From ietf-bounces@ietf.org Mon Oct 01 00:55:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcCyS-0004ND-EP; Mon, 01 Oct 2007 00:33:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcCyQ-0004Mq-Al; Mon, 01 Oct 2007 00:33:38 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcCyL-00033x-4J; Mon, 01 Oct 2007 00:33:34 -0400 Received: by dog.tcb.net (Postfix, from userid 0) id 7DC7C2680F1; Sun, 30 Sep 2007 22:32:57 -0600 (MDT) Received: from [192.168.1.7] (VDSL-151-118-145-60.DNVR.QWEST.NET [151.118.145.60]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sun, 30 Sep 2007 22:32:57 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=151.118.145.60; client-port=50344; syn-fingerprint=65535:56:1:64:M1460,N,W0,N,N,T,S MacOS 10.4.8; data-bytes=0 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <18AB2B0C-6169-4132-8F2E-06A04D0914E3@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Date: Sun, 30 Sep 2007 22:32:39 -0600 To: ietf@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: dnsop@ietf.org Subject: Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I do support this document being published as BCP. A couple of minor comments: Section 4's reference to BCP 84, in part, creates a false sense of useful action on part of the operator, IMO (in addition, there's a typo; s/were/where/). In situations were more complex network setups are in place, "Ingress Filtering for Multihomed Network" [BCP84] maybe a useful additional reference. Perhaps clarifying that Strict and Feasible methods do provide some protection, but Loose provides zero protection from reflective attacks, as they really only require that the target "exist" - they usually do. You might stress that the "IP based authentication" recommendation is pretty much useless -- unless you implement policy at all ingress points (including from peers/providers). In particular, if you don't filter you're permitted-query-address-sources coming from "the Internet" or peers, then spoofing can still be used to launch reflective attacks: o IP based authentication. Use the IP address of the sending host and filter them through and Access Control List (ACL) to service only the intended clients. Also, I'm not sure I'd call this "authentication", perhaps IP-based access policy" is more appropriate? Some more details and recommendations on SOHOish ORNS might be useful for implementers. As for the TSIG or SIG(0) recommendation, I'm not sure what the numbers are for client support today, but I suspect it's at best an negligible sample. I also agree with Paul Hoffman's comments on some reasons for ORNSs. There are many reasons why I may want to use a specific resolver consistently, to include those outlined by Paul/John. -danny _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 01 04:09:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcG52-0005V4-OM; Mon, 01 Oct 2007 03:52:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcG50-0005Ub-Vc; Mon, 01 Oct 2007 03:52:38 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcG4u-00080I-O6; Mon, 01 Oct 2007 03:52:38 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 2B3111C00EB; Mon, 1 Oct 2007 09:52:27 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 262511C00DE; Mon, 1 Oct 2007 09:52:27 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 22AC358ECCA; Mon, 1 Oct 2007 09:52:27 +0200 (CEST) Date: Mon, 1 Oct 2007 09:52:27 +0200 From: Stephane Bortzmeyer To: Danny McPherson Message-ID: <20071001075227.GA18512@nic.fr> References: <18AB2B0C-6169-4132-8F2E-06A04D0914E3@tcb.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18AB2B0C-6169-4132-8F2E-06A04D0914E3@tcb.net> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: dnsop@ietf.org, ietf@ietf.org Subject: Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Sun, Sep 30, 2007 at 10:32:39PM -0600, Danny McPherson wrote a message of 51 lines which said: > Section 4's reference to BCP 84, in part, creates a false sense of > useful action on part of the operator, This could be said of all the parts of the I-D which mentions non-DNS issues such as BCP 38. In that respect, I full agree with Stephen Hanna's review (http://www1.ietf.org/mail-archive/web/ietf/current/msg48117.html). > Some more details and recommendations on SOHOish ORNS might be > useful for implementers. Any idea? The current draft mentions "Incoming Interface based selection" and I do not see what to add? > I also agree with Paul Hoffman's comments on some reasons for ORNSs. > There are many reasons why I may want to use a specific resolver > consistently, to include those outlined by Paul/John. Sorry, but their messages are quite off the track. The problem is not wether there is an use case for using a resolver different from the one provided by the current access point. There are, indeed, many reasons for *not* using the default resolver (ISP which violates RFC 4925, section 2.5.2 are a very good example). But ORNS are *not* the proper solution for that use case. TSIG signatures, VPNs, local caching resolvers are the good solutions. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 01 05:34:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcHa4-0000Hs-AQ; Mon, 01 Oct 2007 05:28:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcHJT-0004GD-6V for ietf@ietf.org; Mon, 01 Oct 2007 05:11:39 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcHJS-0004z5-Ln for ietf@ietf.org; Mon, 01 Oct 2007 05:11:39 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 0674D19865D; Mon, 1 Oct 2007 12:11:38 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6D5DE198646; Mon, 1 Oct 2007 12:11:37 +0300 (EEST) Message-ID: <4700B9C6.6040202@piuha.net> Date: Mon, 01 Oct 2007 12:11:34 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: David Harrington References: <02c601c7feef$b6460730$6702a8c0@china.huawei.com> In-Reply-To: <02c601c7feef$b6460730$6702a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: 6man-chairs@tools.ietf.org, 'IETF discussion list' , tim.polk@nist.gov, secdir@mit.edu, psavola@funet.fi, 'Sam Hartman' , gnn@neville-neil.com Subject: Re: secid review of draft-ietf-ipv6-deprecate-rh0-01 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi David, and thanks for your review. Inline: > As such, the whole document is a security consideration. The > vulnerability appears well-documented, and the guidelines for handling > the deprecated RH0 are clear. > Good. > I have a few comments > 1) RH0 really is something we do not want to see used, right? Should > this RH be obsoleted rather than deprecated? > The new RFC cannot obsolete the RFC where RH0 was defined, because the latter contains also parts that we do not intend to remove :-) i.e., base IPv6 spec. > 2) Per BCP61, MUST is for implementers, and SHOULD is for > users/deployers. There is a MUST NOT in section 4.2 that is a > deployment decision, so this should be a SHOULD NOT. At the same time, > there is a "must" in section 4.2 that is an implementation > requirement, so this should be a MUST. > Hmm. There was fair amount of discussion about this in the WG. The problem is that wholesale filtering of protocol 43 breaks other things, including Mobile IPv6. This is why the document explicitly says that type specific filtering is required. There was a desire to make this very clear. But then again, who is the IETF to say what filtering MUST be performed? If someone wants to block all of TCP, they should be able to do it... We'll talk about this point in the next IESG telechat. > 3) Section three uses "must" where MUST would seem appropriate > This is a quote from another RFC, and as such we should not change it. Jari _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 01 09:36:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcL7n-0001mn-Nj; Mon, 01 Oct 2007 09:15:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcL7m-0001mN-3Q for ietf@ietf.org; Mon, 01 Oct 2007 09:15:50 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcL7b-0001ZW-N8 for ietf@ietf.org; Mon, 01 Oct 2007 09:15:50 -0400 Received: from [192.168.0.2] (adsl-67-127-53-203.dsl.pltn13.pacbell.net [67.127.53.203]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l91DFHHg024763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2007 06:15:17 -0700 Message-ID: <4700F2E7.2080404@bbiw.net> Date: Mon, 01 Oct 2007 06:15:19 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian E Carpenter References: <47004511.1030102@dcrocker.net> <4700534F.6040309@gmail.com> In-Reply-To: <4700534F.6040309@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ietf@ietf.org Subject: Re: Third Last Call: draft-housley-tls-authz-extns X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Brian E Carpenter wrote: > IANAL, but it's my understanding that the prominently displayed Note Well > text already serves this purpose. The real sanction can only be having > a patent struck down by the courts due to intentional failure to > disclose it; all the IETF can do is to make its rules clear enough > for the courts to be able to make such a finding. ... > I don't see what we need to change. As the current case shows, > we know how to rescind a standards action if appropriate. IALOAL (I am less of a lawyer) but what you say makes complete sense to me (which probably should worry folks.) IETF actions: Note Well note, and later possibility of rescinding standards status. Legal action (by others): Use of Note Well, etc. as input to suit against patent. The only issue that occurs to me is the difference between Historic vs. Experimental/Informational. The only reason it might be worthy of discussion is the possible legal impact. I could imagine that Historic would be a more clear bit of input to the legal process... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 01 12:07:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcNc5-0003VK-JW; Mon, 01 Oct 2007 11:55:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcNc3-0003KD-G1 for ietf@ietf.org; Mon, 01 Oct 2007 11:55:15 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcNbl-00069x-2U for ietf@ietf.org; Mon, 01 Oct 2007 11:54:57 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JP800MM9PJK6Q@usaga01-in.huawei.com> for ietf@ietf.org; Mon, 01 Oct 2007 08:54:56 -0700 (PDT) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JP800KKKPJJGX@usaga01-in.huawei.com> for ietf@ietf.org; Mon, 01 Oct 2007 08:54:56 -0700 (PDT) Date: Mon, 01 Oct 2007 10:54:44 -0500 From: Spencer Dawkins To: ietf@ietf.org Message-id: <00fe01c80443$628e44f0$6901a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <47004511.1030102@dcrocker.net> <4700534F.6040309@gmail.com> <4700F2E7.2080404@bbiw.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: Re: Third Last Call: draft-housley-tls-authz-extns X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi, Dave, Just to make sure I'm breathing the same atmosphere you are ... Are you suggesting initial publication of RFCs as Historic? I have some opinions about that, but wanted to make sure what you are suggesting before I start typing... Spencer > The only issue that occurs to me is the difference between Historic vs. > Experimental/Informational. The only reason it might be worthy of > discussion is the possible legal impact. I could imagine that Historic > would be a more clear bit of input to the legal process... > > d/ _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 01 12:16:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcNr2-0000Z6-NV; Mon, 01 Oct 2007 12:10:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcNr0-0000UL-Fg; Mon, 01 Oct 2007 12:10:42 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.201.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcNr0-0006Xt-3J; Mon, 01 Oct 2007 12:10:42 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l91GAXOa018228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2007 12:10:34 -0400 (EDT) Date: Mon, 01 Oct 2007 12:10:33 -0400 From: Jeffrey Hutzelman To: Mark Andrews , Stephen Hanna Message-ID: In-Reply-To: <200709242336.l8ONaNhB060726@drugs.dv.isc.org> References: <200709242336.l8ONaNhB060726@drugs.dv.isc.org> Originator-Info: login-token=Mulberry:01f/hxq+lg5h/LQ+kssnahGhZqqNYGLOrsbZ8QtXg=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: dnsop-chairs@ietf.org, ietf@ietf.org, secdir@mit.edu, fneves@registro.br, iesg@ietf.org, Jeffrey Hutzelman , joao_damas@isc.org Subject: Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Tuesday, September 25, 2007 09:36:23 AM +1000 Mark Andrews wrote: >> The Introduction seems a bit defensive in stating that the DOS attacks >> are not due to any flaw in the design of DNS or its implementations. >> While the blame for the attacks lies with the attackers, some aspects >> of nameserver configuration, behavior, and even protocol design make >> the systems vulnerable to these attacks. I suggest that the defensive >> language be removed. > > No, the blame lies with the parties not implementing BCP 38. > A rogue end site should not be able to inject spoofed packets. No; the blame for an attack _always_ lies with the attacker, not the victim. While I certainly wish more network providers would implement BCP 38, those who fail to do so are not to blame for the bad acts of others. FWIW, I believe the "defensive language" in question is neither necessary nor particularly problematic, so I take no position on whether it should be removed. >> Finally, I wonder whether other more fundamental techniques for >> addressing the problem have been explored. For instance, if DNS clients >> were required to perform a simple handshake before a DNS server sent >> a long response, fake requests would provide little amplification. >> For example, requests that elicit long responses could prompt a >> shift to TCP. > > The DNS already does this. The DNS is optimised so that the > normal responses go via UDP and the exceptional responses via > TCP. It does, but normally only responses which are too long for UDP require the use of TCP. A recursive nameserver could mitigate this type of attack by lowering the maximum response size it is willing to send via UDP, forcing the use of TCP and thus a three-way handshake for larger responses. The tricky part is that setting the threshold too low can have serious performance impact. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 01 12:42:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcOCy-0006Aw-TT; Mon, 01 Oct 2007 12:33:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcOCx-0006AL-80 for ietf@ietf.org; Mon, 01 Oct 2007 12:33:23 -0400 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcOCw-00072m-QT for ietf@ietf.org; Mon, 01 Oct 2007 12:33:23 -0400 Received: from [192.168.0.2] (adsl-67-127-53-203.dsl.pltn13.pacbell.net [67.127.53.203]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l91GX5Ca000742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2007 09:33:05 -0700 Message-ID: <47012143.5070402@dcrocker.net> Date: Mon, 01 Oct 2007 09:33:07 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Spencer Dawkins References: <47004511.1030102@dcrocker.net> <4700534F.6040309@gmail.com> <4700F2E7.2080404@bbiw.net> <00fe01c80443$628e44f0$6901a8c0@china.huawei.com> In-Reply-To: <00fe01c80443$628e44f0$6901a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ietf@ietf.org Subject: Re: Third Last Call: draft-housley-tls-authz-extns X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Spencer Dawkins wrote: > Hi, Dave, > > Just to make sure I'm breathing the same atmosphere you are ... > > Are you suggesting initial publication of RFCs as Historic? No (though I think DomainKeys was just initially published that way, albeit for a very different and benign reason; kinda amusing to see.). Brian suggested the Historic label as an essentially punitive action, *after* publication on standards track, to reclassify it off the track. If it is discovered that there was inadequate disclosure. It's not exactly insightful to predict that the IETF's taking this unusual action is likely to be the result of a process that includes a lot of anger amongst the IETF community. However I think the action need not be viewed as "punitive". Rather it merely marks an error and fixes the publication "books" to reflect the error. (But, then, I don't see getting on standards track as a "reward", either...) Let's be clear: 1. Lots of specifications do just fine in the real world without any IETF label at all and certainly without an IETF standards track label. So there is no inherent basis for claiming that the label is needed for a spec to be useful. 2. Rather, the label says something about community consensus. If a later disclosure alters that consensus, then of course the community should re-label the thing, to take it off standards track. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 01 12:42:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcOES-0007VI-Pe; Mon, 01 Oct 2007 12:34:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcOER-0007Uk-R7; Mon, 01 Oct 2007 12:34:55 -0400 Received: from dog.tcb.net ([64.78.150.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcOER-00074b-Hm; Mon, 01 Oct 2007 12:34:55 -0400 Received: by dog.tcb.net (Postfix, from userid 0) id 59BA7268682; Mon, 1 Oct 2007 10:34:55 -0600 (MDT) Received: from [192.168.1.7] (VDSL-151-118-145-60.DNVR.QWEST.NET [151.118.145.60]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 01 Oct 2007 10:34:55 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=151.118.145.60; client-port=52346; syn-fingerprint=65535:56:1:64:M1460,N,W0,N,N,T,S MacOS 10.4.8; data-bytes=0 In-Reply-To: References: <200709242336.l8ONaNhB060726@drugs.dv.isc.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <430285D9-F7A6-4E5B-BE99-721D54E23232@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Date: Mon, 1 Oct 2007 10:34:37 -0600 To: Jeffrey Hutzelman X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: dnsop-chairs@ietf.org, ietf@ietf.org, secdir@mit.edu, Mark Andrews , fneves@registro.br, iesg@ietf.org, joao_damas@isc.org Subject: Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 1, 2007, at 10:10 AM, Jeffrey Hutzelman wrote: > > No; the blame for an attack _always_ lies with the attacker, not > the victim. While I certainly wish more network providers would > implement BCP 38, those who fail to do so are not to blame for the > bad acts of others. Given the reality with bots et al. today, most of the attacking systems are actually victims themselves. > It does, but normally only responses which are too long for UDP > require the use of TCP. A recursive nameserver could mitigate this > type of attack by lowering the maximum response size it is willing > to send via UDP, forcing the use of TCP and thus a three-way > handshake for larger responses. The tricky part is that setting > the threshold too low can have serious performance impact. Note that in real deployments just this behavior has broken things on occasion, as many firewall and other such policy application points assume things like DNS resolution will only be UDP/53 transactions. YMMV. -danny _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 01 12:42:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcOJ1-00039W-8Z; Mon, 01 Oct 2007 12:39:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcOIy-0002xA-NM; Mon, 01 Oct 2007 12:39:36 -0400 Received: from mucmx01.ixos.de ([149.235.128.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcOIx-0007AR-Ry; Mon, 01 Oct 2007 12:39:36 -0400 Received: from mucpm02.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l91GdNAM008494; Mon, 1 Oct 2007 18:39:23 +0200 (MEST) Received: from MUCXGC2.opentext.net (mucxg04.opentext.net [149.235.128.138]) by mucpm02.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id l91GdLLQ021049; Mon, 1 Oct 2007 12:39:21 -0400 (envelope-from tgondrom@opentext.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Oct 2007 18:39:20 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A786801AB1F56@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir] draft-aboba-sg-experiment-02.txt Thread-Index: AcgESZ3OHRUHool+TOKTAsuCVxFU4A== From: "Tobias Gondrom" To: , X-Archived: msg.Ba4D5LH:2007-10-01:mucpm02.smtp.dmz.opentext.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ebd5ffc455fd7bcccba963126e1cf1f5 Cc: Bernard_Aboba@hotmail.com, narten@us.ibm.com, ietf@ietf.org, jari.arkko@ericsson.com Subject: [secdir] draft-aboba-sg-experiment-02.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0394595487==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============0394595487== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80449.9E312988" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80449.9E312988 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello,=20 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. The document described an RFC3933 experiment in forming a Study Group = prior to Working Group formation. As such I agree with the authors that = there are no additional specific security considerations as also = discussed in RFC3933.=20 Aside from the Security Review, I have three comments:=20 1. editorial comment to section 1:=20 s/those who have no followed the/ those who have not followed the 2. comment to section 2: Section 2 states that:=20 "If at any point...., including after a first or second BoF session, ... = the IESG MAY propose that a Study Group be formed." This sounds to me like partially conflicting with RFC2418, which clearly = states that an absolute maximum of two BOFs are allowed for a topic. This would implicate that if a Study Group was formed after the second = BOF, it would have to directly lead to a WG (or be abandoned) as it can = not go back to BOF.=20 I would propose to change this to that a Study Group may be initiated = after the first BOF but not after the second to prevent this conflict.=20 (The second BOF is already an extension and we should not add the Study = Group as a second extension to the system. People should be pretty well = prepared at a second BOF to get either a Yes or No - and if they are not = ready for a decision by then, another second extension may probably also = not help.) So, proposal to change the line in section 2 accordingly:=20 s/including after a first or second BoF session/including after a first = BoF session I.e. if a first BOF does not lead to the anticipated results (WG: yes/no = decision), the appropriate mechanism for the AD should be to decide = whether s/he wants to use this experiment or run straight with the = second BOF as defined in the process. With the study group the second = BOF could be initiated after the Study Group has concluded if the AD = does not want to go to WG directly without second BOF.=20 3. comment to section 3:=20 In section 3 it is described that a study group shall have and run the = same infrastructure identical to a WG.=20 I would not agree with this suggestion, but think it should be limited = to less than a WG.=20 Otherwise it might lead to false impressions, de-facto situations and = also prolong the work of the study group to finally get a "go" for a WG, = as they might consider this an already fully functional "lightweight = WG".=20 Summary:=20 I believe that this idea of a Study Group is a great idea that will add = a new tool for the AD for the situation that a BOF has not been = satisfactory preparing a WG formation. However I would suggest to make sure to keep a clear distinction between = a WG and a study group, as they differ dramatically in the regard of = role and acceptance by the IETF community. If they both look similar = this might be misunderstood by people outside or new to the IETF.=20 Greeting, Tobias __________________________________________ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/ =20 Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, = Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 = 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: = M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number = /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton, Walter K=F6hler ------_=_NextPart_001_01C80449.9E312988 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [secdir] draft-aboba-sg-experiment-02.txt

Hello,

I = have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the = IESG.  These comments were written primarily for the benefit of the security area = directors.  Document editors and WG chairs should treat these = comments just like any other last call comments.

The = document described an RFC3933 experiment in forming a Study Group = prior to Working Group formation. As such I agree with the authors that = there are no additional specific security considerations as also discussed in = RFC3933.


Aside = from the Security Review, I have three comments:

1. editorial comment to section 1:

s/those who have no followed the/ those who have not = followed the

2. = comment = to section 2:

Section 2 states that:

If = at any point., = including after a first or second BoF session, the IESG MAY propose that a Study Group be = formed.

This = sounds to me like partially conflicting with RFC2418, which clearly states that an absolute = maximum of two BOFs are allowed for a topic.

This = would implicate that if a Study Group was formed after the second BOF, = it would have to directly lead to a WG (or be abandoned) = as it can not go back to BOF. =

I = would propose to change this to that a Study Group may be initiated after the first BOF but not after = the second to prevent this conflict. =

(The = second BOF is already an extension and we should not add the Study Group = as a second extension to the system. People should be pretty well = prepared at a second BOF to get either a Yes or No = and if they are not = ready for a decision = by then, = another second extension = may probably also not help.)

So, = proposal to change the line in section 2 accordingly:

s/including after a first or second BoF session/including after a first BoF session

I.e. = if a first BOF = does not lead to the anticipated results = (WG: yes/no decision), = the appropriate mechanism for the AD should be to decide whether s/he = wants to use this experiment or run straight with the second BOF as defined in = the process. With the = study group the = second BOF could be initiated after the Study Group has = concluded = if the AD does not want to go to WG directly without second = BOF. =

3. = comment to section 3:

In = section 3 it is described that a study group shall have and run = the same infrastructure = identical to a WG.

I = would not agree with this suggestion, but think it should be limited to less than a = WG.

Otherwise it might lead to false impressions, de-facto situations = and also prolong the work of = the study group to finally get a go = for a WG, = as they might consider this an already fully functional lightweight WG.


Summary:

I = believe that this = idea of a Study Group is a great = idea that will add a new tool for the AD for the situation = that a BOF has not been satisfactory preparing a WG formation.

However I would suggest to make sure to keep a clear distinction between a WG and a = study group, = as they differ dramatically in the regard of role and acceptance by the IETF community. If they both look similar this might = be misunderstood by people outside or new to the IETF.

Greeting, Tobias





__________________________________________
Tobias = Gondrom
Head of = Open Text Security Team
Director, Product Security

Open = Text
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail:
mailto:tobias.gondrom@opentex= t.com
Internet: http://www.opentext.com/  =

Place = of Incorporation / Sitz der Gesellschaft: Open Text GmbH, = Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 = 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: = M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number = /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton, Walter K=F6hler

------_=_NextPart_001_01C80449.9E312988-- --===============0394595487== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0394595487==-- From ietf-bounces@ietf.org Mon Oct 01 12:48:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcOMU-0003bi-QD; Mon, 01 Oct 2007 12:43:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcOMT-0003bd-Ly for ietf@ietf.org; Mon, 01 Oct 2007 12:43:13 -0400 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcOMS-0005d2-9p for ietf@ietf.org; Mon, 01 Oct 2007 12:43:13 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l91GhBKm019855 for ; Mon, 1 Oct 2007 16:43:11 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l91GhBOJ025753 for ; Mon, 1 Oct 2007 10:43:11 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l91GhAVB016887 for ; Mon, 1 Oct 2007 11:43:10 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l91GhASU016886 for ietf@ietf.org; Mon, 1 Oct 2007 11:43:10 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 1 Oct 2007 11:43:10 -0500 From: Nicolas Williams To: ietf@ietf.org Message-ID: <20071001164310.GZ11376@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i X-Spam-Score: -1.0 (-) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo() and searching) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 200709270133.l8R1XuB6060071@drugs.dv.isc.org List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org What a timely thread. I've recently concluded that we need an extension to getaddrinfo() along these lines, but I'm looking for somewhat tighter and more generic semantics. My proposal is to add an AI_SECURE_CANONNAME flag with the following semantics: - it MUST be used with AI_CANONNAME - if set in the hints then it will be set in the results IFF: - the resulting ai_canonname == the nodename given as input or - the resulting ai_canonname was obtained securely, such as from a write-protected local hosts file, via DNSSEC, or via any other acceptably secure name service or - the resulting ai_canonname == nodename + '.' + default domain from the resolver's configuration (i.e., the _first_ domain in the search list) Additional flags modifying for controlling search behaviour would be nice, such as: - AI_CANONNAME_SEARCH_ANY Accept canonical names formed by successively trying the given nodename suffixed with the domainnames from the resolver's search list. If this flag is used in the input hints then it will be set in the result IFF the domainname used to qualify the given nodename was not the first domain in the search list. - AI_CANONNAME_SEARCH_PARENTS Like AI_CANONNAME_SEARCH_ANY, but skip domainnames in the search list which are not parents (or grandparents) of the preceding domainname on the list. - AI_CANONNAME_SEARCH_SIBLINGS Like AI_CANONNAME_SEARCH_PARENTS, but search sibling domains in the search list too. - AI_CANONNAME_SEARCH_DEFAULT Allow whatever AI_CANONNAME_SEARCH_* behaviour is locally configured as a default for this flag. If this flag is used in the input hints then one of the above will be set in the result to indicate which search policy was configured and used. This flag might be all the other AI_CANONNAME_SEARCH_* flags ORed together. I'm still researching this proposal. We might want one more flag to indicate whether unsecured NXDOMAIN replies can be/were processed during search list processing, say, AI_SECURE_CANONNAME_SEARCH. And we might not care to have so many AI_CANONNAME_SEARCH_* flags, maybe AI_CANONNAME_SEARCH_ANY will do. Comments? Nico -- _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 01 12:53:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcORA-0006nf-DW; Mon, 01 Oct 2007 12:48:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcOR8-0006XS-7R; Mon, 01 Oct 2007 12:48:02 -0400 Received: from dog.tcb.net ([64.78.150.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcOR7-0007QV-Nh; Mon, 01 Oct 2007 12:48:02 -0400 Received: by dog.tcb.net (Postfix, from userid 0) id 86D022686DE; Mon, 1 Oct 2007 10:48:01 -0600 (MDT) Received: from [192.168.1.7] (VDSL-151-118-145-60.DNVR.QWEST.NET [151.118.145.60]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 01 Oct 2007 10:48:01 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=151.118.145.60; client-port=52391; syn-fingerprint=65535:56:1:64:M1460,N,W0,N,N,T,S MacOS 10.4.8; data-bytes=0 In-Reply-To: <20071001075227.GA18512@nic.fr> References: <18AB2B0C-6169-4132-8F2E-06A04D0914E3@tcb.net> <20071001075227.GA18512@nic.fr> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6597BFA8-7B43-4076-BA19-76B42B61D07F@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Date: Mon, 1 Oct 2007 10:47:44 -0600 To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: dnsop@ietf.org, ietf@ietf.org Subject: Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 1, 2007, at 1:52 AM, Stephane Bortzmeyer wrote: > On Sun, Sep 30, 2007 at 10:32:39PM -0600, > Danny McPherson wrote > a message of 51 lines which said: > >> Section 4's reference to BCP 84, in part, creates a false sense of >> useful action on part of the operator, > > This could be said of all the parts of the I-D which mentions non-DNS > issues such as BCP 38. In that respect, I full agree with Stephen > Hanna's review > (http://www1.ietf.org/mail-archive/web/ietf/current/msg48117.html). I read Stephen's comments before posting, and I agree as well. However, the BCP 84 bit is slightly different because it's only useful for mitigating reflective attacks IF it's employed in a particular way. If this document is going to reference it then it should make a distinction here. > Any idea? The current draft mentions "Incoming Interface based > selection" and I do not see what to add? Perhaps expanding in the "Problem Description" section would be beneficial. Something mentioning that Many SOHO and broadband access devices provide some flavor of name resolution services (e.g., there are 4 flavors outlined by JKT and others; Recursive, Forwarder, Caching- only and Restricted). Some other empirical bits might be useful as well, though and although I'm not sure they need to be in the I-D, they would be useful: E.g., 16M recursive "type" servers, , with 800k or so being the larger problem. Also, some references that provide usual information on actual numbers, such as John's work here: http://condor.depaul.edu/~jkristof/orns/ http://maps.measurement-factory.com/gallery/Openresolvers/ And this is particularly illustrative: http://maps.measurement-factory.com/gallery/Openresolvers/20070429.png As for the current text, you don't provide much in the way of explaining that queries should probably not be accepted from the Internet/untrusted interfaces, you just essentially state that interface-based discrimination might be employed. That was my initial concern. If your attempt is to progress as BCP, then some actual specific guidelines on this front for implementers and administrators alike might provide more actionable information. > > Sorry, but their messages are quite off the track. The problem is not > wether there is an use case for using a resolver different from the > one provided by the current access point. There are, indeed, many > reasons for *not* using the default resolver (ISP which violates RFC > 4925, section 2.5.2 are a very good example). But ORNS are *not* the > proper solution for that use case. TSIG signatures, VPNs, local > caching resolvers are the good solutions. I think you made my point. Where is this currently explained in the document as such? Acknowledging existence and practical realities is important, methinks. -danny _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 01 12:54:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcOUq-0002Bf-M7; Mon, 01 Oct 2007 12:51:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcOUp-0002BZ-FM for ietf@ietf.org; Mon, 01 Oct 2007 12:51:51 -0400 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcOUp-0007ao-1S for ietf@ietf.org; Mon, 01 Oct 2007 12:51:51 -0400 Received: from [192.168.0.2] (adsl-67-127-53-203.dsl.pltn13.pacbell.net [67.127.53.203]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l91GpXdW006539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 1 Oct 2007 09:51:33 -0700 Message-ID: <47012597.4010601@dcrocker.net> Date: Mon, 01 Oct 2007 09:51:35 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ietf@ietf.org References: <47004511.1030102@dcrocker.net> <4700534F.6040309@gmail.com> <4700F2E7.2080404@bbiw.net> <00fe01c80443$628e44f0$6901a8c0@china.huawei.com> <47012143.5070402@dcrocker.net> In-Reply-To: <47012143.5070402@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: Re: Third Last Call: draft-housley-tls-authz-extns X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Post-posting additional thoughts: Dave Crocker wrote: > 2. Rather, the label says something about community consensus. If a > later disclosure alters that consensus, then of course the community > should re-label the thing, to take it off standards track. Although this should be check with an appropriate attorney, I would expect that relabeling to Historic might have a variety of uses for an legal actions. Reversing a patent is only one. I could imagine something as interesting as class action, among the companies who were deceived by the non-disclosing party. After all, they will have gone down the path of strategic planning and implementation, on a basis that the disclosing party knew to be both incorrect and to its benefit, along with being against the IETF rules. I could even imagine that those companies could even demand fees for having been used as unwitting consultants to the disclosing party's design efforts... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 01 14:06:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcPPX-00083j-Vk; Mon, 01 Oct 2007 13:50:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcPPV-00081S-T3; Mon, 01 Oct 2007 13:50:26 -0400 Received: from dhcp-18-188-10-61.dyn.mit.edu ([18.188.10.61] helo=carter-zimmerman.suchdamage.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcPPQ-0007mw-P9; Mon, 01 Oct 2007 13:50:21 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7B93748C4; Mon, 1 Oct 2007 13:50:00 -0400 (EDT) To: ietf@ietf.org From: Sam Hartman Message-Id: <20071001175000.7B93748C4@carter-zimmerman.suchdamage.org> Date: Mon, 1 Oct 2007 13:50:00 -0400 (EDT) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: Would someone help the secretariat figure out why they cannot route to teredo addresses? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi. I opened a ticket with the secretariat a few weeks ago complaining that I cannot reach www.ietf.org using a teredo address either allocated through the Microsoft Teredo server or the Debian teredo server. This is annoying because glibc's source address selection algorithm seems to prefer teredo addresses to v4 addresses. So, I get really bad response times to www.ietf.org when using teredo. Based on the responses to the ticket, it was not entirely clear if the people at NSS understood how teredo differs from a normal IPV6 address. I just don't have time to work with them to debug the problem. Is there someone out there with significant IPV6 experience who can reproduce the problem and who would be willing to work with NSS to resolve? I want to reiterate that NSS has been incredibly helpful. They are willing to work with me, I just don't have time to explain Teredo and be responsive. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 01 15:17:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcQWK-0001R3-Tc; Mon, 01 Oct 2007 15:01:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcQWI-0001FE-8E for ietf@ietf.org; Mon, 01 Oct 2007 15:01:30 -0400 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcQWH-00031t-Js for ietf@ietf.org; Mon, 01 Oct 2007 15:01:30 -0400 DKIM-Signature: a=rsa-sha1; c=nowsp; d=consulintel.es; s=MDaemon; t=1191268703; x=1191873503; i=jordi.palet@consulintel.es; q=dns; h=DomainKey-Signature:Received:User-Agent:Date:Subject:From:To: Message-ID:Thread-Topic:Thread-Index:In-Reply-To:Mime-version: Content-type:Content-transfer-encoding:Reply-To; b=TfxHP4I+d12Oxc 6+v1WjIpQpker9QTb5/eCtfYvoFrC2s6BgK8y4dYDYuCgGXfiLFYsR7B3HdKdcC6 r3GDCoWdmdqCGIIXzdAg8avxUTJ96Iqj9OpRZLWVWexA6YXlY9CnuuxrsTxrFJ3p 3QIJFsRHqDL4k6mBetTCyTQFmYZvk= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=XDQ1JxPRmFAUQd8u7YXCW8uBzVGcDRDatFn7KYMNQKqvRKZHwWOysB5d81WjHa9G5g9qORTA5b/fNNbS8ZI2C8dcr7CLyXqs2/2oM/GA7bdrlpluuLwD7LuPPDJSqoniBP+jkT+zPXUFergy7mfV0YD3kDaOMX8LsINzX8yH7kY=; Received: from [10.10.10.50] by consulintel.es (MDaemon.PRO.v8.1.5.R) with ESMTP id md50002678424.msg for ; Mon, 01 Oct 2007 20:58:21 +0200 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 01 Oct 2007 21:01:32 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: Would someone help the secretariat figure out why they cannot route to teredo addresses? Thread-Index: AcgEXXrfubRsVHBQEdyS6wAX8sYbNQ== In-Reply-To: <20071001175000.7B93748C4@carter-zimmerman.suchdamage.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:071001:ietf@ietf.org::WpORuN29ledEan+i:00001YxV X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ietf@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es X-Spam-Status: No, score=-4.7 required=4.5 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Level: X-Spam-Processed: consulintel.es, Mon, 01 Oct 2007 20:58:23 +0200 X-MDAV-Processed: consulintel.es, Mon, 01 Oct 2007 20:58:23 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: Re: Would someone help the secretariat figure out why they cannot route to teredo addresses? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I can work on that. Regards, Jordi > De: Sam Hartman > Responder a: > Fecha: Mon, 1 Oct 2007 13:50:00 -0400 (EDT) > Para: > Asunto: Would someone help the secretariat figure out why they cannot route to > teredo addresses? > > > > Hi. I opened a ticket with the secretariat a few weeks ago > complaining that I cannot reach www.ietf.org using a teredo address > either allocated through the Microsoft Teredo server or the Debian > teredo server. > > This is annoying because glibc's source address selection algorithm > seems to prefer teredo addresses to v4 addresses. So, I get really > bad response times to www.ietf.org when using teredo. > > Based on the responses to the ticket, it was not entirely clear if the > people at NSS understood how teredo differs from a normal IPV6 > address. I just don't have time to work with them to debug the > problem. > > Is there someone out there with significant IPV6 experience who can > reproduce the problem and who would be willing to work with NSS to > resolve? > > I want to reiterate that NSS has been incredibly helpful. They are > willing to work with me, I just don't have time to explain Teredo and > be responsive. > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 01 21:34:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcWGA-0002p0-Uh; Mon, 01 Oct 2007 21:09:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcWG9-0002oW-7j for ietf@ietf.org; Mon, 01 Oct 2007 21:09:13 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcWG5-0000Do-6Z for ietf@ietf.org; Mon, 01 Oct 2007 21:09:10 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id 0E018233E8; Tue, 2 Oct 2007 10:08:44 +0900 (JST) To: 200709270133.l8R1XuB6060071@drugs.dv.isc.org In-Reply-To: Your message of "Mon, 1 Oct 2007 11:43:10 -0500" <20071001164310.GZ11376@Sun.COM> References: <20071001164310.GZ11376@Sun.COM> X-Mailer: Cue version 0.8 (070521-1856/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20071002010844.0E018233E8@coconut.itojun.org> Date: Tue, 2 Oct 2007 10:08:44 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: -0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ietf@ietf.org Subject: Re: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo() and searching) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > What a timely thread. > > I've recently concluded that we need an extension to getaddrinfo() along > these lines, but I'm looking for somewhat tighter and more generic > semantics. > > My proposal is to add an AI_SECURE_CANONNAME flag with the following > semantics: do not try to implement policy into applications. you will end up forced to (?) rewrite every existing applications. itojun _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 01 21:50:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcWmQ-0001LA-5A; Mon, 01 Oct 2007 21:42:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcWmD-0001Is-To; Mon, 01 Oct 2007 21:42:21 -0400 Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcWmC-0000xC-Je; Mon, 01 Oct 2007 21:42:21 -0400 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id l921g1Qh079229; Tue, 2 Oct 2007 11:42:02 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200710020142.l921g1Qh079229@drugs.dv.isc.org> To: Danny McPherson From: Mark Andrews In-reply-to: Your message of "Sun, 30 Sep 2007 22:32:39 CST." <18AB2B0C-6169-4132-8F2E-06A04D0914E3@tcb.net> Date: Tue, 02 Oct 2007 11:42:01 +1000 X-Spam-Score: -1.4 (-) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: dnsop@ietf.org, ietf@ietf.org Subject: Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > As for the TSIG or SIG(0) recommendation, I'm not sure what > the numbers are for client support today, but I suspect it's at > best an negligible sample. Well all Windows XP/2003/Vista boxes can be configured to support TSIG, with free software, if not natively. All Linux, *BSD and Apple boxes can do this with what ships with the OS. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 01 21:56:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcWwV-00057Q-9X; Mon, 01 Oct 2007 21:52:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcWwS-0004uY-OJ; Mon, 01 Oct 2007 21:52:56 -0400 Received: from dog.tcb.net ([64.78.150.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcWwS-0003Qq-G5; Mon, 01 Oct 2007 21:52:56 -0400 Received: by dog.tcb.net (Postfix, from userid 0) id 41B28368043; Mon, 1 Oct 2007 19:52:56 -0600 (MDT) Received: from [166.129.8.188] (166.129.8.188 [166.129.8.188]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 01 Oct 2007 19:52:55 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=166.129.8.188; client-port=49901; client-dnsfail=166.129.8.188: name server failure; syn-fingerprint=65535:53:1:64:M1460,N,W0,N,N,T,S MacOS 10.4.8; data-bytes=0 In-Reply-To: <200710020142.l921g1Qh079229@drugs.dv.isc.org> References: <200710020142.l921g1Qh079229@drugs.dv.isc.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Danny McPherson Date: Mon, 1 Oct 2007 19:52:33 -0600 To: Mark Andrews X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: dnsop@ietf.org, ietf@ietf.org Subject: Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 1, 2007, at 7:42 PM, Mark Andrews wrote: > >> As for the TSIG or SIG(0) recommendation, I'm not sure what >> the numbers are for client support today, but I suspect it's at >> best an negligible sample. > > Well all Windows XP/2003/Vista boxes can be configured to > support TSIG, with free software, if not natively. > > All Linux, *BSD and Apple boxes can do this with what ships > with the OS. Sorry, I said "support", I meant "use". Any numbers there? -danny _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 01 23:11:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcXva-0000vW-Ih; Mon, 01 Oct 2007 22:56:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcXvV-0000tt-Sf; Mon, 01 Oct 2007 22:56:01 -0400 Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcXvR-0002Ga-E6; Mon, 01 Oct 2007 22:55:58 -0400 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id l922tadC023029; Tue, 2 Oct 2007 12:55:37 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200710020255.l922tadC023029@drugs.dv.isc.org> To: Jeffrey Hutzelman From: Mark Andrews In-reply-to: Your message of "Mon, 01 Oct 2007 12:10:33 -0400." Date: Tue, 02 Oct 2007 12:55:36 +1000 X-Spam-Score: -1.4 (-) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: dnsop-chairs@ietf.org, ietf@ietf.org, secdir@mit.edu, fneves@registro.br, iesg@ietf.org, joao_damas@isc.org Subject: Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > > > On Tuesday, September 25, 2007 09:36:23 AM +1000 Mark Andrews > wrote: > > >> The Introduction seems a bit defensive in stating that the DOS attacks > >> are not due to any flaw in the design of DNS or its implementations. > >> While the blame for the attacks lies with the attackers, some aspects > >> of nameserver configuration, behavior, and even protocol design make > >> the systems vulnerable to these attacks. I suggest that the defensive > >> language be removed. > > > > No, the blame lies with the parties not implementing BCP 38. > > A rogue end site should not be able to inject spoofed packets. > > No; the blame for an attack _always_ lies with the attacker, not the > victim. I'm not blaming the victim, I'm pointing out the contributory negligence on behalf of the ISP that is supplying the attacker bandwidth. BCP 38 is over 7 years old now. The time has past where you can blame the hardware vendors for lack of support. The blame now has to be squarely brought down on the ISP's that have failed to deploy BCP 38. A attacker should not be able to send spoofed packet and have them reach the destination. I don't care if the destination is the other side of the world or the neighbor. ISP's should be doing this anyway to protect their customers from accidental traffic. e.g. DHCP lease changes where not all of the sockets with the old address have shutdown. RFC 1918 sourced traffic. > While I certainly wish more network providers would implement BCP > 38, those who fail to do so are not to blame for the bad acts of others. > > FWIW, I believe the "defensive language" in question is neither necessary > nor particularly problematic, so I take no position on whether it should be > removed. > > >> Finally, I wonder whether other more fundamental techniques for > >> addressing the problem have been explored. For instance, if DNS clients > >> were required to perform a simple handshake before a DNS server sent > >> a long response, fake requests would provide little amplification. > >> For example, requests that elicit long responses could prompt a > >> shift to TCP. > > > > The DNS already does this. The DNS is optimised so that the > > normal responses go via UDP and the exceptional responses via > > TCP. > > It does, but normally only responses which are too long for UDP require the > use of TCP. A recursive nameserver could mitigate this type of attack by > lowering the maximum response size it is willing to send via UDP, forcing > the use of TCP and thus a three-way handshake for larger responses. The > tricky part is that setting the threshold too low can have serious > performance impact. > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 01 23:33:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcYNh-00040z-WC; Mon, 01 Oct 2007 23:25:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcYNf-0003xW-7t; Mon, 01 Oct 2007 23:25:07 -0400 Received: from mx.isc.org ([2001:4f8:0:2::1c]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcYNe-0002uz-1L; Mon, 01 Oct 2007 23:25:07 -0400 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id A940611407A; Tue, 2 Oct 2007 03:25:00 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id 3862DE6080; Tue, 2 Oct 2007 03:25:00 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id l923OrwQ023453; Tue, 2 Oct 2007 13:24:54 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200710020324.l923OrwQ023453@drugs.dv.isc.org> To: Danny McPherson From: Mark Andrews In-reply-to: Your message of "Mon, 01 Oct 2007 10:34:37 CST." <430285D9-F7A6-4E5B-BE99-721D54E23232@tcb.net> Date: Tue, 02 Oct 2007 13:24:53 +1000 X-Spam-Score: -1.4 (-) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: dnsop-chairs@ietf.org, ietf@ietf.org, secdir@mit.edu, fneves@registro.br, iesg@ietf.org, joao_damas@isc.org, Jeffrey Hutzelman Subject: Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > > It does, but normally only responses which are too long for UDP > > require the use of TCP. A recursive nameserver could mitigate this > > type of attack by lowering the maximum response size it is willing > > to send via UDP, forcing the use of TCP and thus a three-way > > handshake for larger responses. The tricky part is that setting > > the threshold too low can have serious performance impact. > > Note that in real deployments just this behavior has broken things > on occasion, as many firewall and other such policy application points > assume things like DNS resolution will only be UDP/53 transactions. That assumption has always been wrong. I would also dispute the "many" above. Most firewalls actually handle the transition to TCP perfectly fine. There are the odd few that are misconfigured. When that happens people complain because nameservers resolution fails. Either the dataset is "fixed" or the firewall is fixed. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 01 23:35:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcYUF-0003nT-1t; Mon, 01 Oct 2007 23:31:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcYUC-0003iT-FF; Mon, 01 Oct 2007 23:31:52 -0400 Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcYUB-00034i-O9; Mon, 01 Oct 2007 23:31:52 -0400 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id l923VjhY023512; Tue, 2 Oct 2007 13:31:46 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200710020331.l923VjhY023512@drugs.dv.isc.org> To: Jeffrey Hutzelman From: Mark Andrews In-reply-to: Your message of "Mon, 01 Oct 2007 13:01:41 -0400." Date: Tue, 02 Oct 2007 13:31:45 +1000 X-Spam-Score: -1.4 (-) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: dnsop-chairs@ietf.org, ietf@ietf.org, secdir@mit.edu, fneves@registro.br, iesg@ietf.org, Danny McPherson , joao_damas@isc.org Subject: Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > > > On Monday, October 01, 2007 10:34:37 AM -0600 Danny McPherson > wrote: > > > Note that in real deployments just this behavior has broken things > > on occasion, as many firewall and other such policy application points > > assume things like DNS resolution will only be UDP/53 transactions. > > Yeah; I'm getting a little tired of having our protocols redefined based on > the incorrect assumptions of people who don't understand them. The DNS > sometimes uses TCP, UDP flows can last more than one round trip, and ICMP > unreachable messages are an essential part of IP; vendors and operators who > assume otherwise should be made to fix their assumptions, instead of > everyone else having to cripple their applications and networks to make the > assumptions true. > > -- Jeff And IP fragnments exist and are useful. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 01 23:36:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcYXW-0001Op-El; Mon, 01 Oct 2007 23:35:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcYXU-0001NT-9A for ietf@ietf.org; Mon, 01 Oct 2007 23:35:16 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcYXU-0005VZ-2I for ietf@ietf.org; Mon, 01 Oct 2007 23:35:16 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 108531EE1E6; Mon, 1 Oct 2007 23:35:14 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFQK+5rplmEC; Mon, 1 Oct 2007 23:35:12 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 7C2471EE207; Mon, 1 Oct 2007 23:35:09 -0400 (EDT) Message-ID: <4701BC66.5000107@cs.utk.edu> Date: Mon, 01 Oct 2007 23:35:02 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Jun-ichiro itojun Hagino References: <20071001164310.GZ11376@Sun.COM> <20071002010844.0E018233E8@coconut.itojun.org> In-Reply-To: <20071002010844.0E018233E8@coconut.itojun.org> X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ietf@ietf.org, 200709270133.l8R1XuB6060071@drugs.dv.isc.org Subject: Re: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo() and searching) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Jun-ichiro itojun Hagino wrote: >> What a timely thread. >> >> I've recently concluded that we need an extension to getaddrinfo() along >> these lines, but I'm looking for somewhat tighter and more generic >> semantics. >> >> My proposal is to add an AI_SECURE_CANONNAME flag with the following >> semantics: >> > > do not try to implement policy into applications. you will end up > forced to (?) rewrite every existing applications. > perhaps, but having the policy be application-independent doesn't make sense either. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 01 23:53:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcYhU-0000gU-16; Mon, 01 Oct 2007 23:45:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcYhS-0000gF-H2; Mon, 01 Oct 2007 23:45:34 -0400 Received: from mx.isc.org ([2001:4f8:0:2::1c]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcYhR-0003O1-D4; Mon, 01 Oct 2007 23:45:34 -0400 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id 1538911401F; Tue, 2 Oct 2007 03:45:33 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id 96E0AE6080; Tue, 2 Oct 2007 03:45:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id l923jUoL024214; Tue, 2 Oct 2007 13:45:30 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200710020345.l923jUoL024214@drugs.dv.isc.org> To: Danny McPherson From: Mark Andrews In-reply-to: Your message of "Mon, 01 Oct 2007 19:52:33 CST." Date: Tue, 02 Oct 2007 13:45:30 +1000 X-Spam-Score: -1.4 (-) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: dnsop@ietf.org, ietf@ietf.org Subject: Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > On Oct 1, 2007, at 7:42 PM, Mark Andrews wrote: > > > > >> As for the TSIG or SIG(0) recommendation, I'm not sure what > >> the numbers are for client support today, but I suspect it's at > >> best an negligible sample. > > > > Well all Windows XP/2003/Vista boxes can be configured to > > support TSIG, with free software, if not natively. > > > > All Linux, *BSD and Apple boxes can do this with what ships > > with the OS. > > Sorry, I said "support", I meant "use". Any numbers there? > > -danny I use TSIG on my laptop. As for others I have no idea. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 01 23:58:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcYqr-00044I-Hm; Mon, 01 Oct 2007 23:55:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcYqn-0003Hr-H6; Mon, 01 Oct 2007 23:55:13 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcYqm-00062M-Pp; Mon, 01 Oct 2007 23:55:13 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l923t6FY028447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 1 Oct 2007 20:55:06 -0700 Received: from [10.50.65.183] (qconnect-10-50-65-183.qualcomm.com [10.50.65.183]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l923t5bH002439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Oct 2007 20:55:05 -0700 Message-ID: <4701C11E.6080903@qualcomm.com> Date: Mon, 01 Oct 2007 20:55:10 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tobias Gondrom References: <2666EB2A846BAC4BB2D7F593301A786801AB1F56@MUCXGC2.opentext.net> In-Reply-To: <2666EB2A846BAC4BB2D7F593301A786801AB1F56@MUCXGC2.opentext.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by numenor.qualcomm.com id l923t6FY028447 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: narten@us.ibm.com, ietf@ietf.org, jari.arkko@ericsson.com, Bernard_Aboba@hotmail.com, secdir@mit.edu, iesg@ietf.org Subject: Re: [secdir] draft-aboba-sg-experiment-02.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi Tobias, Many thanks for your review. Please see inline for my thoughts on your=20 observations. On 10/1/2007 9:39 AM, Tobias Gondrom wrote: > Hello, >=20 > I have reviewed this document as part of the security directorate's=20 > ongoing effort to review all IETF documents being processed by the=20 > IESG. These comments were written primarily for the benefit of the=20 > security area directors. Document editors and WG chairs should treat=20 > these comments just like any other last call comments. >=20 > The document described an RFC3933 experiment in forming a Study Group=20 > prior to Working Group formation. As such I agree with the authors that= =20 > there are no additional specific security considerations as also=20 > discussed in RFC3933. >=20 >=20 > Aside from the Security Review, I have three comments: >=20 > 1. editorial comment to section 1: >=20 > s/those who have no followed the/ those who have not followed the We'll fix this in the revision. >=20 > 2. comment to section 2: >=20 > Section 2 states that: >=20 > "If at any point...., including after a first or second BoF session, ..= . the=20 > IESG MAY propose that a Study Group be formed." >=20 > This sounds to me like partially conflicting with RFC2418, which clearl= y=20 > states that an absolute maximum of two BOFs are allowed for a topic. >=20 > This would implicate that if a Study Group was formed after the second=20 > BOF, it would have to directly lead to a WG (or be abandoned) as it can= =20 > not go back to BOF. >=20 > I would propose to change this to that a Study Group may be initiated=20 > after the first BOF but not after the second to prevent this conflict. >=20 > (The second BOF is already an extension and we should not add the Study= =20 > Group as a second extension to the system. People should be pretty well= =20 > prepared at a second BOF to get either a Yes or No -- and if they are n= ot=20 > ready for a decision by then, another second extension may probably als= o=20 > not help.) My take is that after the SG it is a WG or nothing. The sponsoring and=20 other ADs would have the opportunity to observe the SG in progress just=20 as they would do a BoF and can assess whether to form a WG or not. With that clarification, does the current wording sound alright? >=20 > So, proposal to change the line in section 2 accordingly: >=20 > s/including after a first or second BoF session/including after a first= =20 > BoF session >=20 > I.e. if a first BOF does not lead to the anticipated results (WG: yes/n= o=20 > decision), the appropriate mechanism for the AD should be to decide=20 > whether s/he wants to use this experiment or run straight with the=20 > second BOF as defined in the process. With the study group the second=20 > BOF could be initiated after the Study Group has concluded if the AD=20 > does not want to go to WG directly without second BOF. >=20 > 3. comment to section 3: >=20 > In section 3 it is described that a study group shall have and run the=20 > same infrastructure identical to a WG. >=20 > I would not agree with this suggestion, but think it should be limited=20 > to less than a WG. It is in fact less than a WG. More specifically, "A Study Group charter=20 MUST NOT include milestones relating to development of a protocol specification." was included=20 to make it less than a WG. The limited lifetime is another constraint. The other processes are intentionally made similar so as to reuse our=20 current operational structures. Does that clarification alleviate this concern? regards, Lakshminath >=20 > Otherwise it might lead to false impressions, de-facto situations and=20 > also prolong the work of the study group to finally get a "go" for a WG= ,=20 > as they might consider this an already fully functional "lightweight WG= ". >=20 >=20 > Summary: >=20 > I believe that this idea of a Study Group is a great idea that will add= =20 > a new tool for the AD for the situation that a BOF has not been=20 > satisfactory preparing a WG formation. >=20 > However I would suggest to make sure to keep a clear distinction betwee= n=20 > a WG and a study group, as they differ dramatically in the regard of=20 > role and acceptance by the IETF community. If they both look similar=20 > this might be misunderstood by people outside or new to the IETF. >=20 > Greeting, Tobias >=20 >=20 >=20 >=20 >=20 > ***__________________________________________* > *****Tobias Gondrom* > Head of Open Text Security Team > Director, Product Security >=20 > *****Open Text* > Technopark 2 > Werner-von-Siemens-Ring 20 > D-85630 Grasbrunn >=20 > Phone: +49 (0) 89 4629-1816 > Mobile: +49 (0) 173 5942987 > Telefax: +49 (0) 89 4629-33-1816 > eMail: mailto:tobias.gondrom@opentext.com > Internet: http://www.opentext.com/=20 >=20 > Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH,=20 > Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 8= 9=20 > 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht:=20 > M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Numbe= r=20 > /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John= =20 > Shackleton, Walter K=F6hler >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 00:20:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcZ7r-0003qn-Q2; Tue, 02 Oct 2007 00:12:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcZ7q-0003qb-HF for ietf@ietf.org; Tue, 02 Oct 2007 00:12:50 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcZ7q-0006MK-9n for ietf@ietf.org; Tue, 02 Oct 2007 00:12:50 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 9DDD81EE209; Tue, 2 Oct 2007 00:12:49 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZdOK+AYpOtl; Tue, 2 Oct 2007 00:12:46 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 636491EE207; Tue, 2 Oct 2007 00:12:42 -0400 (EDT) Message-ID: <4701C538.1000103@cs.utk.edu> Date: Tue, 02 Oct 2007 00:12:40 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Jun-ichiro itojun Hagino References: <4701BC66.5000107@cs.utk.edu> <20071002040737.AEA02233E9@coconut.itojun.org> In-Reply-To: <20071002040737.AEA02233E9@coconut.itojun.org> X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ietf@ietf.org Subject: Re: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo() and searching) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Jun-ichiro itojun Hagino wrote: >>>> I've recently concluded that we need an extension to getaddrinfo() along >>>> these lines, but I'm looking for somewhat tighter and more generic >>>> semantics. >>>> >>>> My proposal is to add an AI_SECURE_CANONNAME flag with the following >>>> semantics: >>>> >>> do not try to implement policy into applications. you will end up >>> forced to (?) rewrite every existing applications. >>> >>> >> perhaps, but having the policy be application-independent doesn't make >> sense either. >> >> it can be application-specific, without application modification. >> check out "systrace" by Niels Provos. >> it's useful but it really isn't flexible enough to remove the need for applications to be able to specify policies. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 00:20:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcZ3K-00037L-Qu; Tue, 02 Oct 2007 00:08:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcZ3F-00032R-IK for ietf@ietf.org; Tue, 02 Oct 2007 00:08:05 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcZ3A-0003tm-7O for ietf@ietf.org; Tue, 02 Oct 2007 00:08:00 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id AEA02233E9; Tue, 2 Oct 2007 13:07:37 +0900 (JST) To: moore@cs.utk.edu In-Reply-To: Your message of "Mon, 01 Oct 2007 23:35:02 -0400" <4701BC66.5000107@cs.utk.edu> References: <4701BC66.5000107@cs.utk.edu> X-Mailer: Cue version 0.8 (070521-1856/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20071002040737.AEA02233E9@coconut.itojun.org> Date: Tue, 2 Oct 2007 13:07:37 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: -0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ietf@ietf.org Subject: Re: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo() and searching) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > >> I've recently concluded that we need an extension to getaddrinfo() along > >> these lines, but I'm looking for somewhat tighter and more generic > >> semantics. > >> > >> My proposal is to add an AI_SECURE_CANONNAME flag with the following > >> semantics: > > > > do not try to implement policy into applications. you will end up > > forced to (?) rewrite every existing applications. > > > perhaps, but having the policy be application-independent doesn't make > sense either. it can be application-specific, without application modification. check out "systrace" by Niels Provos. itojun _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 00:22:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcZDG-000672-H5; Tue, 02 Oct 2007 00:18:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcZDE-00066p-Dy for ietf@ietf.org; Tue, 02 Oct 2007 00:18:24 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcZDD-00045P-64 for ietf@ietf.org; Tue, 02 Oct 2007 00:18:24 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id 2862B233E9; Tue, 2 Oct 2007 13:18:22 +0900 (JST) To: moore@cs.utk.edu In-Reply-To: Your message of "Tue, 02 Oct 2007 00:12:40 -0400" <4701C538.1000103@cs.utk.edu> References: <4701C538.1000103@cs.utk.edu> X-Mailer: Cue version 0.8 (070521-1856/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20071002041822.2862B233E9@coconut.itojun.org> Date: Tue, 2 Oct 2007 13:18:22 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: -0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ietf@ietf.org Subject: Re: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo() and searching) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > >> it can be application-specific, without application modification. > >> check out "systrace" by Niels Provos. > >> > it's useful but it really isn't flexible enough to remove the need for > applications to be able to specify policies. i wonder how many command line options will be added to the applications once you start adding up policy stuff... sendmail.cf lookalike for every apps? itojun _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 00:43:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcZSp-0002Xx-LV; Tue, 02 Oct 2007 00:34:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcZSo-0002Xn-6G for ietf@ietf.org; Tue, 02 Oct 2007 00:34:30 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcZSi-0004Ml-0e for ietf@ietf.org; Tue, 02 Oct 2007 00:34:30 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 01E671EE1C2; Tue, 2 Oct 2007 00:34:07 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+-Z7Q7hdSaS; Tue, 2 Oct 2007 00:34:05 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 220281EE207; Tue, 2 Oct 2007 00:34:05 -0400 (EDT) Message-ID: <4701CA3B.2030301@cs.utk.edu> Date: Tue, 02 Oct 2007 00:34:03 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Jun-ichiro itojun Hagino References: <4701C538.1000103@cs.utk.edu> <20071002041822.2862B233E9@coconut.itojun.org> In-Reply-To: <20071002041822.2862B233E9@coconut.itojun.org> X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ietf@ietf.org Subject: Re: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo() and searching) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Jun-ichiro itojun Hagino wrote: >>>> it can be application-specific, without application modification. >>>> check out "systrace" by Niels Provos. >>>> >>>> >> it's useful but it really isn't flexible enough to remove the need for >> applications to be able to specify policies. >> > > i wonder how many command line options will be added to the > applications once you start adding up policy stuff... sendmail.cf > lookalike for every apps? > well, I do think we need a policy specification language that lets policies for use of the network be specified independently of the application. I just don't think it will be sufficient for all applications. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 00:53:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcZeP-0005lG-NE; Tue, 02 Oct 2007 00:46:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcZeN-0005kc-Al; Tue, 02 Oct 2007 00:46:27 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IcZeM-00074x-Sy; Tue, 02 Oct 2007 00:46:27 -0400 X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1191300385!10160203!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 15325 invoked from network); 2 Oct 2007 04:46:25 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-153.messagelabs.com with SMTP; 2 Oct 2007 04:46:25 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l924kOax009502; Mon, 1 Oct 2007 21:46:24 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l924kOs9010910; Mon, 1 Oct 2007 23:46:24 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l924kNcM010905; Mon, 1 Oct 2007 23:46:23 -0500 (CDT) 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" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Oct 2007 00:46:22 -0400 Message-ID: <3870C46029D1F945B1472F170D2D979003183C3F@de01exm64.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir] secdir review ofdraft-ietf-dnsop-reflectors-are-evil-04.txt Thread-Index: Acf+2UOtT2DLETsATceZ3pArOSN4vgF1VVfw References: From: "Eastlake III Donald-LDE008" To: , , , , , X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: RE: [secdir] secdir review ofdraft-ietf-dnsop-reflectors-are-evil-04.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org See http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-02.txt . Donald -----Original Message----- From: secdir-bounces@mit.edu [mailto:secdir-bounces@mit.edu] On Behalf Of Stephen Hanna Sent: Monday, September 24, 2007 3:52 PM To: ietf@ietf.org; dnsop-chairs@ietf.org; iesg@ietf.org; secdir@mit.edu; Joao_Damas@isc.org; fneves@registro.br Subject: [secdir] secdir review ofdraft-ietf-dnsop-reflectors-are-evil-04.txt ... Finally, I wonder whether other more fundamental techniques for addressing the problem have been explored. For instance, if DNS clients were required to perform a simple handshake before a DNS server sent a long response, fake requests would provide little amplification. ... Thanks, Steve _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 02:43:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcbBc-0005Qh-F2; Tue, 02 Oct 2007 02:24:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcbBR-0005Pc-09 for ietf@ietf.org; Tue, 02 Oct 2007 02:24:41 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcbBQ-0000oJ-FU for ietf@ietf.org; Tue, 02 Oct 2007 02:24:40 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l926OC8H023921 for ; Tue, 2 Oct 2007 09:24:38 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Oct 2007 09:24:37 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Oct 2007 09:24:37 +0300 Received: from esdhcp041139.research.nokia.com ([172.21.41.139]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Oct 2007 09:24:37 +0300 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: ietf@ietf.org Date: Tue, 2 Oct 2007 09:24:48 +0300 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <20071001175000.7B93748C4@carter-zimmerman.suchdamage.org> In-Reply-To: <20071001175000.7B93748C4@carter-zimmerman.suchdamage.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200710020924.49180.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 02 Oct 2007 06:24:37.0551 (UTC) FILETIME=[E82A53F0:01C804BC] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: Re: Would someone help the secretariat figure out why they cannot route to teredo addresses? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Le Monday 01 October 2007 20:50:00 ext Sam Hartman, vous avez =C3=A9crit=C2= =A0: > Hi. I opened a ticket with the secretariat a few weeks ago > complaining that I cannot reach www.ietf.org using a teredo address > either allocated through the Microsoft Teredo server or the Debian > teredo server. > > This is annoying because glibc's source address selection algorithm > seems to prefer teredo addresses to v4 addresses. So, I get really > bad response times to www.ietf.org when using teredo. To make a long short, that depends on your glibc version. As far as I=20 remember, RFC3484 was implemented in version 2.4. Configurable policy in=20 version 2.5, and Teredo in the default policy only very recently. Because Teredo is not mentioned in RFC3484, I expect many other RFC3484=20 implementations do have the same issue. Unfortunately, even if they don't=20 have Teredo support themselves, they should still recognize the prefix for= =20 source address selection... I did write an I-D to allocate one new prefix, but then I realized that the= =20 revised RFC3484 draft work already mentioned it, so I did not bother=20 submitting it. In your particular case, did you try to add label 2001:0::/32 7 precedence 2001:0::/32 5 to /etc/gai.conf ? =2D-=20 R=C3=A9mi Denis-Courmont _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 03:16:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcbtJ-00024f-BV; Tue, 02 Oct 2007 03:10:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcbtG-00024R-FD for ietf@ietf.org; Tue, 02 Oct 2007 03:09:58 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcbtG-0001qF-18 for ietf@ietf.org; Tue, 02 Oct 2007 03:09:58 -0400 Received: from [163.117.139.34] ([163.117.139.34]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l92777Pb080709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Oct 2007 09:07:08 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20071001175000.7B93748C4@carter-zimmerman.suchdamage.org> References: <20071001175000.7B93748C4@carter-zimmerman.suchdamage.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Mon, 1 Oct 2007 22:17:45 +0200 To: Sam Hartman X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, score=0.4 required=3.5 tests=AWL,BAYES_00,ILJQX_SUBJ_HUH autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 1.9 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ietf@ietf.org Subject: Re: Would someone help the secretariat figure out why they cannot route to teredo addresses? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 1-okt-2007, at 19:50, Sam Hartman wrote: > This is annoying because glibc's source address selection algorithm > seems to prefer teredo addresses to v4 addresses. So, I get really > bad response times to www.ietf.org when using teredo. It would help if vendors implemented the RFC 3484 policy table so administrators can override this. (AFAIK, only (Free)BSD and Windows support this.) > Based on the responses to the ticket, it was not entirely clear if the > people at NSS understood how teredo differs from a normal IPV6 > address. I just don't have time to work with them to debug the > problem. > Is there someone out there with significant IPV6 experience who can > reproduce the problem and who would be willing to work with NSS to > resolve? I'm not currently in the position to test Teredo, but I suspect there is more going on. For instance, I can't reach the IETF or ARIN using 2001:1af8:2:5::2. The problem seems to be with OCCAID, which provides IPv6 connectivity to both. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 03:16:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icbrh-0001WN-79; Tue, 02 Oct 2007 03:08:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icbrf-0001M1-BC; Tue, 02 Oct 2007 03:08:19 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcbrO-0007rb-A6; Tue, 02 Oct 2007 03:08:08 -0400 Received: by dog.tcb.net (Postfix, from userid 0) id D0C77268722; Tue, 2 Oct 2007 01:07:46 -0600 (MDT) Received: from [166.128.166.36] (166.128.166.36 [166.128.166.36]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 02 Oct 2007 01:07:42 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=166.128.166.36; client-port=50280; client-dnsfail=166.128.166.36: name server failure; syn-fingerprint=65535:53:1:64:M1460,N,W0,N,N,T,S MacOS 10.4.8; data-bytes=0 In-Reply-To: <200710020324.l923OrwQ023453@drugs.dv.isc.org> References: <200710020324.l923OrwQ023453@drugs.dv.isc.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Danny McPherson Date: Tue, 2 Oct 2007 01:05:39 -0600 To: Mark Andrews X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: dnsop-chairs@ietf.org, ietf@ietf.org, secdir@mit.edu, fneves@registro.br, iesg@ietf.org, joao_damas@isc.org, Jeffrey Hutzelman Subject: Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 1, 2007, at 9:24 PM, Mark Andrews wrote: >> >> Note that in real deployments just this behavior has broken things >> on occasion, as many firewall and other such policy application =20 >> points >> assume things like DNS resolution will only be UDP/53 transactions. > > That assumption has always been wrong. Not in my experience. Actually, there are two separate things here. One, is implementation/ product, the other is configuration and device administration. I'm not sure how your average user would separate the two from a practical standpoint, and it really doesn't matter. I'm aware of at two products in the last few months that, in production deployment forced TCP switch-over, only to find that this broke name resolution completely for a large pool of subscribers. In addition, in my own experience, more often than not when folks clamp down firewall policies, in particular in enterprise or =20 "restricted" space, they often deny all TCP/53 to address spaces (in one case the culprit for the brokenness above). Another common place to see policies that block TCP/53 is roaming access points captive user environments. E.g., SSH tunneling over DNS was easy enough over UDP. To further support my statement, just google for +"firewall policy" +TCP/53 +DNS, here are a few examples: http://www.whitehats.ca/downloads/cerberus/Rick_Wanner_GCFW.pdf Service: The enabled service is DNS (domain-udp, port 53/udp). =20 Firewall-1=92s DNS service by default contains both domain-udp (53/udp) and domain-tcp (53/tcp). =20 We have removed domain- tcp from the object definition, on the grounds that we will not be =20 permitting zone transfers. It will be necessary to watch carefully since removing domain-tcp also means =20 that long dns-queries will not be supported. It is important to note that this will not work =20 unless =93Accept UDP replies=94 is enabled on the Firewall-1 Security Properties screen. Without =20 =93Accept UDP replies=94 enabled, the queries will still be allowed through the firewall, but the replies =20 will be dropped on the firewall. http://security.ucdavis.edu/basic_firewall_rules.pdf: Allow DNS (UDP 53) to internal DNS server =96 If the unit runs internal =20= DNS servers this rule is recommended. The rule is needed if a Windows Active Directory =20= server is hosted on the internal network. You must permit TCP 53 for zone transfer =20 capability, however this permission should not be applied by default. Right or wrong, it's quite common. > I would also dispute the "many" above. Most firewalls > actually handle the transition to TCP perfectly fine. There > are the odd few that are misconfigured. When that happens > people complain because nameservers resolution fails. Either > the dataset is "fixed" or the firewall is fixed. I'd be quite interested in any pointers you might have to empirical evidence supporting this position. I don't believe it's an odd few that are misconfigured, I believe it's often done as a conscious effort. -danny= _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 03:44:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IccBZ-0007Ou-Fs; Tue, 02 Oct 2007 03:28:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IccBX-0007IW-6m; Tue, 02 Oct 2007 03:28:51 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IccBW-0008PW-1w; Tue, 02 Oct 2007 03:28:51 -0400 Received: by dog.tcb.net (Postfix, from userid 0) id D7C61368074; Tue, 2 Oct 2007 01:28:49 -0600 (MDT) Received: from [166.128.166.36] (166.128.166.36 [166.128.166.36]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 02 Oct 2007 01:28:49 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=166.128.166.36; client-port=50335; client-dnsfail=166.128.166.36: name server failure; syn-fingerprint=65535:50:1:64:M1460,N,W0,N,N,T,S MacOS 10.4.8; data-bytes=0 In-Reply-To: <200710020255.l922tadC023029@drugs.dv.isc.org> References: <200710020255.l922tadC023029@drugs.dv.isc.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Danny McPherson Date: Tue, 2 Oct 2007 01:28:20 -0600 To: Mark Andrews X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: dnsop-chairs@ietf.org, ietf@ietf.org, secdir@mit.edu, fneves@registro.br, iesg@ietf.org, joao_damas@isc.org, Jeffrey Hutzelman Subject: Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 1, 2007, at 8:55 PM, Mark Andrews wrote: > > I'm not blaming the victim, I'm pointing out the contributory > negligence on behalf of the ISP that is supplying the > attacker bandwidth. > > BCP 38 is over 7 years old now. The time has past where you can > blame the hardware vendors for lack of support. The blame > now has to be squarely brought down on the ISP's that have failed > to deploy BCP 38. Really? How many ISPs are you aware of that have *decommissioned* every piece of routing gear in their network in the past 7 years? The ugly bit here is that routers usually are pushed further and further to the edge of the network, until they finally fall off. The closer to the edge they get to the edge, the less feature capability they usually have, while all the more you need them. Furthermore, it's pretty much impossible to explicitly filter based on sources from large peers with lots of routes and lots of churn, or ever large customers, for that matter. Dynamically generated feasible path RPF models are the best solution for this, but there's little (no?) support. And even those models are derived based on RIB data, which means route policy essentially dictates what you'll accept for both data plane and control plane. But wait, where's the authoritative source for who owns what prefixes, and who's permitted to originate/transit what prefixes? BTW: Even NIST "Guidelines on Firewalls and Firewall Policy "recommends blocking TCP/53, except for external secondaries. -danny _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 03:47:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IccOE-0002qx-HN; Tue, 02 Oct 2007 03:41:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IccOC-0002qC-3C; Tue, 02 Oct 2007 03:41:56 -0400 Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IccOA-0000Ik-Gl; Tue, 02 Oct 2007 03:41:56 -0400 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id l927fhWW067952; Tue, 2 Oct 2007 17:41:43 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200710020741.l927fhWW067952@drugs.dv.isc.org> To: Danny McPherson From: Mark Andrews In-reply-to: Your message of "Tue, 02 Oct 2007 01:05:39 CST." Date: Tue, 02 Oct 2007 17:41:43 +1000 X-Spam-Score: -1.4 (-) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: dnsop-chairs@ietf.org, ietf@ietf.org, secdir@mit.edu, fneves@registro.br, iesg@ietf.org, joao_damas@isc.org, Jeffrey Hutzelman Subject: Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > > On Oct 1, 2007, at 9:24 PM, Mark Andrews wrote: > > >> > >> Note that in real deployments just this behavior has broken things > >> on occasion, as many firewall and other such policy application =20 > >> points > >> assume things like DNS resolution will only be UDP/53 transactions. > > > > That assumption has always been wrong. > > Not in my experience. I repeat. The ASSUMPTION as ALWAYS been wrong. From day one the DNS specified fall back to TCP for QUERY. > Actually, there are two separate things here. One, is implementation/ > product, the other is configuration and device administration. I'm not > sure how your average user would separate the two from a practical > standpoint, and it really doesn't matter. > > I'm aware of at two products in the last few months that, in production > deployment forced TCP switch-over, only to find that this broke name > resolution completely for a large pool of subscribers. It still doesn't mean that many are badly configured only that some are badly configured. > In addition, in my own experience, more often than not when folks > clamp down firewall policies, in particular in enterprise or =20 > "restricted" > space, they often deny all TCP/53 to address spaces (in one case the > culprit for the brokenness above). And I presume they adjusted the policy once they discovered how idiotic it is. > Another common place to see policies that block TCP/53 is roaming > access points captive user environments. E.g., SSH tunneling over > DNS was easy enough over UDP. I didn't say that it didn't occur. Some people are stupid. > To further support my statement, just google for +"firewall policy" > +TCP/53 +DNS, here are a few examples: > > http://www.whitehats.ca/downloads/cerberus/Rick_Wanner_GCFW.pdf > > Service: The enabled service is DNS (domain-udp, port 53/udp). =20 > Firewall-1=92s DNS service by > default contains both domain-udp (53/udp) and domain-tcp (53/tcp). =20 > We have removed domain- > tcp from the object definition, on the grounds that we will not be =20 > permitting zone transfers. It will > be necessary to watch carefully since removing domain-tcp also means =20 > that long dns-queries will > not be supported. It is important to note that this will not work =20 > unless =93Accept UDP replies=94 is > enabled on the Firewall-1 Security Properties screen. Without =20 > =93Accept UDP replies=94 enabled, the > queries will still be allowed through the firewall, but the replies =20 > will be dropped on the firewall. So. It just means they intend to live dangerously. This policy will bite them at some point. > http://security.ucdavis.edu/basic_firewall_rules.pdf: > > Allow DNS (UDP 53) to internal DNS server =96 If the unit runs internal =20= > > DNS servers this > rule is recommended. The rule is needed if a Windows Active Directory =20= > > server is hosted > on the internal network. You must permit TCP 53 for zone transfer =20 > capability, however > this permission should not be applied by default. Someone should talk to ucdavis.edu and get this idiocy pulled. > Right or wrong, it's quite common. > > > I would also dispute the "many" above. Most firewalls > > actually handle the transition to TCP perfectly fine. There > > are the odd few that are misconfigured. When that happens > > people complain because nameservers resolution fails. Either > > the dataset is "fixed" or the firewall is fixed. > > I'd be quite interested in any pointers you might have to empirical > evidence supporting this position. I don't believe it's an odd few > that are misconfigured, I believe it's often done as a conscious > effort. Because there are lots of recursive and authoritative nameservers out there behind firewalls that get it right. I've seen many more complaints about UDP packets > 512 bytes being blocked than complaints about fallback to TCP failing. Most people actually do the right thing without thinking about it. The allow TCP out to anything this includes DNS servers. Most allow both UDP and TCP in to their nameservers. This is the silent majority. Mark > -danny= -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 03:53:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IccV3-0001RO-Sz; Tue, 02 Oct 2007 03:49:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IccV1-0001Pz-M6; Tue, 02 Oct 2007 03:48:59 -0400 Received: from dog.tcb.net ([64.78.150.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IccV1-0002t5-DV; Tue, 02 Oct 2007 03:48:59 -0400 Received: by dog.tcb.net (Postfix, from userid 0) id 2AAC0268739; Tue, 2 Oct 2007 01:48:59 -0600 (MDT) Received: from [166.128.166.36] (166.128.166.36 [166.128.166.36]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 02 Oct 2007 01:48:58 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=166.128.166.36; client-port=50549; client-dnsfail=166.128.166.36: name server failure; syn-fingerprint=65535:53:1:64:M1460,N,W0,N,N,T,S MacOS 10.4.8; data-bytes=0 In-Reply-To: <200710020741.l927fhWW067952@drugs.dv.isc.org> References: <200710020741.l927fhWW067952@drugs.dv.isc.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7494AF81-70CE-4F94-83A1-537401276949@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Date: Tue, 2 Oct 2007 01:48:36 -0600 To: Mark Andrews X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: dnsop-chairs@ietf.org, ietf@ietf.org, secdir@mit.edu, fneves@registro.br, iesg@ietf.org, joao_damas@isc.org, Jeffrey Hutzelman Subject: Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 2, 2007, at 1:41 AM, Mark Andrews wrote: > Someone should talk to ucdavis.edu and get this idiocy pulled. And NIST, and many many others.. > Because there are lots of recursive and authoritative > nameservers out there behind firewalls that get it right. > > I've seen many more complaints about UDP packets > 512 bytes > being blocked than complaints about fallback to TCP failing. > > Most people actually do the right thing without thinking > about it. The allow TCP out to anything this includes DNS > servers. > > Most allow both UDP and TCP in to their nameservers. This > is the silent majority. Again, any pointers empirical data along these lines would be appreciated. -danny _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 04:13:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IccnW-0005zf-JT; Tue, 02 Oct 2007 04:08:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IccnU-0005yC-VD; Tue, 02 Oct 2007 04:08:04 -0400 Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IccnT-00016m-A2; Tue, 02 Oct 2007 04:08:04 -0400 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id l9287xk9087813; Tue, 2 Oct 2007 18:07:59 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200710020807.l9287xk9087813@drugs.dv.isc.org> To: Danny McPherson From: Mark Andrews In-reply-to: Your message of "Tue, 02 Oct 2007 01:28:20 CST." Date: Tue, 02 Oct 2007 18:07:59 +1000 X-Spam-Score: -1.4 (-) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: dnsop-chairs@ietf.org, ietf@ietf.org, secdir@mit.edu, fneves@registro.br, iesg@ietf.org, joao_damas@isc.org, Jeffrey Hutzelman Subject: Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > > On Oct 1, 2007, at 8:55 PM, Mark Andrews wrote: > > > > I'm not blaming the victim, I'm pointing out the contributory > > negligence on behalf of the ISP that is supplying the > > attacker bandwidth. > > > > BCP 38 is over 7 years old now. The time has past where you can > > blame the hardware vendors for lack of support. The blame > > now has to be squarely brought down on the ISP's that have failed > > to deploy BCP 38. > > Really? How many ISPs are you aware of that have > *decommissioned* every piece of routing gear in their > network in the past 7 years? The ugly bit here is that > routers usually are pushed further and further to the > edge of the network, until they finally fall off. The > closer to the edge they get to the edge, the less > feature capability they usually have, while all the more > you need them. Again, its the ISP's *choice* to use such equipment. At some point someone that has been attacked will sue the connecting ISP's from which the packets originated and I wouldn't be suprised to see the ISP being fined or otherwise penalised. > Furthermore, it's pretty much impossible to explicitly > filter based on sources from large peers with lots of > routes and lots of churn, or ever large customers, for > that matter. Dynamically generated feasible path RPF > models are the best solution for this, but there's little > (no?) support. BCP 38 is about *everyone* filtering as close to the source as possible. You do your part and your peer does their part. > And even those models are derived based on RIB data, > which means route policy essentially dictates what you'll > accept for both data plane and control plane. But wait, > where's the authoritative source for who owns what > prefixes, and who's permitted to originate/transit what > prefixes? > > BTW: Even NIST "Guidelines on Firewalls and Firewall > Policy "recommends blocking TCP/53, except for > external secondaries. Even NIST can get it wrong. > -danny -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 06:50:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icf07-0003Ev-To; Tue, 02 Oct 2007 06:29:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icf04-0002mO-DW; Tue, 02 Oct 2007 06:29:12 -0400 Received: from mucmx01.ixos.de ([149.235.128.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Icezv-0004aG-2J; Tue, 02 Oct 2007 06:29:09 -0400 Received: from mucpm01.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l92AScj4018312; Tue, 2 Oct 2007 12:28:38 +0200 (MEST) Received: from MUCXGC2.opentext.net (mucxg04.opentext.net [149.235.128.138]) by mucpm01.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id l92ASZWh020391; Tue, 2 Oct 2007 06:28:35 -0400 (envelope-from tgondrom@opentext.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Oct 2007 12:28:33 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A786801AB1FF8@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir] draft-aboba-sg-experiment-02.txt Thread-Index: AcgEqA3naVV/pJLzSJCtHAt/6WjjogAMJKDw X-Priority: 5 Priority: Non-Urgent Importance: low From: "Tobias Gondrom" To: "Lakshminath Dondeti" X-Archived: msg.AAiaKdz:2007-10-02:mucpm01.smtp.dmz.opentext.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: narten@us.ibm.com, ietf@ietf.org, jari.arkko@ericsson.com, Bernard_Aboba@hotmail.com, secdir@mit.edu, iesg@ietf.org Subject: RE: [secdir] draft-aboba-sg-experiment-02.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi Lakshminath,=20 your comments solve my concerns, mostly.=20 I understand your reasons and actually am not sure I have a really = better idea. So please consider my comments rather as personal concerns, = not comments that need to be resolved:=20 #2: I still do not feel 100% comfortable with the fact that the SG will = introduce a new second extension after the second BOF; on the other = hand, as the SG is at the discretion of the AD, there should be no harm. #3: I fully understood the part with the "SG ... MUST NOT include = milestones relating to development of a protocol specification", but = actually let me envision the following scenario:=20 People start to work in a SG, e.g. on charter and requirements and as = they most probably also already have a solution in mind (e.g. they made = a prototype or even full implementation) they will in parallel prepare = the other drafts. Ok they can not track this via milestones, but maybe = this is not perceived as so critical by them and the current experiment = draft also actually allows them to submit I-Ds in the SG about protocols = etc. - just like a normal WG..... (and probably to submit such I-Ds = SHOULD NOT be forbidden in the experiment, as it can help to work on the = requirements when you have an example solution to look at, and actually = I would hate to stop people to think or work in any direction - just for = the sake of a process...) So you see, this distinction line between SG = and WG feels very faint to me and maybe might also initiate an = automatism to _always_ go from SG to WG, "because so much work has = already been done..." However, having that said, I believe that you can't make a process 100% = foolproof (at least not one that you actually want to really use in real = life) and hey that's what an experiment is for, so I will be fine to try = it.=20 Again as a summary: I think it's a great idea and would hum for = progressing the draft and the experiment.=20 - Tobias > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > Sent: Tuesday, October 02, 2007 5:55 AM > To: Tobias Gondrom > Cc: iesg@ietf.org; secdir@mit.edu; Bernard_Aboba@hotmail.com; > narten@us.ibm.com; jari.arkko@ericsson.com; ietf@ietf.org > Subject: Re: [secdir] draft-aboba-sg-experiment-02.txt >=20 > Hi Tobias, >=20 > Many thanks for your review. Please see inline for my thoughts on = your > observations. >=20 > On 10/1/2007 9:39 AM, Tobias Gondrom wrote: > > Hello, > > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should = treat > > these comments just like any other last call comments. > > > > The document described an RFC3933 experiment in forming a Study = Group > > prior to Working Group formation. As such I agree with the authors = that > > there are no additional specific security considerations as also > > discussed in RFC3933. > > > > > > Aside from the Security Review, I have three comments: > > > > 1. editorial comment to section 1: > > > > s/those who have no followed the/ those who have not followed the > We'll fix this in the revision. > > > > 2. comment to section 2: > > > > Section 2 states that: > > > > "If at any point...., including after a first or second BoF session, = ... > the > > IESG MAY propose that a Study Group be formed." > > > > This sounds to me like partially conflicting with RFC2418, which = clearly > > states that an absolute maximum of two BOFs are allowed for a topic. > > > > This would implicate that if a Study Group was formed after the = second > > BOF, it would have to directly lead to a WG (or be abandoned) as it = can > > not go back to BOF. > > > > I would propose to change this to that a Study Group may be = initiated > > after the first BOF but not after the second to prevent this = conflict. > > > > (The second BOF is already an extension and we should not add the = Study > > Group as a second extension to the system. People should be pretty = well > > prepared at a second BOF to get either a Yes or No -- and if they = are > not > > ready for a decision by then, another second extension may probably = also > > not help.) >=20 > My take is that after the SG it is a WG or nothing. The sponsoring = and > other ADs would have the opportunity to observe the SG in progress = just > as they would do a BoF and can assess whether to form a WG or not. >=20 > With that clarification, does the current wording sound alright? > > > > So, proposal to change the line in section 2 accordingly: > > > > s/including after a first or second BoF session/including after a = first > > BoF session > > > > I.e. if a first BOF does not lead to the anticipated results (WG: = yes/no > > decision), the appropriate mechanism for the AD should be to decide > > whether s/he wants to use this experiment or run straight with the > > second BOF as defined in the process. With the study group the = second > > BOF could be initiated after the Study Group has concluded if the AD > > does not want to go to WG directly without second BOF. > > > > 3. comment to section 3: > > > > In section 3 it is described that a study group shall have and run = the > > same infrastructure identical to a WG. > > > > I would not agree with this suggestion, but think it should be = limited > > to less than a WG. >=20 > It is in fact less than a WG. More specifically, "A Study Group = charter > MUST NOT include milestones > relating to development of a protocol specification." was included > to make it less than a WG. The limited lifetime is another = constraint. >=20 > The other processes are intentionally made similar so as to reuse our > current operational structures. >=20 > Does that clarification alleviate this concern? >=20 > regards, > Lakshminath >=20 > > > > Otherwise it might lead to false impressions, de-facto situations = and > > also prolong the work of the study group to finally get a "go" for a = WG, > > as they might consider this an already fully functional "lightweight > WG". > > > > > > Summary: > > > > I believe that this idea of a Study Group is a great idea that will = add > > a new tool for the AD for the situation that a BOF has not been > > satisfactory preparing a WG formation. > > > > However I would suggest to make sure to keep a clear distinction = between > > a WG and a study group, as they differ dramatically in the regard of > > role and acceptance by the IETF community. If they both look similar > > this might be misunderstood by people outside or new to the IETF. > > > > Greeting, Tobias > > > > > > > > > > > > ***__________________________________________* > > *****Tobias Gondrom* > > Head of Open Text Security Team > > Director, Product Security > > > > *****Open Text* > > Technopark 2 > > Werner-von-Siemens-Ring 20 > > D-85630 Grasbrunn > > > > Phone: +49 (0) 89 4629-1816 > > Mobile: +49 (0) 173 5942987 > > Telefax: +49 (0) 89 4629-33-1816 > > eMail: mailto:tobias.gondrom@opentext.com > > Internet: http://www.opentext.com/ > > > > Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, > > Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 = (0) 89 > > 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / = Registergericht: > > M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID = Number > > /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: = John > > Shackleton, Walter K=F6hler > > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 06:50:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcfBM-0007Zu-My; Tue, 02 Oct 2007 06:40:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcfBK-0007Q8-4n for ietf@ietf.org; Tue, 02 Oct 2007 06:40:50 -0400 Received: from firewall.drtvnet.cg ([83.229.14.242] helo=smtp.drtvnet.cg) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcfBC-0004oC-Q3 for ietf@ietf.org; Tue, 02 Oct 2007 06:40:50 -0400 Received: from DRTVnet1 (firewall.drtvnet.cg [172.29.11.1]) by smtp.drtvnet.cg (8.13.8/8.13.5) with SMTP id l92BdOCD027830; Tue, 2 Oct 2007 12:39:33 +0100 Message-ID: <03f001c804e0$92860060$6a01a8c0@DRTVnet1> From: "philemon" To: "Hannes Tschofenig" , "Keith Moore" References: <20070701150230.090F5233CB@coconut.itojun.org><4687DA5A.5020407@cs.utk.edu> <01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com> <198A730C2044DE4A96749D13E167AD37565E63@MOU1WNEXMB04.vcorp.ad.vrsn.com><4697D229.7070207@cs.utk.edu> <4697DC68.9060808@gmx.net> Date: Tue, 2 Oct 2007 11:39:47 +0100 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.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on localhost X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Stephen Sprunk , ietf@ietf.org, Paul Hoffman Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi All Just an input about the NAT issue handled here. The 'war' against NAT is senseless before succeeding the one against IPv4. I mean, as far as the v4 protocol runs on our networks, NAT will remain as a useful tool for those who need it, of course for specific applications. In developing countries for example where IPv6 entry is very slow -add to a scarcity of IPv4 addresses- we are always using NAT, and are happy to do so as: 1- No enough IPv4 addresses 2-No need for the specific applications for those networks 3-No alternative solution currently 'in the hands'. Thanks Philemon ----- Original Message ----- From: "Hannes Tschofenig" To: "Keith Moore" Cc: "Stephen Sprunk" ; ; "Paul Hoffman" Sent: Friday, July 13, 2007 9:11 PM Subject: Re: IPv4 to IPv6 transition > Hi Keith, > > Keith Moore wrote: >>> Most application protocols work just fine behind NAT. FTP works with >>> an ugly work-around. The main protocol that breaks down is SIP. >>> >>> >> >> there are a couple of problems with this analysis: >> >> one is that it considers only application protocols that are in >> widespread use. there are lots of applications that are used by limited >> communities that are nevertheless important. > > Namely? > > >> and of course, since NATs >> are so pervasive, most of the applications that are in widespread use >> have been made to work with NAT (often at tremendous expense, and >> reduced reliability). >> > Could you explain the tremendous expense a bit more? > > >> another problem is that it only considers current applications. a big >> part of the problem with NAT is that it inhibits the >> development/deployment of useful new applications. >> > > As Phillip stated, I don't see the problem with future applications. > Compare this with the security aspects that are taken care of much more > than before when developing new applications NAT traversal is just another > thing to think about as a protocol designer. > > Ciao > Hannes > >> Keith >> >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www1.ietf.org/mailman/listinfo/ietf >> > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 08:18:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icgb1-0004Nw-0D; Tue, 02 Oct 2007 08:11:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icgaz-0004Nc-K1 for ietf@ietf.org; Tue, 02 Oct 2007 08:11:25 -0400 Received: from smtp2.arin.net ([192.149.252.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Icgat-0007FF-FF for ietf@ietf.org; Tue, 02 Oct 2007 08:11:25 -0400 Received: by smtp2.arin.net (Postfix, from userid 5003) id 14D1F14479F; Tue, 2 Oct 2007 08:10:56 -0400 (EDT) Received: from ex.arin.net (ex.arin.net [192.149.252.56]) by smtp2.arin.net (Postfix) with ESMTP id 5BDEF144773; Tue, 2 Oct 2007 08:10:55 -0400 (EDT) Received: from EDAMAME.arin.net ([192.136.136.195]) by ex.arin.net ([192.149.252.56]) with mapi; Tue, 2 Oct 2007 08:11:51 -0400 From: Ray Plzak To: philemon , Hannes Tschofenig , Keith Moore Date: Tue, 2 Oct 2007 08:10:43 -0400 Thread-Topic: IPv4 to IPv6 transition Thread-Index: AcgE4is8hUfLVlRSR2SX3lLsmAurkwACubwA Message-ID: References: <20070701150230.090F5233CB@coconut.itojun.org><4687DA5A.5020407@cs.utk.edu> <01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com> <198A730C2044DE4A96749D13E167AD37565E63@MOU1WNEXMB04.vcorp.ad.vrsn.com><4697D229.7070207@cs.utk.edu> <4697DC68.9060808@gmx.net> <03f001c804e0$92860060$6a01a8c0@DRTVnet1> In-Reply-To: <03f001c804e0$92860060$6a01a8c0@DRTVnet1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Level: X-Spam-Status: No, hits=-73.1 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.63-arin1 X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: Stephen Sprunk , "ietf@ietf.org" , Paul Hoffman Subject: RE: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org The shortage of IPv4 addresses in developing countries in a red herring. Al= l one has to do is apply for them from the RIR. Getting a service provider = to route them is a different problem, especially when they profit from runn= ing your traffic through their NAT. Ray > -----Original Message----- > From: philemon [mailto:philemon@drtvnet.cg] > Sent: Tuesday, October 02, 2007 6:40 AM > To: Hannes Tschofenig; Keith Moore > Cc: Stephen Sprunk; ietf@ietf.org; Paul Hoffman > Subject: Re: IPv4 to IPv6 transition > > Hi All > > > > Just an input about the NAT issue handled here. The 'war' against NAT > is > senseless before succeeding the one against IPv4. I mean, as far as the > v4 > protocol runs on our networks, NAT will remain as a useful tool for > those > who need it, of course for specific applications. In developing > countries > for example where IPv6 entry is very slow -add to a scarcity of IPv4 > addresses- we are always using NAT, and are happy to do so as: > > 1- No enough IPv4 addresses > > 2-No need for the specific applications for those networks > > 3-No alternative solution currently 'in the hands'. > > > > Thanks > > > > Philemon > > > > > ----- Original Message ----- > From: "Hannes Tschofenig" > To: "Keith Moore" Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icgb1-0004Nw-0D; Tue, 02 Oct 2007 08:11:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icgaz-0004Nc-K1 for ietf@ietf.org; Tue, 02 Oct 2007 08:11:25 -0400 Received: from smtp2.arin.net ([192.149.252.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Icgat-0007FF-FF for ietf@ietf.org; Tue, 02 Oct 2007 08:11:25 -0400 Received: by smtp2.arin.net (Postfix, from userid 5003) id 14D1F14479F; Tue, 2 Oct 2007 08:10:56 -0400 (EDT) Received: from ex.arin.net (ex.arin.net [192.149.252.56]) by smtp2.arin.net (Postfix) with ESMTP id 5BDEF144773; Tue, 2 Oct 2007 08:10:55 -0400 (EDT) Received: from EDAMAME.arin.net ([192.136.136.195]) by ex.arin.net ([192.149.252.56]) with mapi; Tue, 2 Oct 2007 08:11:51 -0400 From: Ray Plzak To: philemon , Hannes Tschofenig , Keith Moore Date: Tue, 2 Oct 2007 08:10:43 -0400 Thread-Topic: IPv4 to IPv6 transition Thread-Index: AcgE4is8hUfLVlRSR2SX3lLsmAurkwACubwA Message-ID: References: <20070701150230.090F5233CB@coconut.itojun.org><4687DA5A.5020407@cs.utk.edu> <01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com> <198A730C2044DE4A96749D13E167AD37565E63@MOU1WNEXMB04.vcorp.ad.vrsn.com><4697D229.7070207@cs.utk.edu> <4697DC68.9060808@gmx.net> <03f001c804e0$92860060$6a01a8c0@DRTVnet1> In-Reply-To: <03f001c804e0$92860060$6a01a8c0@DRTVnet1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Level: X-Spam-Status: No, hits=-73.1 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.63-arin1 X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: Stephen Sprunk , "ietf@ietf.org" , Paul Hoffman Subject: RE: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org The shortage of IPv4 addresses in developing countries in a red herring. Al= l one has to do is apply for them from the RIR. Getting a service provider = to route them is a different problem, especially when they profit from runn= ing your traffic through their NAT. Ray > -----Original Message----- > From: philemon [mailto:philemon@drtvnet.cg] > Sent: Tuesday, October 02, 2007 6:40 AM > To: Hannes Tschofenig; Keith Moore > Cc: Stephen Sprunk; ietf@ietf.org; Paul Hoffman > Subject: Re: IPv4 to IPv6 transition > > Hi All > > > > Just an input about the NAT issue handled here. The 'war' against NAT > is > senseless before succeeding the one against IPv4. I mean, as far as the > v4 > protocol runs on our networks, NAT will remain as a useful tool for > those > who need it, of course for specific applications. In developing > countries > for example where IPv6 entry is very slow -add to a scarcity of IPv4 > addresses- we are always using NAT, and are happy to do so as: > > 1- No enough IPv4 addresses > > 2-No need for the specific applications for those networks > > 3-No alternative solution currently 'in the hands'. > > > > Thanks > > > > Philemon > > > > > ----- Original Message ----- > From: "Hannes Tschofenig" > To: "Keith Moore" > Cc: "Stephen Sprunk" ; ; "Paul > Hoffman" > > Sent: Friday, July 13, 2007 9:11 PM > Subject: Re: IPv4 to IPv6 transition > > > > Hi Keith, > > > > Keith Moore wrote: > >>> Most application protocols work just fine behind NAT. FTP works > with > >>> an ugly work-around. The main protocol that breaks down is SIP. > >>> > >>> > >> > >> there are a couple of problems with this analysis: > >> > >> one is that it considers only application protocols that are in > >> widespread use. there are lots of applications that are used by > limited > >> communities that are nevertheless important. > > > > Namely? > > > > > >> and of course, since NATs > >> are so pervasive, most of the applications that are in widespread > use > >> have been made to work with NAT (often at tremendous expense, and > >> reduced reliability). > >> > > Could you explain the tremendous expense a bit more? > > > > > >> another problem is that it only considers current applications. a > big > >> part of the problem with NAT is that it inhibits the > >> development/deployment of useful new applications. > >> > > > > As Phillip stated, I don't see the problem with future applications. > > Compare this with the security aspects that are taken care of much > more > > than before when developing new applications NAT traversal is just > another > > thing to think about as a protocol designer. > > > > Ciao > > Hannes > > > >> Keith > >> > >> > >> _______________________________________________ > >> Ietf mailing list > >> Ietf@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ietf > >> > > > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf > > > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 08:18:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcgZD-00035D-M8; Tue, 02 Oct 2007 08:09:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcgZB-00034x-IW for ietf@ietf.org; Tue, 02 Oct 2007 08:09:33 -0400 Received: from aharp.ittns.northwestern.edu ([129.105.153.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcgZ1-0007AP-EV for ietf@ietf.org; Tue, 02 Oct 2007 08:09:29 -0400 Received: from dsl017-022-071.chi1.dsl.speakeasy.net (aharp [127.0.0.1]) by aharp.ittns.northwestern.edu (smtpd) with SMTP id 16C20136C82 for ; Tue, 2 Oct 2007 07:09:03 -0500 (CDT) Date: Tue, 2 Oct 2007 07:09:02 -0500 From: John Kristoff To: ietf@ietf.org In-Reply-To: <7494AF81-70CE-4F94-83A1-537401276949@tcb.net> References: <200710020741.l927fhWW067952@drugs.dv.isc.org> <7494AF81-70CE-4F94-83A1-537401276949@tcb.net> X-Mailer: Sylpheed version 2.2.2 (GTK+ 2.8.12; i386-apple-darwin8.5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20071002120903.16C20136C82@aharp.ittns.northwestern.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Tue, 2 Oct 2007 01:48:36 -0600 Danny McPherson wrote: > Again, any pointers empirical data along tutk.edu> > Cc: "Stephen Sprunk" ; ; "Paul > Hoffman" > > Sent: Friday, July 13, 2007 9:11 PM > Subject: Re: IPv4 to IPv6 transition > > > > Hi Keith, > > > > Keith Moore wrote: > >>> Most application protocols work just fine behind NAT. FTP works > with > >>> an ugly work-around. The main protocol that breaks down is SIP. > >>> > >>> > >> > >> there are a couple of problems with this analysis: > >> > >> one is that it considers only application protocols that are in > >> widespread use. there are lots of applications that are used by > limited > >> communities that are nevertheless important. > > > > Namely? > > > > > >> and of course, since NATs > >> are so pervasive, most of the applications that are in widespread > use > >> have been made to work with NAT (often at tremendous expense, and > >> reduced reliability). > >> > > Could you explain the tremendous expense a bit more? > > > > > >> another problem is that it only considers current applications. a > big > >> part of the problem with NAT is that it inhibits the > >> development/deployment of useful new applications. > >> > > > > As Phillip stated, I don't see the problem with future applications. > > Compare this with the security aspects that are taken care of much > more > > than before when developing new applications NAT traversal is just > another > > thing to think about as a protocol designer. > > > > Ciao > > Hannes > > > >> Keith > >> > >> > >> _______________________________________________ > >> Ietf mailing list > >> Ietf@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ietf > >> > > > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf > > > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 08:18:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcgZD-00035D-M8; Tue, 02 Oct 2007 08:09:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcgZB-00034x-IW for ietf@ietf.org; Tue, 02 Oct 2007 08:09:33 -0400 Received: from aharp.ittns.northwestern.edu ([129.105.153.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcgZ1-0007AP-EV for ietf@ietf.org; Tue, 02 Oct 2007 08:09:29 -0400 Received: from dsl017-022-071.chi1.dsl.speakeasy.net (aharp [127.0.0.1]) by aharp.ittns.northwestern.edu (smtpd) with SMTP id 16C20136C82 for ; Tue, 2 Oct 2007 07:09:03 -0500 (CDT) Date: Tue, 2 Oct 2007 07:09:02 -0500 From: John Kristoff To: ietf@ietf.org In-Reply-To: <7494AF81-70CE-4F94-83A1-537401276949@tcb.net> References: <200710020741.l927fhWW067952@drugs.dv.isc.org> <7494AF81-70CE-4F94-83A1-537401276949@tcb.net> X-Mailer: Sylpheed version 2.2.2 (GTK+ 2.8.12; i386-apple-darwin8.5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20071002120903.16C20136C82@aharp.ittns.northwestern.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Tue, 2 Oct 2007 01:48:36 -0600 Danny McPherson wrote: > Again, any pointers empirical data along these lines would > be appreciated. I said this awhile back: "As a datapoint I ran some tests against a reasonably diverse and sizeable TLD zone I work with in another forum. I queried the name servers listed in the parent to see if I could successfuly query them for their corresponding domain name they are configured for using TCP. Out of about 9,300 unique name servers I failed to receive any answer from about 1700 of them. That is a bit more than an 18% failure rate." I think I overcompensated as I later found what looked like BIND 8 servers being unresponsive for multiple TCP queries in queue. I let the numbers stay, since the percentage of those servers were fairly small and, well, they were BIND 8 and probably have other problems anyway. :) John _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf hese lines would > be appreciated. I said this awhile back: "As a datapoint I ran some tests against a reasonably diverse and sizeable TLD zone I work with in another forum. I queried the name servers listed in the parent to see if I could successfuly query them for their corresponding domain name they are configured for using TCP. Out of about 9,300 unique name servers I failed to receive any answer from about 1700 of them. That is a bit more than an 18% failure rate." I think I overcompensated as I later found what looked like BIND 8 servers being unresponsive for multiple TCP queries in queue. I let the numbers stay, since the percentage of those servers were fairly small and, well, they were BIND 8 and probably have other problems anyway. :) John _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 08:58:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IchAv-0001Gj-Eq; Tue, 02 Oct 2007 08:48:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IchAu-0001GW-6T for ietf@ietf.org; Tue, 02 Oct 2007 08:48:32 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IchAo-0008Vx-QT for ietf@ietf.org; Tue, 02 Oct 2007 08:48:32 -0400 Received: from [205.205.80.243] by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IchAI-0008hC-SW; Tue, 02 Oct 2007 12:47:56 +0000 In-Reply-To: <4700B9C6.6040202@piuha.net> References: <02c601c7feef$b6460730$6702a8c0@china.huawei.com> <4700B9C6.6040202@piuha.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <39B17A43-056A-4A67-A69F-D3669EEA3C97@ca.afilias.info> Content-Transfer-Encoding: 7bit From: Joe Abley Date: Tue, 2 Oct 2007 08:46:42 -0400 To: Jari Arkko X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 6man-chairs@tools.ietf.org, 'IETF discussion list' , secdir@mit.edu, tim.polk@nist.gov, gnn@neville-neil.com, 'Sam Hartman' , psavola@funet.fi Subject: Re: secid review of draft-ietf-ipv6-deprecate-rh0-01 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 1-Oct-2007, at 0511, Jari Arkko wrote: > Hi David, and thanks for your review. Inline: > >> As such, the whole document is a security consideration. The >> vulnerability appears well-documented, and the guidelines for >> handling >> the deprecated RH0 are clear. > > Good. Just by-the-by, I noticed the first reports of peoples' "block-rh0" filters in live production networks taking hits yesterday. The notes I saw showed periods of low-volume, low-frequency packets with RH0, and also periods in which the traffic volume was noticeably higher. The reports I saw featured source addresses in CERNET in China. It was not obvious whether those had been spoofed. It is of course difficult go gauge the motivation for sending the packets when you're on the receiving end. However, I thought it noteworthy that such things had been seen, recently, in the wild. Joe _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 09:10:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IchRq-0002NR-0M; Tue, 02 Oct 2007 09:06:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IchRn-0001xL-6v for ietf@ietf.org; Tue, 02 Oct 2007 09:05:59 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IchRn-0003Zx-10 for ietf@ietf.org; Tue, 02 Oct 2007 09:05:59 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 11A041EE24A; Tue, 2 Oct 2007 09:05:58 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Begkmn2n5tuJ; Tue, 2 Oct 2007 09:05:55 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 017501EE245; Tue, 2 Oct 2007 09:05:41 -0400 (EDT) Message-ID: <47024223.7000508@cs.utk.edu> Date: Tue, 02 Oct 2007 09:05:39 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Ray Plzak References: <20070701150230.090F5233CB@coconut.itojun.org><4687DA5A.5020407@cs.utk.edu> <01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com> <198A730C2044DE4A96749D13E167AD37565E63@MOU1WNEXMB04.vcorp.ad.vrsn.com><4697D229.7070207@cs.utk.edu> <4697DC68.9060808@gmx.net> <03f001c804e0$92860060$6a01a8c0@DRTVnet1> In-Reply-To: X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Stephen Sprunk , "ietf@ietf.org" , Paul Hoffman Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Ray Plzak wrote: > The shortage of IPv4 addresses in developing countries in a red herring. that has to rank as one of the most bizarre statements that's ever been made on the ietf list. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 09:38:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IchsR-0001i5-JY; Tue, 02 Oct 2007 09:33:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IchsP-0001cG-Gf for ietf@ietf.org; Tue, 02 Oct 2007 09:33:29 -0400 Received: from [2001:630:d0:f102:230:48ff:fe77:96e] (helo=owl.ecs.soton.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IchsJ-00027o-16 for ietf@ietf.org; Tue, 02 Oct 2007 09:33:29 -0400 X-ECS-MailScanner-Watermark: 1191936788.18201@1Ty3jBz09c4M7TDz5Jdklg Received: from goose.ecs.soton.ac.uk (goose.ecs.soton.ac.uk [152.78.68.131]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id l92DX7Lm014848 for ; Tue, 2 Oct 2007 14:33:07 +0100 X-ECS-MailScanner-Watermark: 1191936635.55197@0uWqjtumrgR6du7SUGbqUg Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe59:5f12]) by goose.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id l92DUYQL010016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Oct 2007 14:30:34 +0100 Received: from login.ecs.soton.ac.uk (localhost.localdomain [127.0.0.1]) by login.ecs.soton.ac.uk (8.13.8/8.11.6) with ESMTP id l92DW1A5001614 for ; Tue, 2 Oct 2007 14:32:01 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.13.8/8.13.8/Submit) id l92DW1Ej001613 for ietf@ietf.org; Tue, 2 Oct 2007 14:32:01 +0100 Date: Tue, 2 Oct 2007 14:32:01 +0100 From: Tim Chown To: "ietf@ietf.org" Message-ID: <20071002133200.GI14394@login.ecs.soton.ac.uk> Mail-Followup-To: "ietf@ietf.org" References: <01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com> <4697DC68.9060808@gmx.net> <03f001c804e0$92860060$6a01a8c0@DRTVnet1> <47024223.7000508@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47024223.7000508@cs.utk.edu> User-Agent: Mutt/1.4.2.2i X-ECS-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote: > Ray Plzak wrote: > > The shortage of IPv4 addresses in developing countries in a red herring. > that has to rank as one of the most bizarre statements that's ever been > made on the ietf list. More of an ostrich than a herring? .="""=._ / ., .`. /__(,_.-' || ` /| || / | || \| || ~~~~~ ~ |\ ~~!)~~~~~~~ Tim _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 09:54:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ici6U-0003U3-W6; Tue, 02 Oct 2007 09:48:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ici6T-0003SQ-50 for ietf@ietf.org; Tue, 02 Oct 2007 09:48:01 -0400 Received: from smtp2.arin.net ([192.149.252.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ici6P-000588-Tn for ietf@ietf.org; Tue, 02 Oct 2007 09:47:58 -0400 Received: by smtp2.arin.net (Postfix, from userid 5003) id A86AB144773; Tue, 2 Oct 2007 09:47:47 -0400 (EDT) Received: from ex.arin.net (ex.arin.net [192.149.252.56]) by smtp2.arin.net (Postfix) with ESMTP id 7C2FF1447A9; Tue, 2 Oct 2007 09:47:46 -0400 (EDT) Received: from EDAMAME.arin.net ([192.136.136.195]) by ex.arin.net ([192.149.252.56]) with mapi; Tue, 2 Oct 2007 09:48:42 -0400 From: Ray Plzak To: Keith Moore Date: Tue, 2 Oct 2007 09:47:33 -0400 Thread-Topic: IPv4 to IPv6 transition Thread-Index: AcgE9PyifdCpQz4ZSsyJyCTdQ4qxMQABcP4w Message-ID: References: <20070701150230.090F5233CB@coconut.itojun.org><4687DA5A.5020407@cs.utk.edu> <01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com> <198A730C2044DE4A96749D13E167AD37565E63@MOU1WNEXMB04.vcorp.ad.vrsn.com><4697D229.7070207@cs.utk.edu> <4697DC68.9060808@gmx.net> <03f001c804e0$92860060$6a01a8c0@DRTVnet1> <47024223.7000508@cs.utk.edu> In-Reply-To: <47024223.7000508@cs.utk.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Level: X-Spam-Status: No, hits=-73.1 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.63-arin1 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Stephen Sprunk , "ietf@ietf.org" , Paul Hoffman Subject: RE: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org should have been "is" > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Tuesday, October 02, 2007 9:06 AM > To: Ray Plzak > Cc: philemon; Hannes Tschofenig; Stephen Sprunk; ietf@ietf.org; Paul > Hoffman > Subject: Re: IPv4 to IPv6 transition > > Ray Plzak wrote: > > The shortage of IPv4 addresses in developing countries in a red > herring. > that has to rank as one of the most bizarre statements that's ever been > made on the ietf list. > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 09:54:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ici6l-0003kx-8l; Tue, 02 Oct 2007 09:48:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ici6k-0003kr-8V for ietf@ietf.org; Tue, 02 Oct 2007 09:48:18 -0400 Received: from smtp2.arin.net ([192.149.252.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ici6e-0002bb-4T for ietf@ietf.org; Tue, 02 Oct 2007 09:48:18 -0400 Received: by smtp2.arin.net (Postfix, from userid 5003) id EAE6A144655; Tue, 2 Oct 2007 09:47:46 -0400 (EDT) Received: from ex.arin.net (ex.arin.net [192.149.252.56]) by smtp2.arin.net (Postfix) with ESMTP id 6FE0A144655; Tue, 2 Oct 2007 09:47:46 -0400 (EDT) Received: from EDAMAME.arin.net ([192.136.136.195]) by ex.arin.net ([192.149.252.56]) with mapi; Tue, 2 Oct 2007 09:48:42 -0400 From: Ray Plzak To: Tim Chown , "ietf@ietf.org" Date: Tue, 2 Oct 2007 09:47:02 -0400 Thread-Topic: IPv4 to IPv6 transition Thread-Index: AcgE+ZdcZrossUUXS6atqpO5kdVXxgAAKP7w Message-ID: References: <01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com> <4697DC68.9060808@gmx.net> <03f001c804e0$92860060$6a01a8c0@DRTVnet1> <47024223.7000508@cs.utk.edu> <20071002133200.GI14394@login.ecs.soton.ac.uk> In-Reply-To: <20071002133200.GI14394@login.ecs.soton.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Level: X-Spam-Status: No, hits=-73.1 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.63-arin1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: RE: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Head in the sand is substituting the statement "shortage of IP addresses" f= or the condition of the inability to use the addresses (take your pick when= it comes to infrastructure deficiencies). Ray > -----Original Message----- > From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] > Sent: Tuesday, October 02, 2007 9:32 AM > To: ietf@ietf.org > Subject: Re: IPv4 to IPv6 transition > > On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote: > > Ray Plzak wrote: > > > The shortage of IPv4 addresses in developing countries in a red > herring. > > that has to rank as one of the most bizarre statements that's ever > been > > made on the ietf list. > > More of an ostrich than a herring? > > > .=3D"""=3D._ > / ., .`. > /__(,_.-' || > ` /| || > / | || > \| || > ~~~~~ ~ |\ ~~!)~~~~~~~ > > > Tim > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 10:23:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IciT5-0007nM-Lq; Tue, 02 Oct 2007 10:11:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IciSy-0007gG-Rg; Tue, 02 Oct 2007 10:11:16 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IciSx-00032W-PR; Tue, 02 Oct 2007 10:11:16 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l92EBBOr011646; Tue, 2 Oct 2007 17:11:11 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l92EBAls011643; Tue, 2 Oct 2007 17:11:11 +0300 Date: Tue, 2 Oct 2007 17:11:10 +0300 (EEST) From: Pekka Savola To: ietf@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4447/Tue Oct 2 01:02:09 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00, TW_SV, TW_VW autolearn=no version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on otso.netcore.fi X-Spam-Score: -1.4 (-) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tsvwg@ietf.org Subject: Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Mon, 1 Oct 2007, The IESG wrote: > The IESG has received a request from the Transport Area Working Group WG > (tsvwg) to consider the following document: > > - 'Aggregation of DiffServ Service Classes ' > as an Informational RFC DiffServ Pool 1 codepoints require Standards Action [1]. While this document doesn't define new ones (because there aren't any), it defines how one should configure the treatment for each and every Pool 1 codepoint in the network. Therefore in spirit it specifies DSCP codepoint behaviour and how those should be used. As such I believe this document is inappropriate as an Informational RFC. It is not clear that consensus in the IETF and deployments is strong enough to approve/recommend any specific treatment for standards track DSCP values. If this work were to proceed, I suggest that first RFC 4594, which this document builds on, would attain IETF consensus by following the standards process for publication as a BCP. [1] http://www.iana.org/assignments/dscp-registry -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 10:51:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icivp-0005UI-7y; Tue, 02 Oct 2007 10:41:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icivm-0005Og-2I; Tue, 02 Oct 2007 10:41:02 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icivl-000648-QG; Tue, 02 Oct 2007 10:41:01 -0400 Received: from [192.168.1.2] (c-69-250-218-72.hsd1.md.comcast.net[69.250.218.72]) by comcast.net (rwcrmhc11) with SMTP id <20071002144100m11003lkiue>; Tue, 2 Oct 2007 14:41:00 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <67602DA7-6B73-422C-95D3-7D216E0F388F@g11.org.uk> Content-Transfer-Encoding: 7bit From: ken carlberg Date: Tue, 2 Oct 2007 10:40:57 -0400 To: Pekka Savola X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ietf@ietf.org, tsvwg@ietf.org Subject: Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 2, 2007, at 10:11 AM, Pekka Savola wrote: > It is not clear that consensus in the IETF and deployments is > strong enough to approve/recommend any specific treatment for > standards track DSCP values. could you expand on this observation? -ken _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 11:19:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcjPx-0005n0-HV; Tue, 02 Oct 2007 11:12:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcjPw-0005mu-Ok for ietf@ietf.org; Tue, 02 Oct 2007 11:12:12 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcjPw-0006n0-ER for ietf@ietf.org; Tue, 02 Oct 2007 11:12:12 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l92F55Zq002424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2007 10:05:06 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l92F55Rm003693; Tue, 2 Oct 2007 10:05:05 -0500 (CDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l92F4j9n002598; Tue, 2 Oct 2007 10:04:54 -0500 (CDT) Received: from XCH-SW-1V1.sw.nos.boeing.com ([129.172.192.171]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Oct 2007 08:04:47 -0700 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" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Oct 2007 08:04:02 -0700 Message-ID: <8E5250A6F98050468B5E54ED6E1956E90B8DD27C@XCH-SW-1V1.sw.nos.boeing.com> In-Reply-To: <4701BC66.5000107@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo()and searching) Thread-Index: AcgEpZzijivY6Qe2T6yenNcPICW+jAAXyt5Q References: <20071002010844.0E018233E8@coconut.itojun.org> <4701BC66.5000107@cs.utk.edu> From: "Gorsic, Bonnie L" To: "Keith Moore" , "Jun-ichiro itojun Hagino" X-OriginalArrivalTime: 02 Oct 2007 15:04:47.0527 (UTC) FILETIME=[92C2BB70:01C80505] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ietf@ietf.org, 200709270133.l8R1XuB6060071@drugs.dv.isc.org Subject: RE: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo()and searching) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org It seems that policy should be scenario / use case / mission dependent, and consequently apply to a number of applications. (And thus be application independent).=20 Bonnie L. Gorsic Technical Fellow SoS Architecture & Engineering 714-762-4906 (desk) -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu]=20 Sent: Monday, October 01, 2007 8:35 PM To: Jun-ichiro itojun Hagino Cc: ietf@ietf.org; 200709270133.l8R1XuB6060071@drugs.dv.isc.org Subject: Re: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo()and searching) Jun-ichiro itojun Hagino wrote: >> What a timely thread. >> >> I've recently concluded that we need an extension to getaddrinfo()=20 >> along these lines, but I'm looking for somewhat tighter and more=20 >> generic semantics. >> >> My proposal is to add an AI_SECURE_CANONNAME flag with the following >> semantics: >> =20 > > do not try to implement policy into applications. you will end up > forced to (?) rewrite every existing applications. > =20 perhaps, but having the policy be application-independent doesn't make sense either. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 11:19:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcjMn-0001xv-53; Tue, 02 Oct 2007 11:08:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcjMk-0001nj-SI for ietf@ietf.org; Tue, 02 Oct 2007 11:08:54 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcjMk-0004LM-FS for ietf@ietf.org; Tue, 02 Oct 2007 11:08:54 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id D7B0A233ED; Wed, 3 Oct 2007 00:08:45 +0900 (JST) To: ietf@ietf.org In-Reply-To: Your message of "Tue, 2 Oct 2007 09:24:48 +0300" <200710020924.49180.remi.denis-courmont@nokia.com> References: <200710020924.49180.remi.denis-courmont@nokia.com> X-Mailer: Cue version 0.8 (070521-1856/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Message-Id: <20071002150845.D7B0A233ED@coconut.itojun.org> Date: Wed, 3 Oct 2007 00:08:45 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: -0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: Re: Would someone help the secretariat figure out why they cannot route to teredo addresses? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > Le Monday 01 October 2007 20:50:00 ext Sam Hartman, vous avez $(D+1(Bcrit: > > Hi. I opened a ticket with the secretariat a few weeks ago > > complaining that I cannot reach www.ietf.org using a teredo address > > either allocated through the Microsoft Teredo server or the Debian > > teredo server. > > > > This is annoying because glibc's source address selection algorithm > > seems to prefer teredo addresses to v4 addresses. So, I get really > > bad response times to www.ietf.org when using teredo. > > To make a long short, that depends on your glibc version. As far as I > remember, RFC3484 was implemented in version 2.4. Configurable policy in > version 2.5, and Teredo in the default policy only very recently. this really shows that the approaches with policy table is very against of KISS principle... itojun _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 12:11:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ick8J-0007P1-3V; Tue, 02 Oct 2007 11:58:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ick8H-0007Ne-GW for ietf@ietf.org; Tue, 02 Oct 2007 11:58:01 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ick8B-0007fs-3f for ietf@ietf.org; Tue, 02 Oct 2007 11:57:55 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A24B787315; Tue, 2 Oct 2007 11:57:54 -0400 (EDT) To: ietf@ietf.org Message-Id: <20071002155754.A24B787315@mercury.lcs.mit.edu> Date: Tue, 2 Oct 2007 11:57:54 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: jnc@mercury.lcs.mit.edu Subject: Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > From: Danny McPherson > where's the authoritative source for who owns what prefixes This, one could imagining putting together. > and who's permitted to originate/transit what prefixes? This is a whole different kettle of bits. For one thing, there's no guaranteed-uniquely-definitive answer: entity A might have one idea of how it wants packets to flow from it to a given other entity B (say, 'don't use provider X because we despise them'), but entity B might disagree. Who should win that dispute? So the whole notion of 'allowed to transit' is a potential tussle space; mind, I'm not saying there always will be this sort of issue, but it's *possible*. Second, you're talking about potentially orders of magnitude more data: for each destination, there are worldwide likely hundreds (or more) of ISP's which are likely to be viable backbone transits. (By 'backbone transit', I mean ISP's/AS's which are not even directly connected to the organization which is the source or destination of the packets; e.g. customer A is connected to ISP p which is connected to ISP q which is connected to ISP r which is connected to customer B; q is a 'backbone transit'.) With ISP's which are directly connected with a customer, one can assume that there's an implicit authorization, but what about steps past that? If one further assumes that by p connecting to q, p is transitively authorizing q (with respect to A), then that can be done with straightforward (albeit complex and expensive) security on routing. However, if you go that way, then you lose the ability for A to make assertions about which q's are not acceptable. If you add that back in as a policy knob, then you're back to "potentially orders of magnitude more data". Noel _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 12:52:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ickns-0000S3-Vr; Tue, 02 Oct 2007 12:41:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icknr-0000No-ES; Tue, 02 Oct 2007 12:40:59 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ickng-0006sO-9k; Tue, 02 Oct 2007 12:40:54 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 01E1948C4; Tue, 2 Oct 2007 12:40:31 -0400 (EDT) From: Sam Hartman To: Joao Damas References: <200709281015.l8SAFwfq087916@bartok.nlnetlabs.nl> <3B1D547E-0F40-4A6D-B786-EB765E58A7F2@isc.org> Date: Tue, 02 Oct 2007 12:40:31 -0400 In-Reply-To: <3B1D547E-0F40-4A6D-B786-EB765E58A7F2@isc.org> (Joao Damas's message of "Fri, 28 Sep 2007 13:20:53 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: dnsop@ietf.org, Jaap Akkerhuis , ietf@ietf.org Subject: Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>>>> "Joao" == Joao Damas writes: Joao> It does indeed as Stephane pointed out. Opening up your Joao> resolver so you can server roaming users, without further Joao> protection, is, at best, naive. I'd appreciate it if you took Paul's comments a lot more seriously and looked at whether the dnsop view on this issue extends to other parts of the ietf. To the extent that it does not, please engage in a discussion designed to build consensus rather than assertions that someone who disagrees with you is naive. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 12:58:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ickyy-0005Qc-FK; Tue, 02 Oct 2007 12:52:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ickyw-000563-Cc for ietf@ietf.org; Tue, 02 Oct 2007 12:52:26 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ickyw-0001WI-4l for ietf@ietf.org; Tue, 02 Oct 2007 12:52:26 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id BBA221EE1F6; Tue, 2 Oct 2007 12:52:24 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HylXJpS5leDD; Tue, 2 Oct 2007 12:52:22 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 89FDC1EE1F4; Tue, 2 Oct 2007 12:52:15 -0400 (EDT) Message-ID: <4702773D.8010606@cs.utk.edu> Date: Tue, 02 Oct 2007 12:52:13 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: "Gorsic, Bonnie L" References: <20071002010844.0E018233E8@coconut.itojun.org> <4701BC66.5000107@cs.utk.edu> <8E5250A6F98050468B5E54ED6E1956E90B8DD27C@XCH-SW-1V1.sw.nos.boeing.com> In-Reply-To: <8E5250A6F98050468B5E54ED6E1956E90B8DD27C@XCH-SW-1V1.sw.nos.boeing.com> X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ietf@ietf.org, 200709270133.l8R1XuB6060071@drugs.dv.isc.org Subject: Re: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo()and searching) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Gorsic, Bonnie L wrote: > It seems that policy should be scenario / use case / mission dependent, > and consequently apply to a number of applications. (And thus be > application independent). > it's normal for policy to be different from one application to another. some applications are permitted by policy, others are forbidden, others are permitted with restrictions. also, it is difficult to generalize policy specification to the point that it can be independent of all applications, because sometimes there is a subtle interaction between policy and the application. for example, many sites have mail filtering policies that hinge on subtleties of SMTP protocol responses and DNS query results. it doesn't make sense to try to specify those in an application-independent fashion. that said, a coarse specification of policy that could be applied to some applications would still be useful. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 14:07:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iclum-0000mZ-8d; Tue, 02 Oct 2007 13:52:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icluc-0000eg-0R; Tue, 02 Oct 2007 13:52:02 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcluU-00011e-O5; Tue, 02 Oct 2007 13:51:59 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6474748C4; Tue, 2 Oct 2007 13:51:37 -0400 (EDT) From: Sam Hartman To: Brian E Carpenter References: <468DECAD.1000203@gmail.com> Date: Tue, 02 Oct 2007 13:51:37 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: IETF discussion list , iesg@ietf.org Subject: Re: Draft ION about our rules in practice X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Brian, I'm reviewing your document for approval. I think there are a few places where you overstep the goal of documenting practice and attempt to change RFC 2026. In particular you say with regard to ASes: The community really doesn't have the habit of writing this sort of separate AS; it's rare, and very rare in WG charters. In fact, an AS of this style doesn't really fit in today's document taxonomy - it has more significance than an Informational document, but doesn't belong on the standards track because it can't be implemented and tested in itself. I don't think you can say something as strong as ASes don't belong on the standards track. RFC 2026 disagrees with you; you quote this later in your document. Instead, perhaps saying something like "The IETF has been reluctant to place an AS on the standards track." The rest of the document looks great. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 16:06:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icnk8-0007YD-5j; Tue, 02 Oct 2007 15:49:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icnk6-0007Xy-37 for ietf@ietf.org; Tue, 02 Oct 2007 15:49:18 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icnk5-0007Ld-N0 for ietf@ietf.org; Tue, 02 Oct 2007 15:49:17 -0400 Received: from centralmail4brm.Central.Sun.COM ([129.147.62.198]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l92JnHBt003201 for ; Tue, 2 Oct 2007 19:49:17 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l92JnGJ4018394 for ; Tue, 2 Oct 2007 13:49:17 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l92JnG3F018095; Tue, 2 Oct 2007 14:49:16 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l92JnGiq018094; Tue, 2 Oct 2007 14:49:16 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 2 Oct 2007 14:49:16 -0500 From: Nicolas Williams To: ietf@ietf.org Message-ID: <20071002194915.GR11376@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i X-Spam-Score: 2.2 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: Re: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo() and searching) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > do not try to implement policy into applications. you will end up > forced to (?) rewrite every existing applications. I would expect most applications to use only AI_SECURE_CANONNAME or AI_CANONNAME_SEARCH_DEFAULT. AI_CANONNAME_SEARCH_DEFAULT would come with a system-wide knob attached. But perhaps we should just say that AI_SECURE_CANONNAME should behave like what I called AI_CANONNAME_SEARCH_DEFAULT. Some applications might offer app-specific configuration knobs to specify the use of any of the other AI_CANONNAME_SEARCH_* flags. _Most_ apps would not. The availability of choices at the API level != a plethora of application knobs, just the possibility thereof. Nico -- _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 16:45:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcoX5-0003ZS-UK; Tue, 02 Oct 2007 16:39:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcoX3-0003Z9-Ir for ietf@ietf.org; Tue, 02 Oct 2007 16:39:53 -0400 Received: from fk-out-0910.google.com ([209.85.128.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcoWx-0005P9-Ap for ietf@ietf.org; Tue, 02 Oct 2007 16:39:53 -0400 Received: by fk-out-0910.google.com with SMTP id z23so4456398fkz for ; Tue, 02 Oct 2007 13:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=IdiXu7sjFNsSiAQR1K35a0GI6Hb8kXJnRIw87qZBWt0=; b=mEcDUNjKXrKvpg1qXVMkfVKrnWz0z+gOh6A8AijwSvFfjfCNj+RFYcw1eC0vCT2feeJCIAQA9MNJpHqLRTTMWXBm4/mQwt5SF3lrj+B2XL9OTBZsDbfqEJWtf8DadpO6sJSgsx/mRoMR+lrRQxVtQKrBby9Tg7y8UkYPoWxiQg8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=YmHnEb3856B2Hjwk+rJBkEAxE2kJwLgfiFk3oFwV3lmspD0lviXGDEwDCzUos7EDBYMDp6znJZk40+Y460OvHwa5WReTzzY6Quw0QZwXU2wL8t1CPWRB17A0Lf65FiTInA9TwNwu9ok2vFXiCAVkNX0XpzVz9ABI9DMEBRFQ8Bk= Received: by 10.82.162.14 with SMTP id k14mr13023270bue.1191357556132; Tue, 02 Oct 2007 13:39:16 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id l38sm12628572rvb.2007.10.02.13.39.14 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Oct 2007 13:39:15 -0700 (PDT) Message-ID: <4702AC72.8070907@gmail.com> Date: Wed, 03 Oct 2007 09:39:14 +1300 From: Brian E Carpenter User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Plzak References: <01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com> <4697DC68.9060808@gmx.net> <03f001c804e0$92860060$6a01a8c0@DRTVnet1> <47024223.7000508@cs.utk.edu> <20071002133200.GI14394@login.ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Tim Chown , "ietf@ietf.org" Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Ray, I don't think it's quite fair to refer to ostriches when ARIN is already on record: http://www.arin.net/v6/v6-resolution.html Also, for those who like to see things in real time, there's always http://penrose.uk6x.com/ Regards Brian Carpenter University of Auckland On 2007-10-03 02:47, Ray Plzak wrote: > Head in the sand is substituting the statement "shortage of IP addresses" for the condition of the inability to use the addresses (take your pick when it comes to infrastructure deficiencies). > > Ray > >> -----Original Message----- >> From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] >> Sent: Tuesday, October 02, 2007 9:32 AM >> To: ietf@ietf.org >> Subject: Re: IPv4 to IPv6 transition >> >> On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote: >>> Ray Plzak wrote: >>>> The shortage of IPv4 addresses in developing countries in a red >> herring. >>> that has to rank as one of the most bizarre statements that's ever >> been >>> made on the ietf list. >> More of an ostrich than a herring? >> >> >> .="""=._ >> / ., .`. >> /__(,_.-' || >> ` /| || >> / | || >> \| || >> ~~~~~ ~ |\ ~~!)~~~~~~~ >> >> >> Tim >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www1.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 16:45:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcoOr-0000MU-CU; Tue, 02 Oct 2007 16:31:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcoOq-0000MN-9s for ietf@ietf.org; Tue, 02 Oct 2007 16:31:24 -0400 Received: from an-out-0708.google.com ([209.85.132.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcoOl-0005EH-4B for ietf@ietf.org; Tue, 02 Oct 2007 16:31:24 -0400 Received: by an-out-0708.google.com with SMTP id c17so627336anc for ; Tue, 02 Oct 2007 13:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=F0v5UUyIWaw9xTNJ2RbwksN08lc00PTzQe1qMqArsTM=; b=eZXw1BAKzFALNRdlHAHa7j4JKBHRzYA7iKvcHuKZuQcR4Xzj27YEv5gxNu7e9LQM9Nqib+vrZjk6gpbdo/bhFBbCI47mmlK7/UKhX9v13WOsUJr4DBPjWlqvCyrgzu0xtXMbeTsDLY+L8PEdPnlsbsmihmY+DT8uDbgMZmjNe1I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=CXVjfVdpzppiiEhWeXZ2zAtcjsCu4h2aTp9nVq3Q8ISRqZFoudu9Ce9Incx7SLEBwKmIfsNPpxeKps+dw4VE/MIQ3dUdSu5nUPFj+KHL5GsRbgCBzymO7Nssqw6QS/rJnLjN2Ts4wztGRp4BOc1J0r6TAhOoR7x9NPAWFJAEon0= Received: by 10.142.110.3 with SMTP id i3mr166920wfc.1191357067651; Tue, 02 Oct 2007 13:31:07 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id f42sm15224395rvb.2007.10.02.13.31.04 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Oct 2007 13:31:06 -0700 (PDT) Message-ID: <4702AA88.40401@gmail.com> Date: Wed, 03 Oct 2007 09:31:04 +1300 From: Brian E Carpenter User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pekka Savola References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ietf@ietf.org, tsvwg@ietf.org Subject: Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Pekka, [FYI I've already indicated my support for this draft in a message sent to the IESG.] On 2007-10-03 03:11, Pekka Savola wrote: > On Mon, 1 Oct 2007, The IESG wrote: >> The IESG has received a request from the Transport Area Working Group WG >> (tsvwg) to consider the following document: >> >> - 'Aggregation of DiffServ Service Classes ' >> as an Informational RFC > > DiffServ Pool 1 codepoints require Standards Action [1]. While this > document doesn't define new ones (because there aren't any), it defines > how one should configure the treatment for each and every Pool 1 > codepoint in the network. Therefore in spirit it specifies DSCP > codepoint behaviour and how those should be used. I think this is really not a valid interpretation. It's very common in the IETF to produce the first version of operational recommendations as Informational, with the possibility of producing a later version as BCP when there's successful operational experience. I believe that this draft, and RFC 4594, are in that category. IMHO they do not significantly change the implementation requirements for the various Proposed Standard diffserv PHBs; they add configuration recommendations for those PHBs, which is a perfectly legitimate thing for an Informational RFC. To be clear, the notion of reclassifying diffserv traffic at a domain boundary is a fundamental part of the diffserv architecture, and remapping diffserv classes into treatment aggregates, as this draft describes, is just an example of such reclassification. This draft does not change the diffserv architecture and does not redefine any of the standards track PHBs. To quote an example from the text: Traffic in the Real Time treatment aggregate should be carried in a common queue or class with a PHB as described in RFC 3246 [11] and RFC 3247 [12]. > > As such I believe this document is inappropriate as an Informational RFC. > > It is not clear that consensus in the IETF and deployments is strong > enough to approve/recommend any specific treatment for standards track > DSCP values. > > If this work were to proceed, I suggest that first RFC 4594, which this > document builds on, would attain IETF consensus by following the > standards process for publication as a BCP. Not until there is significant operational feedback, which is still a year or three in the future. I don't see that this draft, or RFC 4594, is significantly different in that respect from, say, RFC 4472. Brian > > [1] > http://www.iana.org/assignments/dscp-registry > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 19:16:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcqZ1-0002J5-5t; Tue, 02 Oct 2007 18:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcqYz-0002Iw-Qc for ietf@ietf.org; Tue, 02 Oct 2007 18:50:01 -0400 Received: from woodstock.binhost.com ([8.8.40.152]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IcqYy-00089B-Le for ietf@ietf.org; Tue, 02 Oct 2007 18:50:01 -0400 Received: (qmail 28690 invoked by uid 0); 2 Oct 2007 22:49:24 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.231.48.203) by woodstock.binhost.com with SMTP; 2 Oct 2007 22:49:24 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 02 Oct 2007 18:49:29 -0400 To: ietf@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Message-Id: The Secretariat tells me that Spammers are responding to TDMA queries so that their mail goes through. They have made the suggestion that we clear the list of people once per year. This would mean that a legitimate user of a list that uses TDMA would get a TDMA query once a year if they are not subscribed to any ietf.org mail list. There is no TDMA query for people who are on at least one ietf.org mail list. Here is the info that I have: > > Russ wants to know how many people have responded to the TMDA > > challenge but are not on any IETF mailing list. > >1025 mail addresses have "confirmed" their address. I would bet that >at least 20% of the confirmed are spam addresses (or autoconfirmed >addresses) Thoughts? Russ _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 20:29:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icrta-0007cZ-5T; Tue, 02 Oct 2007 20:15:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcrtY-0007Yt-Bw for ietf@ietf.org; Tue, 02 Oct 2007 20:15:20 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcrtS-0001SH-1t for ietf@ietf.org; Tue, 02 Oct 2007 20:15:20 -0400 Received: from [10.20.30.108] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l930F2Vp014315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2007 17:15:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 2 Oct 2007 17:14:58 -0700 To: Russ Housley , ietf@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 6:49 PM -0400 10/2/07, Russ Housley wrote: >>1025 mail addresses have "confirmed" their address. I would bet that >>at least 20% of the confirmed are spam addresses (or autoconfirmed >>addresses) > >Thoughts? How was that 20% number guessed at?. If 200 spammers (or even 20!) were on the TDMA list, we should be seeing tons of spam on the lists; so far, we are not. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 20:44:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcsFh-00038i-Sb; Tue, 02 Oct 2007 20:38:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcsFh-00037L-3k for ietf@ietf.org; Tue, 02 Oct 2007 20:38:13 -0400 Received: from mailout00.controlledmail.com ([72.81.252.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcsFg-0005S7-R7 for ietf@ietf.org; Tue, 02 Oct 2007 20:38:13 -0400 Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 7773A5CC101 for ; Wed, 3 Oct 2007 00:38:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1191371892; bh=d2ErMYNhR54ba0evMLA2ilTJOETVKJ/tDdgAEJv KGfE=; h=Received:From:Organization:To:Subject:Date:User-Agent: References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-Disposition:Message-Id: X-AV-Checked; b=Y/N0QURBGukWrJ0di/V9qybwhFqvaNqmTKlxPvyqRMq/FXM0KJ PVnxCsbrorqJNlbd56BmCUjMo/45H0rreQYp3pFob8jiE5teKRWHbTpBY1lIEqHps3K 8IX2ivd6z5TEG5U1hKugvFHRc4MSSp3ye50wKzc3r4FKG+aGEvZD5U= Received: from [192.168.111.102] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by mailout00.controlledmail.com (Postfix) with ESMTP id 416435CC0FE for ; Wed, 3 Oct 2007 00:38:11 +0000 (UTC) From: Scott Kitterman Organization: Kitterman Technical Services To: ietf@ietf.org Date: Tue, 2 Oct 2007 20:38:08 -0400 User-Agent: KMail/1.9.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710022038.09665.scott@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Tuesday 02 October 2007 18:49, Russ Housley wrote: > The Secretariat tells me that Spammers are responding to TDMA queries > so that their mail goes through. They have made the suggestion that > we clear the list of people once per year. This would mean that a > legitimate user of a list that uses TDMA would get a TDMA query once > a year if they are not subscribed to any ietf.org mail list. There > is no TDMA query for people who are on at least one ietf.org mail list. > > Here is the info that I have: > > > Russ wants to know how many people have responded to the TMDA > > > challenge but are not on any IETF mailing list. > > > >1025 mail addresses have "confirmed" their address. I would bet that > >at least 20% of the confirmed are spam addresses (or autoconfirmed > >addresses) > > Thoughts? > Randomly unsubscribing non-abusing mailing list subscribers is unlikely to be an effective spam fighting tool. If people spam an IETF list, unsubscribe them. If not, don't. It's not clear to me what problem you are trying to solve. Scott K _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 21:08:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcsdZ-00052v-Au; Tue, 02 Oct 2007 21:02:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcsdX-0004vq-JC for ietf@ietf.org; Tue, 02 Oct 2007 21:02:51 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcsdJ-0002UA-2f for ietf@ietf.org; Tue, 02 Oct 2007 21:02:43 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l930x7pW015047; Tue, 2 Oct 2007 17:59:07 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Oct 2007 18:02:00 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 2 Oct 2007 18:02:00 -0700 Message-ID: <2788466ED3E31C418E9ACC5C316615570462BD@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Spammers answering TMDA Queries Thread-Index: AcgFScQ0P8m/wfyOTCCbgWhNQZrQJAADzxPU From: "Hallam-Baker, Phillip" To: "Russ Housley" , X-OriginalArrivalTime: 03 Oct 2007 01:02:00.0710 (UTC) FILETIME=[01008A60:01C80559] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: Subject: RE: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1807419586==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============1807419586== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80559.00BA2F68" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80559.00BA2F68 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sounds reasonable to me. Tdma for personal email protection is rude and unacceptable. For mailing = lists it is entirely acceptable. Cost far outweighs benefit as the = inconvenience to the single sender is much less than the benefit to the = community. Should also consider if spf or dkim checks could cull the paypal spam. Sent from my GoodLink Wireless Handheld (www.good.com) -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Tuesday, October 02, 2007 04:12 PM Pacific Standard Time To: ietf@ietf.org Subject: Spammers answering TMDA Queries The Secretariat tells me that Spammers are responding to TDMA queries=20 so that their mail goes through. They have made the suggestion that=20 we clear the list of people once per year. This would mean that a=20 legitimate user of a list that uses TDMA would get a TDMA query once=20 a year if they are not subscribed to any ietf.org mail list. There=20 is no TDMA query for people who are on at least one ietf.org mail list. Here is the info that I have: > > Russ wants to know how many people have responded to the TMDA > > challenge but are not on any IETF mailing list. > >1025 mail addresses have "confirmed" their address. I would bet that >at least 20% of the confirmed are spam addresses (or autoconfirmed >addresses) Thoughts? Russ=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ------_=_NextPart_001_01C80559.00BA2F68 Content-Type: text/html; charset="us-From ietf-bounces@ietf.org Tue Oct 02 21:08:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcsdZ-00052v-Au; Tue, 02 Oct 2007 21:02:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcsdX-0004vq-JC for ietf@ietf.org; Tue, 02 Oct 2007 21:02:51 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcsdJ-0002UA-2f for ietf@ietf.org; Tue, 02 Oct 2007 21:02:43 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l930x7pW015047; Tue, 2 Oct 2007 17:59:07 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Oct 2007 18:02:00 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 2 Oct 2007 18:02:00 -0700 Message-ID: <2788466ED3E31C418E9ACC5C316615570462BD@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Spammers answering TMDA Queries Thread-Index: AcgFScQ0P8m/wfyOTCCbgWhNQZrQJAADzxPU From: "Hallam-Baker, Phillip" To: "Russ Housley" , X-OriginalArrivalTime: 03 Oct 2007 01:02:00.0710 (UTC) FILETIME=[01008A60:01C80559] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: Subject: RE: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1807419586==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============1807419586== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80559.00BA2F68" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80559.00BA2F68 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sounds reasonable to me. Tdma for personal email protection is rude and unacceptable. For mailing = lists it is entirely acceptable. Cost far outweighs benefit as the = inconvenience to the single sender is much less than the benefit to the = community. Should also consider if spf or dkim checks could cull the paypal spam. Sent from my GoodLink Wireless Handheld (www.good.com) -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Tuesday, October 02, 2007 04:12 PM Pacific Standard Time To: ietf@ietf.org Subject: Spammers answering TMDA Queries The Secretariat tells me that Spammers are responding to TDMA queries=20 so that their mail goes through. They have made the suggestion that=20 we clear the list of people once per year. This would mean that a=20 legitimate user of a list that uses TDMA would get a TDMA query once=20 a year if they are not subscribed to any ietf.org mail list. There=20 is no TDMA query for people who are on at least one ietf.org mail list. Here is the info that I have: > > Russ wants to know how many people have responded to the TMDA > > challenge but are not on any IETF mailing list. > >1025 mail addresses have "confirmed" their address. I would bet that >at least 20% of the confirmed are spam addresses (or autoconfirmed >addresses) Thoughts? Russ=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ------_=_NextPart_001_01C80559.00BA2F68 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Spammers answering TMDA Queries

Sounds reasonable to me.

Tdma for personal email protection is rude and unacceptable. For mailing = lists it is entirely acceptable. Cost far outweighs benefit as the = inconvenience to the single sender is much less than the benefit to the = community.

Should also consider if spf or dkim checks could cull the paypal = spam.

Sent from my GoodLink Wireless Handheld (www.good.com)

 -----Original Message-----
From:   Russ Housley [mailto:housley@vigilsec.com]
= Sent:   Tuesday, October 02, 2007 04:12 PM Pacific Standard = Time
To:     ietf@ietf.org
Subject:        Spammers answering = TMDA Queries

The Secretariat tells me that Spammers are responding to TDMA = queries
so that their mail goes through.  They have made the suggestion = that
we clear the list of people once per year.  This would mean that = a
legitimate user of a list that uses TDMA would get a TDMA query once
a year if they are not subscribed to any ietf.org mail list.  = There
is no TDMA query for people who are on at least one ietf.org mail = list.

Here is the info that I have:

>  > Russ wants to know how many people have responded to the = TMDA
>  > challenge but are not on any IETF mailing list.
>
>1025 mail addresses have "confirmed" their address.  = I would bet that
>at least 20% of the confirmed are spam addresses (or = autoconfirmed
>addresses)

Thoughts?

Russ


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.or= g/mailman/listinfo/ietf

------_=_NextPart_001_01C80559.00BA2F68-- --===============1807419586== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============1807419586==-- From ietf-bounces@ietf.org Tue Oct 02 21:08:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcsZy-0006wP-EY; Tue, 02 Oct 2007 20:59:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcsZs-0006vU-KK for ietf@ietf.org; Tue, 02 Oct 2007 20:59:04 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcsZs-0005uh-4T for ietf@ietf.org; Tue, 02 Oct 2007 20:59:04 -0400 X-IronPort-AV: E=Sophos;i="4.21,222,1188802800"; d="scan'208";a="229372072" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 02 Oct 2007 17:53:40 -0700 Received: from 64-142-29-214.dsl.static.sonic.net ([10.21.116.139]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l92NTjmM014261; Tue, 2 Oct 2007 16:29:45 -0700 Message-ID: <4702E856.1030900@cisco.com> Date: Tue, 02 Oct 2007 17:54:46 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Paul Hoffman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dascii" Content-Transfer-Encoding: quoted-printable RE: Spammers answering TMDA Queries

Sounds reasonable to me.

Tdma for personal email protection is rude and unacceptable. For mailing = lists it is entirely acceptable. Cost far outweighs benefit as the = inconvenience to the single sender is much less than the benefit to the = community.

Should also consider if spf or dkim checks could cull the paypal = spam.

Sent from my GoodLink Wireless Handheld (www.good.com)

 -----Original Message-----
From:   Russ Housley [mailto:housley@vigilsec.com]
= Sent:   Tuesday, October 02, 2007 04:12 PM Pacific Standard = Time
To:     ietf@ietf.org
Subject:        Spammers answering = TMDA Queries

The Secretariat tells me that Spammers are responding to TDMA = queries
so that their mail goes through.  They have made the suggestion = that
we clear the list of people once per year.  This would mean that = a
legitimate user of a list that uses TDMA would get a TDMA query once
a year if they are not subscribed to any ietf.org mail list.  = There
is no TDMA query for people who are on at least one ietf.org mail = list.

Here is the info that I have:

>  > Russ wants to know how many people have responded to the = TMDA
>  > challenge but are not on any IETF mailing list.
>
>1025 mail addresses have "confirmed" their address.  = I would bet that
>at least 20% of the confirmed are spam addresses (or = autoconfirmed
>addresses)

Thoughts?

Russ


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.or= g/mailman/listinfo/ietf

------_=_NextPart_001_01C80559.00BA2F68-- --===============1807419586== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============1807419586==-- From ietf-bounces@ietf.org Tue Oct 02 21:08:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcsZy-0006wP-EY; Tue, 02 Oct 2007 20:59:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcsZs-0006vU-KK for ietf@ietf.org; Tue, 02 Oct 2007 20:59:04 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcsZs-0005uh-4T for ietf@ietf.org; Tue, 02 Oct 2007 20:59:04 -0400 X-IronPort-AV: E=Sophos;i="4.21,222,1188802800"; d="scan'208";a="229372072" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 02 Oct 2007 17:53:40 -0700 Received: from 64-142-29-214.dsl.static.sonic.net ([10.21.116.139]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l92NTjmM014261; Tue, 2 Oct 2007 16:29:45 -0700 Message-ID: <4702E856.1030900@cisco.com> Date: Tue, 02 Oct 2007 17:54:46 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Paul Hoffman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=479; t=1191367785; x=1192231785; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20Spammers=20answering=20TMDA=20Queries |Sender:=20 |To:=20Paul=20Hoffman=20; bh=5YJDCxhTdtI4YSV5JAZena6sHVR0DP73sc88YQH6GnQ=; b=NTHS6/xqqTBkrwFkVQDyUXPdg3pMZXCnz8OMlaGir/BtPEjLvcVo2svhkjJI8ZdxLOi/wNM6 ekSlIJZNujU+tcY0THH4VWW5ysfd69D5xveJdFJDWKAukWVXlfs1Jgi5; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ietf@ietf.org Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Paul Hoffman wrote: > At 6:49 PM -0400 10/2/07, Russ Housley wrote: >>> 1025 mail addresses have "confirmed" their address. I would bet that >>> at least 20% of the confirmed are spam addresses (or autoconfirmed >>> addresses) >> >> Thoughts? > > How was that 20% number guessed at?. If 200 spammers (or even 20!) > were on the TDMA list, we should be seeing tons of spam on the lists; > so far, we are not. Maybe they're just harvesting addresses? Mike _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ns/txt; l=479; t=1191367785; x=1192231785; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20Spammers=20answering=20TMDA=20Queries |Sender:=20 |To:=20Paul=20Hoffman=20; bh=5YJDCxhTdtI4YSV5JAZena6sHVR0DP73sc88YQH6GnQ=; b=NTHS6/xqqTBkrwFkVQDyUXPdg3pMZXCnz8OMlaGir/BtPEjLvcVo2svhkjJI8ZdxLOi/wNM6 ekSlIJZNujU+tcY0THH4VWW5ysfd69D5xveJdFJDWKAukWVXlfs1Jgi5; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ietf@ietf.org Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Paul Hoffman wrote: > At 6:49 PM -0400 10/2/07, Russ Housley wrote: >>> 1025 mail addresses have "confirmed" their address. I would bet that >>> at least 20% of the confirmed are spam addresses (or autoconfirmed >>> addresses) >> >> Thoughts? > > How was that 20% number guessed at?. If 200 spammers (or even 20!) > were on the TDMA list, we should be seeing tons of spam on the lists; > so far, we are not. Maybe they're just harvesting addresses? Mike _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 21:23:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icsoc-0008Hz-PF; Tue, 02 Oct 2007 21:14:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icsoa-0008Gn-NS for ietf@ietf.org; Tue, 02 Oct 2007 21:14:16 -0400 Received: from gal.iecc.com ([208.31.42.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icsoa-0006CF-7o for ietf@ietf.org; Tue, 02 Oct 2007 21:14:16 -0400 Received: (qmail 10662 invoked from network); 3 Oct 2007 01:14:15 -0000 Received: from simone.iecc.com (208.31.42.47) by mail1.iecc.com with QMQP; 3 Oct 2007 01:14:15 -0000 Date: 3 Oct 2007 01:14:15 -0000 Message-ID: <20071003011415.70884.qmail@simone.iecc.com> From: John Levine To: ietf@ietf.org In-Reply-To: Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: Re: Random addresses answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > The Secretariat tells me that Spammers are responding to TDMA > queries so that their mail goes through. They have made the > suggestion that we clear the list of people once per year. Isn't there an engineering principle that if something is broken, you don't fix it by breaking it even worse? Naive challenge/response systems like TMDA never worked very well, and on today's Internet they've become actively dangerous. About 90% of all email is spam, and just about all spam has a forged return address at a real domain, often taken from the spam list. This means that most TMDA challenges go to innocent bystanders. Given the volume of spam, it also means that even though only a small fraction of addresses send autoresponses, that's enough to badly pollute any system that uses C/R for validation. If you look at the bogus addreses, I would be rather surprised if they weren't mostly random non-spammers that either auto-acked their way in, or else are people like me who ack all challenges because it's the easiest way to get other people's C/R crudware to shut up. There are plenty of workable ways to filter spam. I've found that, ironically, it is particularly difficult to get people to set up effective filters in environments full of grizzled old nerds. A lot opinions about the nature of spam and filters seem to have been formed in about 1999 or 2000 and haven't been re-examined since then, so when I suggest, e.g., that well chosen DNSBLs can knock out 80% of the spam with essentially no false positives, which is true, they don't believe it. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 22:10:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IctQE-0000Pz-IX; Tue, 02 Oct 2007 21:53:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IctQ7-0000Nl-SZ for ietf@ietf.org; Tue, 02 Oct 2007 21:53:03 -0400 Received: from harry.mail-abuse.org ([168.61.5.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IctQ5-0007Bu-El for ietf@ietf.org; Tue, 02 Oct 2007 21:53:01 -0400 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id BBA1041EE6; Tue, 2 Oct 2007 18:53:00 -0700 (PDT) In-Reply-To: <20071003011415.70884.qmail@simone.iecc.com> References: <20071003011415.70884.qmail@simone.iecc.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9D35DE26-B10E-424C-B96A-22272763EAD7@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Date: Tue, 2 Oct 2007 18:52:40 -0700 To: John Levine X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ietf@ietf.org Subject: Re: Random addresses answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 2, 2007, at 6:14 PM, John Levine wrote: >> The Secretariat tells me that Spammers are responding to TDMA >> queries so that their mail goes through. They have made the >> suggestion that we clear the list of people once per year. > > Isn't there an engineering principle that if something is broken, > you don't fix it by breaking it even worse? > > Naive challenge/response systems like TMDA never worked very well, and > on today's Internet they've become actively dangerous. About 90% of > all email is spam, and just about all spam has a forged return address > at a real domain, often taken from the spam list. This means that > most TMDA challenges go to innocent bystanders. Given the volume of > spam, it also means that even though only a small fraction of > addresses send autoresponses, that's enough to badly pollute any > system that uses C/R for validation. If you look at the bogus > addreses, I would be rather surprised if they weren't mostly random > non-spammers that either auto-acked their way in, or else are people > like me who ack all challenges because it's the easiest way to get > other people's C/R crudware to shut up. > > There are plenty of workable ways to filter spam. I've found that, > ironically, it is particularly difficult to get people to set up > effective filters in environments full of grizzled old nerds. A lot > opinions about the nature of spam and filters seem to have been formed > in about 1999 or 2000 and haven't been re-examined since then, so when > I suggest, e.g., that well chosen DNSBLs can knock out 80% of the spam > with essentially no false positives, which is true, they don't believe > it. Agreed. Email related filtering mechanisms are often broken and can be dangerous. Recipients without DNSBLS are likely seeing only a small percentage of valid email. Of the junk hitting MTAs, more than half is likely to contain a copy of spam reflected off someone's server. IETF lists have recently created their share of this traffic. -Doug _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 22:19:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IctjR-0004ID-Vw; Tue, 02 Oct 2007 22:13:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IctjQ-0004I7-8B for ietf@ietf.org; Tue, 02 Oct 2007 22:13:00 -0400 Received: from wa-out-1112.google.com ([209.85.146.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IctjH-0003x4-Vn for ietf@ietf.org; Tue, 02 Oct 2007 22:13:00 -0400 Received: by wa-out-1112.google.com with SMTP id k40so7261019wah for ; Tue, 02 Oct 2007 19:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=+EQfDOsThSbYRnM8cWGdmrxTJPE2kLEAj7mIITY2hno=; b=UEXwMx0NghkLKj75Fc2i8QH6RK6NHiXAYVYQ4GpxhrOsm9d0GW+EewMePljDB9mnDMgRYQysr9pQEwIy28AQPAPu1UlCuCKsyfMiLkQyVsbYkwin1gk5aVrps87niZdJKSUZJVzjuPcDshdpJuv5q3e+/oMSJlXys4X2/shVuoM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=S/RNFEeAxJ6xJ9rlV1eQ9nncRx2xNygqZQyi6PvzzEnEvdVhy0d3MYC5wff+93jiakdsNLmYxbwJh1nhEpAYgChET3Of3/aJ746ItnQQ1+593owRvJDiB7rVvwSM/hpr6bywXb8g11tVPklJfF/R1kZpObma10iNHpCig+oEu8Q= Received: by 10.114.121.1 with SMTP id t1mr3228293wac.1191377543997; Tue, 02 Oct 2007 19:12:23 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id n40sm9803407wag.2007.10.02.19.12.22 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Oct 2007 19:12:23 -0700 (PDT) Message-ID: <4702FA84.1070806@gmail.com> Date: Wed, 03 Oct 2007 15:12:20 +1300 From: Brian E Carpenter User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Russ Housley References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ietf@ietf.org Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-03 11:49, Russ Housley wrote: > The Secretariat tells me that Spammers are responding to TDMA queries so > that their mail goes through. They have made the suggestion that we > clear the list of people once per year. This would mean that a > legitimate user of a list that uses TDMA would get a TDMA query once a > year if they are not subscribed to any ietf.org mail list. There is no > TDMA query for people who are on at least one ietf.org mail list. > > Here is the info that I have: > >> > Russ wants to know how many people have responded to the TMDA >> > challenge but are not on any IETF mailing list. >> >> 1025 mail addresses have "confirmed" their address. I would bet that >> at least 20% of the confirmed are spam addresses (or autoconfirmed >> addresses) A little history... I manually scanned the TMDA white list about a year ago, or rather I scanned the ~700 addresses that had then confirmed themselves. I didn't keep the relevant files on grounds of privacy protection, but I recall that around 30 of the addresses were self-evidently spammers that we removed manually; there were quite a lot that were self-evidently genuine. However, there were a large number which just couldn't be classified by inspection. I can easily believe the 20% estimate. Speaking personally, I think annual reconfirmation is quite reasonable. The message sent to the user should make it clear that it is an annual process. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 22:34:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ictv2-00005M-84; Tue, 02 Oct 2007 22:25:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ictv0-00005C-Ha for ietf@ietf.org; Tue, 02 Oct 2007 22:24:58 -0400 Received: from p59-157-182-189.sub.ne.jp ([59.157.182.189] helo=uranus.bugest.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ictuu-0004En-7b for ietf@ietf.org; Tue, 02 Oct 2007 22:24:58 -0400 Received: from [192.168.0.239] (x092012.ppp.asahi-net.or.jp [122.249.92.12]) by uranus.bugest.net (Postfix) with ESMTP id B8346E65E59 for ; Wed, 3 Oct 2007 11:24:41 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <20071002133200.GI14394@login.ecs.soton.ac.uk> References: <01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com> <4697DC68.9060808@gmx.net> <03f001c804e0$92860060$6a01a8c0@DRTVnet1> <47024223.7000508@cs.utk.edu> <20071002133200.GI14394@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ruri Hiromi Date: Wed, 3 Oct 2007 11:24:39 +0900 To: ietf@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org dedicate to ostriches... http://www.apple.com/en/downloads/dashboard/networking_security/ ipv420.html On 2007/10/02, at 22:32, Tim Chown wrote: > On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote: >> Ray Plzak wrote: >>> The shortage of IPv4 addresses in developing countries in a red >>> herring. >> that has to rank as one of the most bizarre statements that's ever >> been >> made on the ietf list. > > More of an ostrich than a herring? > > > .="""=._ > / ., .`. > /__(,_.-' || > ` /| || > / | || > \| || > ~~~~~ ~ |\ ~~!)~~~~~~~ > > > Tim > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf ------------------------------- Ruri Hiromi hiromi@inetcore.com _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 23:22:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcuWz-0001v7-Pp; Tue, 02 Oct 2007 23:04:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcuWy-0001uw-6c for ietf@ietf.org; Tue, 02 Oct 2007 23:04:12 -0400 Received: from nz-out-0506.google.com ([64.233.162.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcuWs-0004zX-2Z for ietf@ietf.org; Tue, 02 Oct 2007 23:04:12 -0400 Received: by nz-out-0506.google.com with SMTP id n1so2982682nzf for ; Tue, 02 Oct 2007 20:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=CB2cEEUfurmOmlXSslQap7ERqkZAyJX6P20CpG+OfEE=; b=ge9Akny5KOzWm/fddRW+ub4QKrMyPHwnba2VWp7AaTxEKJJKuIPkV59rx+5dw2lCY/popPLq7+WJnuhH6Hl7Mnx+4enc5ATYLMzGJTvMSHck+RUhZ7TTkTc4Txkwni9fG0JVJKoPWLQfaoorZi6QsTWhUaYoyvzZyAoDWMrPxY0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=UOHqL/+FGQ3S9XWTNatDsFyzu6aRHvslmeZHrlLdomIkGVHFcizntm7/x/SmCpgRW0W5x8bZuLEo4y4w7ljwHLaX7ILbgSVEC+WJeTsG/gWGEhIbCqxwr69excSqUA5H+QlAUqpyzXB37eA7Rhi3mkQh1zaOisj6k8XHr6bUIq0= Received: by 10.114.157.1 with SMTP id f1mr3457874wae.1191380630043; Tue, 02 Oct 2007 20:03:50 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id v38sm79550wah.2007.10.02.20.03.48 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Oct 2007 20:03:49 -0700 (PDT) Message-ID: <47030690.602@gmail.com> Date: Wed, 03 Oct 2007 16:03:44 +1300 From: Brian E Carpenter User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: John Levine References: <20071003011415.70884.qmail@simone.iecc.com> In-Reply-To: <20071003011415.70884.qmail@simone.iecc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ietf@ietf.org Subject: Re: Random addresses answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-03 14:14, John Levine wrote: >> The Secretariat tells me that Spammers are responding to TDMA >> queries so that their mail goes through. They have made the >> suggestion that we clear the list of people once per year. > > Isn't there an engineering principle that if something is broken, > you don't fix it by breaking it even worse? > > Naive challenge/response systems like TMDA never worked very well, John, The IETF uses Spamassassin before mail ever hits TMDA, so most of the readily detected junk never gets there. From the time I was watching what was happening with TMDA at ietf.org, the problems you describe just weren't happening; what was happening was that literally 99% of the spam that survived Spamassassin was getting caught. That's a serious estimate from the impact of TMDA on the IESG list. The chain: Spamassassin -> TMDA -> mailman moderation basically does the job just fine. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 23:22:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcudB-0004E5-0F; Tue, 02 Oct 2007 23:10:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icud9-00047b-UC for ietf@ietf.org; Tue, 02 Oct 2007 23:10:35 -0400 Received: from gal.iecc.com ([208.31.42.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icud4-0000lp-IR for ietf@ietf.org; Tue, 02 Oct 2007 23:10:30 -0400 Received: (qmail 87837 invoked from network); 3 Oct 2007 03:10:30 -0000 Received: from simone.iecc.com (208.31.42.47) by mail1.iecc.com with QMQP; 3 Oct 2007 03:10:30 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 3 Oct 2007 03:10:30 -0000 Date: Tue, 2 Oct 2007 23:10:29 -0400 (EDT) From: John L To: Brian E Carpenter In-Reply-To: <47030690.602@gmail.com> Message-ID: <20071002230741.N69727@simone.iecc.com> References: <20071003011415.70884.qmail@simone.iecc.com> <47030690.602@gmail.com> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ietf@ietf.org Subject: Re: Random addresses answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > IESG list. The chain: > > Spamassassin -> TMDA -> mailman moderation > > basically does the job just fine. Oh, I hadn't realized that Spamassassin was in front. Yes, that should help a lot, since I expect that the contents of legit mail to IETF lists is rather unlike the contents of most spam. On the other hand, I run the ASRG list, and I'm seeing several hundred spams a day land in the mailman moderation queue. If I don't clean it out a couple of times a week, the list of stuff to delete gets so big that my web browser times out trying to load it. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 23:22:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcuWz-0001v7-Pp; Tue, 02 Oct 2007 23:04:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcuWy-0001uw-6c for ietf@ietf.org; Tue, 02 Oct 2007 23:04:12 -0400 Received: from nz-out-0506.google.com ([64.233.162.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcuWs-0004zX-2Z for ietf@ietf.org; Tue, 02 Oct 2007 23:04:12 -0400 Received: by nz-out-0506.google.com with SMTP id n1so2982682nzf for ; Tue, 02 Oct 2007 20:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=CB2cEEUfurmOmlXSslQap7ERqkZAyJX6P20CpG+OfEE=; b=ge9Akny5KOzWm/fddRW+ub4QKrMyPHwnba2VWp7AaTxEKJJKuIPkV59rx+5dw2lCY/popPLq7+WJnuhH6Hl7Mnx+4enc5ATYLMzGJTvMSHck+RUhZ7TTkTc4Txkwni9fG0JVJKoPWLQfaoorZi6QsTWhUaYoyvzZyAoDWMrPxY0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=UOHqL/+FGQ3S9XWTNatDsFyzu6aRHvslmeZHrlLdomIkGVHFcizntm7/x/SmCpgRW0W5x8bZuLEo4y4w7ljwHLaX7ILbgSVEC+WJeTsG/gWGEhIbCqxwr69excSqUA5H+QlAUqpyzXB37eA7Rhi3mkQh1zaOisj6k8XHr6bUIq0= Received: by 10.114.157.1 with SMTP id f1mr3457874wae.1191380630043; Tue, 02 Oct 2007 20:03:50 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id v38sm79550wah.2007.10.02.20.03.48 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Oct 2007 20:03:49 -0700 (PDT) Message-ID: <47030690.602@gmail.com> Date: Wed, 03 Oct 2007 16:03:44 +1300 From: Brian E Carpenter User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: John Levine References: <20071003011415.70884.qmail@simone.iecc.com> In-Reply-To: <20071003011415.70884.qmail@simone.iecc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ietf@ietf.org Subject: Re: Random addresses answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-03 14:14, John Levine wrote: >> The Secretariat tells me that Spammers are responding to TDMA >> queries so that their mail goes through. They have made the >> suggestion that we clear the list of people once per year. > > Isn't there an engineering principle that if something is broken, > you don't fix it by breaking it even worse? > > Naive challenge/response systems like TMDA never worked very well, John, The IETF uses Spamassassin before mail ever hits TMDA, so most of the readily detected junk never gets there. From the time I was watching what was happening with TMDA at ietf.org, the problems you describe just weren't happening; what was happening was that literally 99% of the spam that survived Spamassassin was getting caught. That's a serious estimate from the impact of TMDA on the IESG list. The chain: Spamassassin -> TMDA -> mailman moderation basically does the job just fine. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 02 23:22:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcudB-0004E5-0F; Tue, 02 Oct 2007 23:10:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icud9-00047b-UC for ietf@ietf.org; Tue, 02 Oct 2007 23:10:35 -0400 Received: from gal.iecc.com ([208.31.42.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icud4-0000lp-IR for ietf@ietf.org; Tue, 02 Oct 2007 23:10:30 -0400 Received: (qmail 87837 invoked from network); 3 Oct 2007 03:10:30 -0000 Received: from simone.iecc.com (208.31.42.47) by mail1.iecc.com with QMQP; 3 Oct 2007 03:10:30 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 3 Oct 2007 03:10:30 -0000 Date: Tue, 2 Oct 2007 23:10:29 -0400 (EDT) From: John L To: Brian E Carpenter In-Reply-To: <47030690.602@gmail.com> Message-ID: <20071002230741.N69727@simone.iecc.com> References: <20071003011415.70884.qmail@simone.iecc.com> <47030690.602@gmail.com> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ietf@ietf.org Subject: Re: Random addresses answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > IESG list. The chain: > > Spamassassin -> TMDA -> mailman moderation > > basically does the job just fine. Oh, I hadn't realized that Spamassassin was in front. Yes, that should help a lot, since I expect that the contents of legit mail to IETF lists is rather unlike the contents of most spam. On the other hand, I run the ASRG list, and I'm seeing several hundred spams a day land in the mailman moderation queue. If I don't clean it out a couple of times a week, the list of stuff to delete gets so big that my web browser times out trying to load it. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 01:45:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcwiN-00066e-2N; Wed, 03 Oct 2007 01:24:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcwiL-00066Q-SV for ietf@ietf.org; Wed, 03 Oct 2007 01:24:05 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcwiL-0003mD-IN for ietf@ietf.org; Wed, 03 Oct 2007 01:24:05 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Oct 2007 22:24:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv4 to IPv6 transition Thread-Index: AcgE4is8hUfLVlRSR2SX3lLsmAurkwACubwAACOphLA= References: <20070701150230.090F5233CB@coconut.itojun.org><4687DA5A.5020407@cs.utk.edu><01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com><198A730C2044DE4A96749D13E167AD37565E63@MOU1WNEXMB04.vcorp.ad.vrsn.com><4697D229.7070207@cs.utk.edu><4697DC68.9060808@gmx.net> <03f001c804e0$92860060$6a01a8c0@DRTVnet1> From: "Michel Py" To: "Ray Plzak" , X-Spam-Score: 1.0 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: RE: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > Ray Plzak wrote: > The shortage of IPv4 addresses in developing countries in a red > herring. All one has to do is apply for them from the RIR. Getting > a service provider to route them is a different problem, especially > when they profit from running your traffic through their NAT. ..or especially when a politically repressive government "encourages" ISPs to provide addresses through NAT because a) they can control content access better (by tricks such as transparent DNS proxies on the NAT box) and b) because makes it more difficult for dissident web site to pop up right and left. Michel. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 05:41:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0UQ-0008Gk-Mg; Wed, 03 Oct 2007 05:25:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0UM-0008E1-Qc; Wed, 03 Oct 2007 05:25:54 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id0UG-0005l1-P7; Wed, 03 Oct 2007 05:25:54 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 37EA11C0141; Wed, 3 Oct 2007 11:25:38 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 32A161C0102; Wed, 3 Oct 2007 11:25:38 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 2EBE658ECCA; Wed, 3 Oct 2007 11:25:38 +0200 (CEST) Date: Wed, 3 Oct 2007 11:25:38 +0200 From: Stephane Bortzmeyer To: Sam Hartman Message-ID: <20071003092538.GA31491@nic.fr> References: <200709281015.l8SAFwfq087916@bartok.nlnetlabs.nl> <3B1D547E-0F40-4A6D-B786-EB765E58A7F2@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: dnsop@ietf.org, ietf@ietf.org Subject: Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Tue, Oct 02, 2007 at 12:40:31PM -0400, Sam Hartman wrote a message of 17 lines which said: > I'd appreciate it if you took Paul's comments a lot more seriously > and looked at whether the dnsop view on this issue extends to other > parts of the ietf. To the extent that it does not, please engage in > a discussion designed to build consensus rather than assertions that > someone who disagrees with you is naive. OK, since I agree with Joao Damas on this point, let me rephrase it (again) without harsh words. Everyone took Paul Hoffman's and John Klensin's comments seriously. But these comments have a big flaw, they jump from the (legitimate) use case to a specific (and bad) solution. John Klensin's message wasted many bytes describing the (well known) problem instead of trying to see if the current I-D properly describes the solutions. Everyone agrees that there is a very real and very legitimate use case for roaming users to *not* use the default DNS resolver of the current access point (see RFC 4925, section 2.5.2 for a typical reason). But suggesting ORNS (Open Recursive Name Servers) for the solution to this issue is, indeed, a bad idea (do note I did not say the N word), for the reasons explained in draft-ietf-dnsop-reflectors-are-evil-04.txt (reflections attack). There are other solutions to this issue and lists have already been given in this thread *and* in the I-D we discuss. These solutions are TSIG, local caching resolvers and VPN. May be there is an editorial problem if they are not well explained but the I-D does completely cover the issue of romaing users. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 05:4From ietf-bounces@ietf.org Wed Oct 03 05:41:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0UQ-0008Gk-Mg; Wed, 03 Oct 2007 05:25:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0UM-0008E1-Qc; Wed, 03 Oct 2007 05:25:54 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id0UG-0005l1-P7; Wed, 03 Oct 2007 05:25:54 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 37EA11C0141; Wed, 3 Oct 2007 11:25:38 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 32A161C0102; Wed, 3 Oct 2007 11:25:38 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 2EBE658ECCA; Wed, 3 Oct 2007 11:25:38 +0200 (CEST) Date: Wed, 3 Oct 2007 11:25:38 +0200 From: Stephane Bortzmeyer To: Sam Hartman Message-ID: <20071003092538.GA31491@nic.fr> References: <200709281015.l8SAFwfq087916@bartok.nlnetlabs.nl> <3B1D547E-0F40-4A6D-B786-EB765E58A7F2@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: dnsop@ietf.org, ietf@ietf.org Subject: Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Tue, Oct 02, 2007 at 12:40:31PM -0400, Sam Hartman wrote a message of 17 lines which said: > I'd appreciate it if you took Paul's comments a lot more seriously > and looked at whether the dnsop view on this issue extends to other > parts of the ietf. To the extent that it does not, please engage in > a discussion designed to build consensus rather than assertions that > someone who disagrees with you is naive. OK, since I agree with Joao Damas on this point, let me rephrase it (again) without harsh words. Everyone took Paul Hoffman's and John Klensin's comments seriously. But these comments have a big flaw, they jump from the (legitimate) use case to a specific (and bad) solution. John Klensin's message wasted many bytes describing the (well known) problem instead of trying to see if the current I-D properly describes the solutions. Everyone agrees that there is a very real and very legitimate use case for roaming users to *not* use the default DNS resolver of the current access point (see RFC 4925, section 2.5.2 for a typical reason). But suggesting ORNS (Open Recursive Name Servers) for the solution to this issue is, indeed, a bad idea (do note I did not say the N word), for the reasons explained in draft-ietf-dnsop-reflectors-are-evil-04.txt (reflections attack). There are other solutions to this issue and lists have already been given in this thread *and* in the I-D we discuss. These solutions are TSIG, local caching resolvers and VPN. May be there is an editorial problem if they are not well explained but the I-D does completely cover the issue of romaing users. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 05:41:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0Z0-00059E-DF; Wed, 03 Oct 2007 05:30:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0Yw-0004zP-Qn for ietf@ietf.org; Wed, 03 Oct 2007 05:30:38 -0400 Received: from mail.nttv6.net ([192.68.245.115]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id0Yw-0001s8-1V for ietf@ietf.org; Wed, 03 Oct 2007 05:30:38 -0400 Received: from andrew.nttv6.net ([192.47.163.201]) by mail.nttv6.net (8.14.1/8.14.1) with ESMTP id l939UauC027479; Wed, 3 Oct 2007 18:30:36 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-ID: <47036132.2080600@nttv6.net> Date: Wed, 03 Oct 2007 18:30:26 +0900 From: Arifumi Matsumoto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-JP-mac; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVuaXMtQ291cm1vbnQ=?= References: <20071001175000.7B93748C4@carter-zimmerman.suchdamage.org> <200710020924.49180.remi.denis-courmont@nokia.com> In-Reply-To: <200710020924.49180.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.68.245.115]); Wed, 03 Oct 2007 18:30:36 +0900 (JST) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.nttv6.net id l939UauC027479 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ietf@ietf.org Subject: Re: Would someone help the secretariat figure out why they cannot route to teredo addresses? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org R=C3=A9mi Denis-Courmont wrote: > Le Monday 01 October 2007 20:50:00 ext Sam Hartman, vous avez =C3=A9cri= t : >> Hi. I opened a ticket with the secretariat a few weeks ago >> complaining that I cannot reach www.ietf.org using a teredo address >> either allocated through the Microsoft Teredo server or the Debian >> teredo server. >> >> This is annoying because glibc's source address selection algorithm >> seems to prefer teredo addresses to v4 addresses. So, I get really >> bad response times to www.ietf.org when using teredo. >=20 > To make a long short, that depends on your glibc version. As far as I=20 > remember, RFC3484 was implemented in version 2.4. Configurable policy i= n=20 > version 2.5, and Teredo in the default policy only very recently. >=20 > Because Teredo is not mentioned in RFC3484, I expect many other RFC3484= =20 > implementations do have the same issue. Unfortunately, even if they don= 't=20 > have Teredo support themselves, they should still recognize the prefix = for=20 > source address selection... > I did write an I-D to allocate one new prefix, but then I realized that= the=20 > revised RFC3484 draft work already mentioned it, so I did not bother=20 > submitting it. Do you mean this I-D ? http://tools.ietf.org/id/draft-arifumi-ipv6-rfc3484-revise-00.txt This one includes mainly minor changes to RFC 3484. I tried to talk about this I-D at Prague, but I couldn't have time there. Though this I-D is expired now, I want to put this on the table again. Do you have any comments about this I-D ? Now that we have 6man wg, is it a good idea to move from intarea to 6man = ? Thanks. --=20 Arifumi Matsumoto IP Technology Expert Team Secure Communication Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.net ________________________1:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0Z0-00059E-DF; Wed, 03 Oct 2007 05:30:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0Yw-0004zP-Qn for ietf@ietf.org; Wed, 03 Oct 2007 05:30:38 -0400 Received: from mail.nttv6.net ([192.68.245.115]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id0Yw-0001s8-1V for ietf@ietf.org; Wed, 03 Oct 2007 05:30:38 -0400 Received: from andrew.nttv6.net ([192.47.163.201]) by mail.nttv6.net (8.14.1/8.14.1) with ESMTP id l939UauC027479; Wed, 3 Oct 2007 18:30:36 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-ID: <47036132.2080600@nttv6.net> Date: Wed, 03 Oct 2007 18:30:26 +0900 From: Arifumi Matsumoto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-JP-mac; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVuaXMtQ291cm1vbnQ=?= References: <20071001175000.7B93748C4@carter-zimmerman.suchdamage.org> <200710020924.49180.remi.denis-courmont@nokia.com> In-Reply-To: <200710020924.49180.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.nttv6.net [192.68.245.115]); Wed, 03 Oct 2007 18:30:36 +0900 (JST) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.nttv6.net id l939UauC027479 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ietf@ietf.org Subject: Re: Would someone help the secretariat figure out why they cannot route to teredo addresses? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org R=C3=A9mi Denis-Courmont wrote: > Le Monday 01 October 2007 20:50:00 ext Sam Hartman, vous avez =C3=A9cri= t : >> Hi. I opened a ticket with the secretariat a few weeks ago >> complaining that I cannot reach www.ietf.org using a teredo address >> either allocated through the Microsoft Teredo server or the Debian >> teredo server. >> >> This is annoying because glibc's source address selection algorithm >> seems to prefer teredo addresses to v4 addresses. So, I get really >> bad response times to www.ietf.org when using teredo. >=20 > To make a long short, that depends on your glibc version. As far as I=20 > remember, RFC3484 was implemented in version 2.4. Configurable policy i= n=20 > version 2.5, and Teredo in the default policy only very recently. >=20 > Because Teredo is not mentioned in RFC3484, I expect many other RFC3484= =20 > implementations do have the same issue. Unfortunately, even if they don= 't=20 > have Teredo support themselves, they should still recognize the prefix = for=20 > source address selection... > I did write an I-D to allocate one new prefix, but then I realized that= the=20 > revised RFC3484 draft work already mentioned it, so I did not bother=20 > submitting it. Do you mean this I-D ? http://tools.ietf.org/id/draft-arifumi-ipv6-rfc3484-revise-00.txt This one includes mainly minor changes to RFC 3484. I tried to talk about this I-D at Prague, but I couldn't have time there. Though this I-D is expired now, I want to put this on the table again. Do you have any comments about this I-D ? Now that we have 6man wg, is it a good idea to move from intarea to 6man = ? Thanks. --=20 Arifumi Matsumoto IP Technology Expert Team Secure Communication Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf _______________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 05:53:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0ml-00018z-FR; Wed, 03 Oct 2007 05:44:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0mj-00018f-QO for ietf@ietf.org; Wed, 03 Oct 2007 05:44:53 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id0mj-0002OP-Bm for ietf@ietf.org; Wed, 03 Oct 2007 05:44:53 -0400 Received: from E03MVC4-UKBR.domain1.systemhost.net ([193.113.197.112]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 10:44:51 +0100 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" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Oct 2007 10:45:16 +0100 Message-ID: In-Reply-To: <20071002155754.A24B787315@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir] secdir review ofdraft-ietf-dnsop-reflectors-are-evil-04.txt Thread-Index: AcgFDwBeR4cBAtjIR3q/Xy9v4ldEYAAkeWaQ References: <20071002155754.A24B787315@mercury.lcs.mit.edu> From: To: X-OriginalArrivalTime: 03 Oct 2007 09:44:51.0434 (UTC) FILETIME=[0B6924A0:01C805A2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: RE: [secdir] secdir review ofdraft-ietf-dnsop-reflectors-are-evil-04.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > > From: Danny McPherson >=20 > > where's the authoritative source for who owns what prefixes >=20 > This, one could imagining putting together. The IETF has delegated this to the IANA and the RIRs. So far, the RIRs have not done anything more than keep the antiquated whois directory functioning. I use the word "antiquated" in reference to whois directory services not because of the query protocol, but because of its origins as a way of auditing network users in order to justify budget allocations back in ARPANET days. Since that time, there has never been a serious attempt to rethink the purpose and scope of the IP addressing whois directory.=20 One wonders whether the vastness of the IPv6 address space is sufficient change for the IETF to write some guidance to the RIRs regarding the purpose and scope of a whois directory. Or maybe some other method of signalling the "ownership" of address prefixes. > > and who's permitted to originate/transit what prefixes? The RIRs have taken a stab at this problem with route registry services but it has never gotten significant support from ISPs. Since the RIRs delegate short prefixes to ISPs, who then may delegate longer prefixes in some way, the chain of permission to originate/transit, originates with the RIRs. Is a new protocol needed for this to work right? Or is there simply not enough demand. Note that some RIRs such as RIPE, attempt to maintain a fairly detailed route registry database as part of their whois directory. > Second, you're talking about potentially orders of magnitude=20 > more data: for each destination, there are worldwide likely=20 > hundreds (or more) of ISP's which are likely to be viable=20 > backbone transits. (By 'backbone transit', I mean ISP's/AS's=20 > which are not even directly connected to the organization=20 > which is the source or destination of the packets; e.g.=20 > customer A is connected to ISP p which is connected to ISP q=20 > which is connected to ISP r which is connected to customer B;=20 > q is a 'backbone transit'.) We have the technology to deal with orders of magnitude more data, assuming that the task is delegated to servers, not to routers. --Michael Dillon _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 07:06:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id1va-0001aC-UW; Wed, 03 Oct 2007 06:58:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id1vZ-0001a7-LM for ietf@ietf.org; Wed, 03 Oct 2007 06:58:05 -0400 Received: from smtp2.arin.net ([192.149.252.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id1vZ-0004eE-7J for ietf@ietf.org; Wed, 03 Oct 2007 06:58:05 -0400 Received: by smtp2.arin.net (Postfix, from userid 5003) id C57721447BA; Wed, 3 Oct 2007 06:57:49 -0400 (EDT) Received: from ex.arin.net (ex.arin.net [192.149.252.56]) by smtp2.arin.net (Postfix) with ESMTP id 285C7144506; Wed, 3 Oct 2007 06:57:49 -0400 (EDT) Received: from EDAMAME.arin.net ([192.136.136.195]) by ex.arin.net ([192.149.252.56]) with mapi; Wed, 3 Oct 2007 06:58:49 -0400 From: Ray Plzak To: Brian E Carpenter Date: Wed, 3 Oct 2007 06:56:47 -0400 Thread-Topic: IPv4 to IPv6 transition Thread-Index: AcgFNE6Is/ztRj2PTbOVngcIbqCD+AAdzX9w Message-ID: References: <01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com> <4697DC68.9060808@gmx.net> <03f001c804e0$92860060$6a01a8c0@DRTVnet1> <47024223.7000508@cs.utk.edu> <20071002133200.GI14394@login.ecs.soton.ac.uk> <4702AC72.8070907@gmail.com> In-Reply-To: <4702AC72.8070907@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Level: X-Spam-Status: No, hits=-73.1 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.63-arin1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Tim Chown , "ietf@ietf.org" Subject: RE: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Brian, My comment was regarding a head in the sand approach when it comes to the r= ecurring themes that the developing world can't IP address space, whether i= t is v4 or v6. The fact is that they can get it from the RIR like those in = the developed regions can get it from their RIRs. The real problem, in othe= r words, putting head in sand, is to substitute this address space access i= ssue for the real one of what can the recipients of the address space do wi= th it when they get, particularly if they have no hardware to run it on, no= electricity to power it, and no upstream willing to route it. It is those = issues that need to be hit head on if the Internet is to really grow in the= developing regions of the globe. Ray > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Tuesday, October 02, 2007 4:39 PM > To: Ray Plzak > Cc: Tim Chown; ietf@ietf.org > Subject: Re: IPv4 to IPv6 transition > > Ray, > > I don't think it's quite fair to refer to ostriches > when ARIN is already on record: > http://www.arin.net/v6/v6-resolution.html > > Also, for those who like to see things in real time, > there's always http://penrose.uk6x.com/ > > Regards > Brian Carpenter > University of Auckland > > > > > On 2007-10-03 02:47, Ray Plzak wrote: > > Head in the sand is substituting the statement "shortage of IP > addresses" for the condition of the inability to use the addresses > (take your pick when it comes to infrastructure deficiencies). > > > > Ray > > > >> -----Original Message----- > >> From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] > >> Sent: Tuesday, October 02, 2007 9:32 AM > >> To: ietf@ietf.org > >> Subject: Re: IPv4 to IPv6 transition > >> > >> On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote: > >>> Ray Plzak wrote: > >>>> The shortage of IPv4 addresses in developing countries in a red > >> herring. > >>> that has to rank as one of the most bizarre statements that's ever > >> been > >>> made on the ietf list. > >> More of an ostrich than a herring? > >> > >> > >> .=3D"""=3D._ > >> / ., .`. > >> /__(,_.-' || > >> ` /| || > >> / | || > >> \| || > >> ~~~~~ ~ |\ ~~!)~~~~~~~ > >> > >> > >> Tim > >> > >> _______________________________________________ > >> Ietf mailing list > >> Ietf@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ietf > > > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 07:06:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id1tO-0002lX-OH; Wed, 03 Oct 2007 06:55:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id1tN-0002fV-Mx for ietf@ietf.org; Wed, 03 Oct 2007 06:55:49 -0400 Received: from p59-157-182-189.sub.ne.jp ([59.157.182.189] helo=uranus.bugest.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id1tN-0004ak-6u for ietf@ietf.org; Wed, 03 Oct 2007 06:55:49 -0400 Received: from [192.168.1.5] (h219-110-231-206.catv02.itscom.jp [219.110.231.206]) by uranus.bugest.net (Postfix) with ESMTP id 22295E65E3F for ; Wed, 3 Oct 2007 19:55:46 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com> <4697DC68.9060808@gmx.net> <03f001c804e0$92860060$6a01a8c0@DRTVnet1> <47024223.7000508@cs.utk.edu> <20071002133200.GI14394@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ruri Hiromi Date: Wed, 3 Oct 2007 19:55:40 +0900 To: ietf@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org correction, http://www.apple.com/jp/downloads/dashboard/networking_security/ ipv420.html let me know what do you think about it :-) Regards, On 2007/10/03, at 11:24, Ruri Hiromi wrote: > > dedicate to ostriches... > http://www.apple.com/en/downloads/dashboard/networking_security/ > ipv420.html > > On 2007/10/02, at 22:32, Tim Chown wrote: > >> On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote: >>> Ray Plzak wrote: >>>> The shortage of IPv4 addresses in developing countries in a red >>>> herring. >>> that has to rank as one of the most bizarre statements that's >>> ever been >>> made on the ietf list. >> >> More of an ostrich than a herring? >> >> >> .="""=._ >> / ., .`. >> /__(,_.-' || >> ` /| || >> / | || >> \| || >> ~~~~~ ~ |\ ~~!)~~~~~~~ >> >> >> Tim >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www1.ietf.org/mailman/listinfo/ietf > > ------------------------------- > Ruri Hiromi > hiromi@inetcore.com > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf ------------------------------- Ruri Hiromi ruri@bugest.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 07:55:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id2eX-000050-3W; Wed, 03 Oct 2007 07:44:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id2eV-00004u-SC for ietf@ietf.org; Wed, 03 Oct 2007 07:44:31 -0400 Received: from relay1.mail.vrmd.de ([81.28.232.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id2eP-0001PK-DM for ietf@ietf.org; Wed, 03 Oct 2007 07:44:31 -0400 Received: from [87.79.236.249] (helo=[192.168.1.102]) by relay1.mail.vrmd.de with esmtpa (Exim 4.60) (envelope-from ) id 1Id2eA-0003YD-Oi for ietf@ietf.org; Wed, 03 Oct 2007 13:44:10 +0200 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com> <4697DC68.9060808@gmx.net> <03f001c804e0$92860060$6a01a8c0@DRTVnet1> <47024223.7000508@cs.utk.edu> <20071002133200.GI14394@login.ecs.soton.ac.uk> X-Gpgmail-State: !signed Message-Id: From: Marc Manthey Date: Wed, 3 Oct 2007 13:43:49 +0200 To: IETF Discussion X-Mailer: Apple Mail (2.752.2) X-Relay-User: marc@let.de X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0233246313==" Errors-To: ietf-bounces@ietf.org --===============0233246313== Content-Type: multipart/alternative; boundary=Apple-Mail-1-503748934 --Apple-Mail-1-503748934 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Oct 3, 2007, at 12:55 PM, Ruri Hiromi wrote: > http://www.apple.com/jp/downloads/dashboard/networking_security/ > ipv420.html hi Ruri , well, i could imagine what its good for , but an english version would be appreciated ;) cheers Marc -- Marc Manthey - LET - research + deployment D- 50672 Cologne Hildeboldplatz 1a web: http://www.let.de my xing profile https://www.xing.com/profile/Marc_Manthey phone &mobile: 0049.221.355.80.32 0049.177.341.54.81 --Apple-Mail-1-503748934 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Oct 3, 2007, at 12:55 PM, Ruri Hiromi = wrote:

hi=A0Ruri ,

well, i could imagine what = its good =A0for , but an english version would be=A0appreciated = ;)

cheers

Marc

--
Marc Manthey -
LET -=A0 research + deployment
D- 50672 Cologne
Hildeboldplatz 1a
=
my xing profile
phone &mobile:
0049.221.355.80.32
0049.177.341.54.81
=
= --Apple-Mail-1-503748934-- --===============0233246313== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0233246313==-- From ietf-bounces@ietf.org Wed Oct 03 07:59:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id2pI-0002aB-4i; Wed, 03 Oct 2007 07:55:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id2pG-0002Z2-9k for ietf@ietf.org; Wed, 03 Oct 2007 07:55:38 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id2pF-0006Ky-Vp for ietf@ietf.org; Wed, 03 Oct 2007 07:55:38 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 66C611C00F5; Wed, 3 Oct 2007 13:55:37 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 620FB1C00E8; Wed, 3 Oct 2007 13:55:37 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 5E15F58ECCA; Wed, 3 Oct 2007 13:55:37 +0200 (CEST) Date: Wed, 3 Oct 2007 13:55:37 +0200 From: Stephane Bortzmeyer To: Ruri Hiromi Message-ID: <20071003115537.GA16214@nic.fr> References: <01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com> <4697DC68.9060808@gmx.net> <03f001c804e0$92860060$6a01a8c0@DRTVnet1> <47024223.7000508@cs.utk.edu> <20071002133200.GI14394@login.ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ietf@ietf.org Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Wed, Oct 03, 2007 at 07:55:40PM +0900, Ruri Hiromi wrote a message of 64 lines which said: >http://www.apple.com/jp/downloads/dashboard/networking_security/ipv420.html ^^ Many webmasters still have not read RFC 4646 :-( > let me know what do you think about it :-) Any translation in my own language? For english, Google suggests: IPv4 depletion clock 2.0 Empty circumstance of the IPv4 address space which IANA has managed and remaining days to depletion expectation day, it can look through the IPv4 address (presumption) and the like at present time. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 08:12:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id2tk-0003wm-TT; Wed, 03 Oct 2007 08:00:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id2tg-0003ur-N0 for ietf@ietf.org; Wed, 03 Oct 2007 08:00:12 -0400 Received: from mail146.messagelabs.com ([216.82.245.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id2tg-0006Sd-Da for ietf@ietf.org; Wed, 03 Oct 2007 08:00:12 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-4.tower-146.messagelabs.com!1191412811!22425846!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 1176 invoked from network); 3 Oct 2007 12:00:11 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-4.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 3 Oct 2007 12:00:11 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l93C0B36012401 for ; Wed, 3 Oct 2007 08:00:11 -0400 Received: from mlph070.sfdc.sbc.com (mlph070.sfdc.sbc.com [144.155.224.139]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l93C07wl012375 for ; Wed, 3 Oct 2007 08:00:07 -0400 Received: from sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph070.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l93C07k2002469 for ; Wed, 3 Oct 2007 08:00:07 -0400 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by mlph070.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l93BxuNN002242 for ; Wed, 3 Oct 2007 08:00:00 -0400 Received: from [135.210.32.21] (unknown[135.210.32.21](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20071003115955gw10010gaie> (Authid: tony); Wed, 3 Oct 2007 11:59:55 +0000 Message-ID: <47038402.6080607@att.com> Date: Wed, 03 Oct 2007 07:58:58 -0400 From: Tony Hansen User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Marc Manthey References: <01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com> <4697DC68.9060808@gmx.net> <03f001c804e0$92860060$6a01a8c0@DRTVnet1> <47024223.7000508@cs.utk.edu> <20071002133200.GI14394@login.ecs.soton.ac.uk> In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: IETF Discussion Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org courtesy of google translation: http://translate.google.com/translate?u=http%3A%2F%2Fwww.apple.com%2Fjp%2Fdownloads%2Fdashboard%2Fnetworking_security%2Fipv420.html+&langpair=ja%7Cen&hl=en&safe=off&ie=UTF-8&oe=UTF-8&prev=%2Flanguage_tools Tony Hansen tony@att.com Marc Manthey wrote: > > On Oct 3, 2007, at 12:55 PM, Ruri Hiromi wrote: >> http://www.apple.com/jp/downloads/dashboard/networking_security/ipv420.html > > well, i could imagine what its good for , but an english version would > be appreciated ;) _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 08:48:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3Vr-0007YS-NY; Wed, 03 Oct 2007 08:39:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcOep-0000IO-7D; Mon, 01 Oct 2007 13:02:11 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.201.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcOej-0006AW-2G; Mon, 01 Oct 2007 13:02:11 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l91H1fAu018254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2007 13:01:42 -0400 (EDT) Date: Mon, 01 Oct 2007 13:01:41 -0400 From: Jeffrey Hutzelman To: Danny McPherson Message-ID: In-Reply-To: <430285D9-F7A6-4E5B-BE99-721D54E23232@tcb.net> References: <200709242336.l8ONaNhB060726@drugs.dv.isc.org> <430285D9-F7A6-4E5B-BE99-721D54E23232@tcb.net> Originator-Info: login-token=Mulberry:01fcLvqucqZB7JDWcrsEAfGRQ0JtUE9mjqNx0Ps0I=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-Mailman-Approved-At: Wed, 03 Oct 2007 08:39:17 -0400 Cc: dnsop-chairs@ietf.org, ietf@ietf.org, secdir@mit.edu, Mark Andrews , fneves@registro.br, iesg@ietf.org, Jeffrey Hutzelman , joao_damas@isc.org Subject: Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Monday, October 01, 2007 10:34:37 AM -0600 Danny McPherson wrote: > Note that in real deployments just this behavior has broken things > on occasion, as many firewall and other such policy application points > assume things like DNS resolution will only be UDP/53 transactions. Yeah; I'm getting a little tired of having our protocols redefined based on the incorrect assumptions of people who don't understand them. The DNS sometimes uses TCP, UDP flows can last more than one round trip, and ICMP unreachable messages are an essential part of IP; vendors and operators who assume otherwise should be made to fix their assumptions, instead of everyone else having to cripple their applications and networks to make the assumptions true. -- Jeff _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 08:48:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3Vm-0007X8-Qe; Wed, 03 Oct 2007 08:39:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaoGc-0008TG-Ue for ietf@ietf.org; Thu, 27 Sep 2007 03:58:39 -0400 Received: from gatekeeper.hitachi-eu.com ([194.36.128.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaoGY-0006UI-KI for ietf@ietf.org; Thu, 27 Sep 2007 03:58:36 -0400 X-ASG-Debug-ID: 1190879911-1c1500420000-h9jmKw X-Barracuda-URL: http://mhd-bar.hitachi-eu.com:8000/cgi-bin/mark.cgi Received: from mhd-mta-int.hitachi-eu.com (localhost [127.0.0.1]) by gatekeeper.hitachi-eu.com (Spam Firewall) with ESMTP id E90791D8A89; Thu, 27 Sep 2007 08:58:31 +0100 (BST) Received: from mhd-mta-int.hitachi-eu.com ([193.39.225.234]) by gatekeeper.hitachi-eu.com with ESMTP id jWXCAW9G8LDZWgpa; Thu, 27 Sep 2007 08:58:31 +0100 (BST) X-ASG-Whitelist: Client Received: from MHDEXC99.adhel.hitachi-eu.com (Not Verified[193.39.227.52]) by mhd-mta-int.hitachi-eu.com with MailMarshal (v6, 1, 8, 2172) id ; Thu, 27 Sep 2007 07:58:27 +0000 Received: from mhdexcb.adhel.hitachi-eu.com ([193.39.227.47]) by MHDEXC99.adhel.hitachi-eu.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 08:58:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [IPFIX] draft-ietf-ipfix-protocol-26.txt Date: Thu, 27 Sep 2007 08:56:38 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] draft-ietf-ipfix-protocol-26.txt Thread-Index: AcgA2+7RY5qakY6GRx6lw6NI4jGBgw== From: "Boschi, Elisa" To: X-OriginalArrivalTime: 27 Sep 2007 07:58:31.0460 (UTC) FILETIME=[322BDE40:01C800DC] X-Barracuda-Connect: UNKNOWN[193.39.225.234] X-Barracuda-Start-Time: 1190879911 X-Barracuda-Virus-Scanned: by HEU SPAM Firewall - MHD at hitachi-eu.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 08868c2bcdb53bddcb7cc7e7cf96b038 X-Mailman-Approved-At: Wed, 03 Oct 2007 08:39:18 -0400 Cc: ietf@ietf.org, ipfix@ietf.org, tsv-dir@ietf.org Subject: Re: [IPFIX] draft-ietf-ipfix-protocol-26.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0247319720==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============0247319720== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C800DC.324BDF5C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C800DC.324BDF5C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Scott, we received similar comments during the transport directorate review of t= he IPFIX implementation guidelines. The new revision of the document, now= =20available at: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-implementation-guide= lines-07.txt might address your concerns. I'm copying the UDP section here below for your convenience. Elisa --- 6.2. UDP =20 UDP is useful in simple systems where an SCTP stack is not available= , =20 and where there is insufficient memory for TCP buffering. =20 However, UDP is not a reliable transport protocol, and IPFIX message= s =20 sent over UDP might be lost as with partially-reliable SCTP streams.= =20 UDP is not the recommended protocol for IPFIX and is intended for us= e =20 in cases in which IPFIX is replacing an existing NetFlow =20 infrastructure, with the following properties: =20 o A dedicated network, =20 o within a single administrative domain, =20 o where SCTP is not available due to implementation constraints, =20 o and the collector is as topographically close as possible to the =20 exporter. =20 Note that because UDP itself provides no congestion control =20 mechanisms, it is recommended to use UDP transport only on managed =20 networks, where the network path has been explicitly provisioned for= =20 IPFIX traffic through traffic engineering mechanisms, such as rate =20 limiting or capacity reservations. =20 An important example of an explicitly provisioned managed network fo= r =20 IPFIX is use of IPFIX to replace a functioning NetFlow implementatio= n =20 on a dedicated network. In this situation, the dedicated network =20 should be provisioned in accordance with the NetFlow deployment =20 experience that flow export traffic generated by monitoring an =20 interface will amount to 2-5% of the monitored interface's bandwidth= . =20 As recommended in [I-D.ietf-tsvwg-udp-guidelines] an application =20 SHOULD NOT send UDP messages that result in IP packets that exceed =20 the MTU of the path to the destination and SHOULD enable UDP =20 checksums (see sections 3.2 and 3.4 of =20 [I-D.ietf-tsvwg-udp-guidelines] respectively). =20 Since IPFIX assumes reliable transport of templates over SCTP, this =20 necessitates some changes for IPFIX template management over UDP. =20 Templates sent from the Exporting Process to the Collecting Process =20 over UDP MUST be resent at regular time intervals; these intervals =20 MUST be configurable. =20 We recommend a default Template resend time of 10 minutes, =20 configurable between 1 minute and 1 day. =20 Note that this could become an interoperability problem, e.g. if an =20 Exporter re-sends Templates once per day, while a Collector expires =20 Templates hourly, then they may both be IPFIX-compatible, but not be= =20 interoperable. =20 Retransmission time intervals that are too short waste bandwidth on =20 unnecessary template retransmissions. On the other hand, time =20 intervals that are too long introduce additional costs or risk of =20 data loss by potentially requiring the Collector to cache more data =20 without having the Templates available to decode it. =20 To increase reliability and limit the amount of potentially lost dat= a =20 the Exporting Process MAY resend additional templates using a packet= - =20 based schedule. In this case Templates are resent depending on the =20 number of data packets sent. Similarly to the time interval, =20 resending a Template every few packets introduces additional overhea= d =20 while resending after a large amount of packets have already been =20 sent means high costs due to the data caching and potential data =20 loss. =20 We recommend a default Template resend interval of 20 packets, =20 configurable between 1 and 1000 packets. =20 Note that a sufficiently small resend time or packet interval may =20 cause a system to become stuck, continually re-sending templates. =20 e.g., if the resend packet interval is 2 (i.e., templates are to be =20 sent in every other packet) but more than two packets are required t= o =20 send all the templates, then the resend interval will have expired b= y =20 the time the templates have been sent, and templates will be sent =20 continuously - possibly preventing any data from being sent at all. =20 Therefore the Template resend intervals should be considered from th= e =20 last data packet, and should not be tied to specific sequence =20 numbers. =20 The Collecting Process SHOULD use the Sequence Number in the IPFIX =20 Message header to determine whether any messages are lost. =20 The following may be done to mitigate message loss: =20 o Move the Collector topologically closer to the Exporter. =20 o Increase the bandwidth of the links through which the Data Record= s =20 are exported. =20 o Use sampling, filtering, or aggregation in the Metering Process t= o =20 reduce the amount of exported data. =20 o Increase the buffer size at the Collector and/or the Exporter. =20 Before using a Template for the first time, the Exporter may send it= =20 in several different IPFIX Messages spaced out over a period of =20 packets in order to increase the likelihood that the Collector has =20 received the Template. =20 Template Withdraw messages MUST NOT be sent over UDP; the Exporter =20 must rely on expiration at the Collector to expire old Templates or =20 to reuse Template Ids. =20 We recommend that the collector implements a template expiry of thre= e =20 times the Exporter refresh rate. =20 However, since the IPFIX protocol doesn't provide any mechanism for =20 the Exporter to convey any information about the Template expiry tim= e =20 to the Collector, configuration must be done out of band. =20 If no out of band configuration is made, we recommend to initially =20 set a template expiry time at the Collector of 60 minutes. The =20 Collecting Process MAY estimate each Exporting Process's resend time= =20 and adapt the expiry time for the corresponding Templates =20 accordingly.=20 Scott O. Bradner wrote: > I reviewed draft-ietf-ipfix-protocol-26.txt as part of the Transport > Area review effort. >=20 > I did not find any particular issues in the described technology - a fe= w > nits: >=20 > section 3.1 "Export Time" someday the IETF needs to stop using 32-bit > "seconds since 1 jan 1970" for timing - at least within in the next 31 > years >=20 > section 6.1.2 - it might be reasonable to add the IEEE 8-byte MAC > address as an address type - this is used in ZigBee and may be in wider= > use in the future >=20 > section 10.3.3 - a max packet size of 1280 could be used if the > connection is known to be running in an IPv6-only environment >=20 > I'm not sure why the packet size discussion is only listed for UDP - it= > seems like the same restriction should apply to all protocols - > fragmentation is not your friend >=20 > Historically the biggest issue with IPFIX has been that most > implementers want to run it over UDP with consequences be dammed. - > this was weaseled in the IPFIX Requirements document (RFC 3917) by > requiring (in section 6.3.1) that "For the data transfer, a congestion > aware protocol must be supported." This draft meets that requirement b= y > making the implementation of SCTP a MUST. That will not stop many > implementers from ignoring the requirement for implementation or users > to enable UDP and thus creating a potentially very high bandwidth > non-congestion avoiding fire hose that can quite easily wipe out a net > by misconfiguration or become a DoS engine by purposeful configuration.= >=20 > I'm not sure if anything can be actually be done about this risk - It > might help some to say that UDP is a "MUST NOT" but I doubt it - in any= > case it would help somewhat, imho, to expand section 10.3 to be clearer= > about the threats posed by any use of a non-congestion avoiding > transport protocol or to do that in the Security Considerations section= >=20 > Scott >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix >=20 *************************************************************************= *************************=20 E-mail Confidentiality Notice and Disclaimer.=20 This e-mail and any files transmitted with it are confidential and are in= tended solely for the use=20 of the individual or entity to which they are addressed. Access to this e= -mail by anyone else is=20 unauthorised. If you are not the intended recipient, any disclosure, copy= ing, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. E-m= ail messages are not=20 necessarily secure. Hitachi does not accept responsibility for any change= s made to this message=20 after it was sent.=20 Hitachi checks outgoing e-mail messages for the presence of computer viru= ses.=20 *************************************************************************= ************************* ------_=_NextPart_001_01C800DC.324BDF5C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.ietf.org/internet-drafts/draft-ietf-i= pfix-implementation-guidelines-07.txt

might address your concerns.

I'm copying the UDP section here below for your convenience.

Elisa


---

6.2.  UDP

   UDP is useful in simple systems where an SCTP stack is not a= vailable,
   and where there is insufficient memory for TCP buffering.
   However, UDP is not a reliable transport protocol, and IPFIX= =20messages
   sent over UDP might be lost as with partially-reliable SCTP = streams.
   UDP is not the recommended protocol for IPFIX and is intende= d for use
   in cases in which IPFIX is replacing an existing NetFlow
=    infrastructure, with the following properties:

   o  A dedicated network,

   o  within a single administrative domain,

   o  where SCTP is not available due to implementation co= nstraints,

   o  and the collector is as topographically close as pos= sible to the
      exporter.

   Note that because UDP itself provides no congestion control<= BR>    mechanisms, it is recommended to use UDP transport only on m= anaged
   networks, where the network path has been explicitly provisi= oned for
   IPFIX traffic through traffic engineering mechanisms, such a= s rate
   limiting or capacity reservations.

   An important example of an explicitly provisioned managed ne= twork for
   IPFIX is use of IPFIX to replace a functioning NetFlow imple= mentation
   on a dedicated network.  In this situation, the dedicat= ed network
   should be provisioned in accordance with the NetFlow deploym= ent
   experience that flow export traffic generated by monitoring = an
   interface will amount to 2-5% of the monitored interface's b= andwidth.

   As recommended in [I-D.ietf-tsvwg-udp-guidelines] an applica= tion
   SHOULD NOT send UDP messages that result in IP packets that = exceed
   the MTU of the path to the destination and SHOULD enable UDP=
   checksums (see sections 3.2 and 3.4 of
   [I-D.ietf-tsvwg-udp-guidelines] respectively).

   Since IPFIX assumes reliable transport of templates over SCT= P, this
   necessitates some changes for IPFIX template management over= =20UDP.
   Templates sent from the Exporting Process to the Collecting = Process
   over UDP MUST be resent at regular time intervals; these int= ervals
   MUST be configurable.

   We recommend a default Template resend time of 10 minutes,    configurable between 1 minute and 1 day.

   Note that this could become an interoperability problem, e.g= . if an
   Exporter re-sends Templates once per day, while a Collector = expires
   Templates hourly, then they may both be IPFIX-compatible, bu= t not be
   interoperable.

   Retransmission time intervals that are too short waste bandw= idth on
   unnecessary template retransmissions.  On the other han= d, time
   intervals that are too long introduce additional costs or ri= sk of
   data loss by potentially requiring the Collector to cache mo= re data
   without having the Templates available to decode it.

   To increase reliability and limit the amount of potentially = lost data
   the Exporting Process MAY resend additional templates using = a packet-
   based schedule.  In this case Templates are resent depe= nding on the
   number of data packets sent.  Similarly to the time int= erval,
   resending a Template every few packets introduces additional= =20overhead
   while resending after a large amount of packets have already= =20been
   sent means high costs due to the data caching and potential = data
   loss.

   We recommend a default Template resend interval of 20 packet= s,
   configurable between 1 and 1000 packets.

   Note that a sufficiently small resend time or packet interva= l may
   cause a system to become stuck, continually re-sending templ= ates.
   e.g., if the resend packet interval is 2 (i.e., templates ar= e to be
   sent in every other packet) but more than two packets are re= quired to
   send all the templates, then the resend interval will have e= xpired by
   the time the templates have been sent, and templates will be= =20sent
   continuously - possibly preventing any data from being sent = at all.
   Therefore the Template resend intervals should be considered= =20from the
   last data packet, and should not be tied to specific sequenc= e
   numbers.

   The Collecting Process SHOULD use the Sequence Number in the= =20IPFIX
   Message header to determine whether any messages are lost.
   The following may be done to mitigate message loss:

   o  Move the Collector topologically closer to the Expor= ter.

   o  Increase the bandwidth of the links through which th= e Data Records
      are exported.

   o  Use sampling, filtering, or aggregation in the Meter= ing Process to
      reduce the amount of exported data.

   o  Increase the buffer size at the Collector and/or the= =20Exporter.

   Before using a Template for the first time, the Exporter may= =20send it
   in several different IPFIX Messages spaced out over a period= =20of
   packets in order to increase the likelihood that the Collect= or has
   received the Template.

   Template Withdraw messages MUST NOT be sent over UDP; the Ex= porter
   must rely on expiration at the Collector to expire old Templ= ates or
   to reuse Template Ids.

   We recommend that the collector implements a template expiry= =20of three
   times the Exporter refresh rate.

   However, since the IPFIX protocol doesn't provide any mechan= ism for
   the Exporter to convey any information about the Template ex= piry time
   to the Collector, configuration must be done out of band.
   If no out of band configuration is made, we recommend to ini= tially
   set a template expiry time at the Collector of 60 minutes.&n= bsp; The
   Collecting Process MAY estimate each Exporting Process's res= end time
   and adapt the expiry time for the corresponding Templates    accordingly.

Scott O. Bradner wrote:
> I reviewed draft-ietf-ipfix-protocol-26.txt as part of the Transport=
> Area review effort.
>
> I did not find any particular issues in the described technology - a= =20few
> nits:
>
> section 3.1 "Export Time" someday the IETF needs to stop u= sing 32-bit
> "seconds since 1 jan 1970" for timing - at least within in= =20the next 31
> years
>
> section 6.1.2 - it might be reasonable to add the IEEE 8-byte MAC > address as an address type - this is used in ZigBee and may be in wi= der
> use in the future
>
> section 10.3.3 - a max packet size of 1280 could be used if the
> connection is known to be running in an IPv6-only environment
>
> I'm not sure why the packet size discussion is only listed for UDP -= =20it
> seems like the same restriction should apply to all protocols -
> fragmentation is not your friend
>
> Historically the biggest issue with IPFIX has been that most
> implementers want to run it over UDP with consequences be dammed.&nb= sp; -
> this was weaseled in the IPFIX Requirements document (RFC 3917) by > requiring (in section 6.3.1) that "For the data transfer, a con= gestion
> aware protocol must be supported."  This draft meets that = requirement by
> making the implementation of SCTP a MUST.  That will not stop m= any
> implementers from ignoring the requirement for implementation or use= rs
> to enable UDP and thus creating a potentially very high bandwidth > non-congestion avoiding fire hose that can quite easily wipe out a n= et
> by misconfiguration or become a DoS engine by purposeful configurati= on.
>
> I'm not sure if anything can be actually be done about this risk - I= t
> might help some to say that UDP is a "MUST NOT" but I doub= t it - in any
> case it would help somewhat, imho, to expand section 10.3 to be clea= rer
> about the threats posed by any use of a non-congestion avoiding
> transport protocol or to do that in the Security Considerations sect= ion
>
> Scott
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www= 1.ietf.org/mailman/listinfo/ipfix
>


************= *************************************************************************= *************
E-mail=20 Confidentiality Notice and Disclaimer.

This e-mail and any files transmitted with it are confiden= tial and=20 are intended solely for the use of the individual or entity to which they= =20are=20 addressed. Access to this e-mail by anyone else is unauthorised. If you a= re not=20 the intended recipient, any disclosure, copying, distribution or any acti= on=20 taken or omitted to be taken in reliance on it, is prohibited.
E-mail= =20 messages are not necessarily secure.
Hitachi does not accept responsi= bility=20 for any changes made to this message after it was sent.
Hitachi checks= =20 outgoing e-mail messages for the presence of computer viruses.=20
*********************************************************************= *****************************=20

------_=_NextPart_001_01C800DC.324BDF5C-- --===============0247319720== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0247319720==-- From ietf-bounces@ietf.org Wed Oct 03 08:48:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3Vp-0007Xo-Ve; Wed, 03 Oct 2007 08:39:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIVM-0006zG-5M; Fri, 28 Sep 2007 12:15:52 -0400 Received: from newtla.xelerance.com ([193.110.157.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbIVK-0005mi-SW; Fri, 28 Sep 2007 12:15:52 -0400 Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id A12E9C024; Fri, 28 Sep 2007 12:16:20 -0400 (EDT) Date: Fri, 28 Sep 2007 12:16:20 -0400 (EDT) From: Paul Wouters To: Joe Abley In-Reply-To: <21112CF5-0ABE-4509-8B1D-1C5AB74FFDCB@ca.afilias.info> Message-ID: References: <200709281015.l8SAFwfq087916@bartok.nlnetlabs.nl> <20070928071931.GA21696@nic.fr> <200709281015.l8SAFwfq087916@bartok.nlnetlabs.nl> <3B1D547E-0F40-4A6D-B786-EB765E58A7F2@isc.org> <21112CF5-0ABE-4509-8B1D-1C5AB74FFDCB@ca.afilias.info> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Wed, 03 Oct 2007 08:39:18 -0400 Cc: dnsop@ietf.org, Paul Hoffman , ietf@ietf.org Subject: Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Fri, 28 Sep 2007, Joe Abley wrote: > I'm surprised by that comment. > > I think it's a common use case that organisations who deploy VPNs have split > DNS; that is, namespaces available through internal network resolvers that do > not appear in the global namespace. In my experience, it is normal for: > > - VPN client software to use IP addresses rather than names to establish a > secure tunnel with the home network If you are a worldwide organisation, you want to connect to the nearest VPN point, and not your "home vpn point". This is done by customising DNS answers (eg bind views or akamai like setups). The last thing I want is for my Dutch branch, to connect me to the company vpn in The Netherlands, when I'm in the US, crossing the atlantic twice. You only start to use the internal company's DNS server, after you have connected to the VPN - if only to resolve internal network only machines. Paul _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 08:48:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3Vq-0007Y0-I6; Wed, 03 Oct 2007 08:39:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbNOS-0003T8-V2; Fri, 28 Sep 2007 17:29:04 -0400 Received: from newtla.xelerance.com ([193.110.157.143]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbNOS-0008IJ-Kx; Fri, 28 Sep 2007 17:29:04 -0400 Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id F0589C029; Fri, 28 Sep 2007 17:29:43 -0400 (EDT) Date: Fri, 28 Sep 2007 17:29:43 -0400 (EDT) From: Paul Wouters To: Dean Anderson In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-Mailman-Approved-At: Wed, 03 Oct 2007 08:39:18 -0400 Cc: dnsop@ietf.org, Paul Hoffman , ietf@ietf.org Subject: Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Fri, 28 Sep 2007, Dean Anderson wrote: > Maybe its not mentioned because its not a practical solution. But > whatever the reason it isn't mentioned, a 25 million user VPN is not > going to happen with 10/8. A comcast person recently complained on PPML > that there wasn't enough RFC1918 space for their internal network. Time for them to migrate to IPv6? :) Paul _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 08:48:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3Vo-0007XW-TX; Wed, 03 Oct 2007 08:39:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIN3-0008Bv-UD; Fri, 28 Sep 2007 12:07:17 -0400 Received: from newtla.xelerance.com ([193.110.157.143]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbIN3-0004Oj-Jh; Fri, 28 Sep 2007 12:07:17 -0400 Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id 56C86C023; Fri, 28 Sep 2007 12:07:56 -0400 (EDT) Date: Fri, 28 Sep 2007 12:07:56 -0400 (EDT) From: Paul Wouters To: Jaap Akkerhuis In-Reply-To: <200709281015.l8SAFwfq087916@bartok.nlnetlabs.nl> Message-ID: References: <200709281015.l8SAFwfq087916@bartok.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-Mailman-Approved-At: Wed, 03 Oct 2007 08:39:18 -0400 Cc: dnsop@ietf.org, ietf@ietf.org Subject: Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Fri, 28 Sep 2007, Jaap Akkerhuis wrote: > There are two major reasons for an organization to not want roaming > users to trust locally-assigned DNS servers. > > Open recursive servers doesn't help in against man in the middle > attacks. If you want to avoid that use VPN's or (for DNS) TSIG. That's why you want your own caching resolver on your laptop. But I guess hotspots won't work as well with that. Then again, the whole captive portal by hacking up DNS packets needs to go away when DNSSEC deployment deems that interfering inappropriate. Is there some IETF work going on to standarize captive portal bootstraps? Paul _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 08:48:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3Vr-0007YD-4c; Wed, 03 Oct 2007 08:39:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcMoy-0001jV-QS; Mon, 01 Oct 2007 11:04:32 -0400 Received: from mucmx01.ixos.de ([149.235.128.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcMou-0005Dp-6s; Mon, 01 Oct 2007 11:04:28 -0400 Received: from mucpm01.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l91F4JBW004486; Mon, 1 Oct 2007 17:04:20 +0200 (MEST) Received: from MUCXGC2.opentext.net (mucxg04.opentext.net [149.235.128.138]) by mucpm01.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id l91F4Iwc027028; Mon, 1 Oct 2007 11:04:18 -0400 (envelope-from tgondrom@opentext.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Oct 2007 17:04:17 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A786801AB1F20@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir] security review of draft-edwards-urn-smpte-02 Thread-Index: AcgEPFapcdF0JlIOSU2Nh0D4fhQHmA== From: "Tobias Gondrom" To: , , X-Archived: msg.AEkjesn:2007-10-01:mucpm01.smtp.dmz.opentext.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2fe944273194be3112d13b31c91e6941 X-Mailman-Approved-At: Wed, 03 Oct 2007 08:39:15 -0400 Cc: tedwards@pbs.org, ietf@ietf.org Subject: [secdir] security review of draft-edwards-urn-smpte-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0019752620==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============0019752620== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8043C.56D6BA38" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8043C.56D6BA38 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello,=20 I have re-reviewed this document (draft-edwards-urn-smpte-02) as part of = the security directorate's ongoing effort to review all IETF documents = being processed by the IESG. =20 These comments were written primarily for the benefit of the security = area directors. Document editor should treat these comments just like = any other last call comments. Note: this is a revisit of the document as the first security review has = been conducted on version-01 on May 8th, 2007 with no major findings but = 5 comments. I still agree with the author that this document introduces no security = issues other than those normally associated with the use and resolution = of URNs in general.=20 All comments from the former security review have been resolved.=20 No new problems have been introduced. Which leaves two minor comments on version-02: 1. minor editorial comment:=20 Section 8 references:=20 "Society of Motion Picture and Television Engineers, "Uniform Resource Names for SMPTE Resources", SMPTE 2029, (to be published)." Should be changed to=20 "Society of Motion Picture and Television Engineers, "Uniform Resource Names for SMPTE Resources", SMPTE 2029-2007 " As the SMPTE-2029-2007 document has been actually published (as had been = required for the draft to proceed).=20 Now just the reference text needs to be updated.=20 2. and the personal comment/note from the version-01 remains as I did = not receive feedback on this one:=20 a) I am not sure that SMPTE really needs a formal URN, and why an = informal URN would not be sufficient. But this should be decided by the = community.=20 Note: draft version-02 introduced some justification about the need for = this new namespace in section 5 of the draft. But from my personal view = this mainly equals to "we need our(SMPTE) own URN which is exclusively = under our(SMPTE) control". As a reason this may not be considered a real = reason/value by itself and thus may not be sufficient.=20 b) As the organization seems mainly focussed on the North American = Continent, it might also be a good idea to pursue via independent expert = reviews the question whether there exist potential namespace conflicts = with other international organizations in this area (Motion Picture and = Television) like e.g. ARIB (Association of Radio Industries and = Businesses) or others.=20 Best regards, Tobias Gondrom __________________________________________ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/ =20 Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, = Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 = 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: = M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number = /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton, Walter K=F6hler ------_=_NextPart_001_01C8043C.56D6BA38 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [secdir] security review of draft-edwards-urn-smpte-02

Hello,

I = have re-reviewed this document = (draft-edwards-urn-smpte-02) = as part of the security directorate's ongoing effort to review all IETF = documents being processed by the IESG.  =

These = comments were written primarily for the benefit of the security area = directors.  Document editor should treat these comments just like = any other last call comments.

Note: this is a revisit of the document as the first = security review has been conducted on version-01 = on May 8th, = 2007 with no major findings = but 5 comments.

I still agree with the author that this document introduces no = security issues other than those normally associated with the use and = resolution of URNs in general.


All = comments from the former security review have been resolved. =

No = new problems have been introduced.


Which = leaves two = minor comments on version-02:

1. = minor = editorial comment:

Section 8 references:

Society of Motion Picture and Television = Engineers,

"Uniform Resource Names for SMPTE Resources", = SMPTE 2029,

<http://www.smpte.org> (to be = published).

Should be changed to

Society of Motion Picture and Television = Engineers,

"Uniform Resource Names for SMPTE Resources", = SMPTE 2029-2007

<http://www.smpte.org><= SPAN LANG=3D"de">

As = the SMPTE-2029-2007 document has been actually published (as had been required for the draft = to proceed).

Now = just the reference text needs to be updated.


2. = and the personal = comment/note = from the version-01 remains = as I did not receive feedback on this one:

a) I = am not sure that SMPTE really needs a formal URN, and why an informal = URN would not be sufficient. But this should be decided by the = community.

Note: = draft version-02 introduced some justification about the = need for this new namespace in section 5 of the = draft. = But from my personal = view this mainly equals to we need our(SMPTE) = own URN = which is exclusively under our(SMPTE) control. As a reason this may not be considered a real reason/value by = itself = and thus may = not be sufficient. =

b) As = the organization seems mainly focussed on the North American Continent, = it might also be a good idea to pursue via independent expert reviews = the question whether there exist potential namespace conflicts with = other international organizations in this area (Motion Picture and = Television) like e.g. ARIB (Association of Radio Industries and = Businesses) or others.



Best = regards, Tobias Gondrom




__________________________________________
Tobias = Gondrom
Head of = Open Text Security Team
Director, Product Security

Open = Text
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail:
mailto:tobias.gondrom@opentex= t.com
Internet: http://www.opentext.com/  =

Place = of Incorporation / Sitz der Gesellschaft: Open Text GmbH, = Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 = 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: = M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number = /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton, Walter K=F6hler

------_=_NextPart_001_01C8043C.56D6BA38-- --===============0019752620== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0019752620==-- From ietf-bounces@ietf.org Wed Oct 03 08:48:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3Vr-0007YD-4c; Wed, 03 Oct 2007 08:39:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcMoy-0001jV-QS; Mon, 01 Oct 2007 11:04:32 -0400 Received: from mucmx01.ixos.de ([149.235.128.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcMou-0005Dp-6s; Mon, 01 Oct 2007 11:04:28 -0400 Received: from mucpm01.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l91F4JBW004486; Mon, 1 Oct 2007 17:04:20 +0200 (MEST) Received: from MUCXGC2.opentext.net (mucxg04.opentext.net [149.235.128.138]) by mucpm01.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id l91F4Iwc027028; Mon, 1 Oct 2007 11:04:18 -0400 (envelope-from tgondrom@opentext.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Oct 2007 17:04:17 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A786801AB1F20@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir] security review of draft-edwards-urn-smpte-02 Thread-Index: AcgEPFapcdF0JlIOSU2Nh0D4fhQHmA== From: "Tobias Gondrom" To: , , X-Archived: msg.AEkjesn:2007-10-01:mucpm01.smtp.dmz.opentext.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2fe944273194be3112d13b31c91e6941 X-Mailman-Approved-At: Wed, 03 Oct 2007 08:39:15 -0400 Cc: tedwards@pbs.org, ietf@ietf.org Subject: [secdir] security review of draft-edwards-urn-smpte-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0019752620==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============0019752620== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8043C.56D6BA38" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8043C.56D6BA38 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello,=20 I have re-reviewed this document (draft-edwards-urn-smpte-02) as part of = the security directorate's ongoing effort to review all IETF documents = being processed by the IESG. =20 These comments were written primarily for the benefit of the security = area directors. Document editor should treat these comments just like = any other last call comments. Note: this is a revisit of the document as the first security review has = been conducted on version-01 on May 8th, 2007 with no major findings but = 5 comments. I still agree with the author that this document introduces no security = issues other than those normally associated with the use and resolution = of URNs in general.=20 All comments from the former security review have been resolved.=20 No new problems have been introduced. Which leaves two minor comments on version-02: 1. minor editorial comment:=20 Section 8 references:=20 "Society of Motion Picture and Television Engineers, "Uniform Resource Names for SMPTE Resources", SMPTE 2029, (to be published)." Should be changed to=20 "Society of Motion Picture and Television Engineers, "Uniform Resource Names for SMPTE Resources", SMPTE 2029-2007 " As the SMPTE-2029-2007 document has been actually published (as had been = required for the draft to proceed).=20 Now just the reference text needs to be updated.=20 2. and the personal comment/note from the version-01 remains as I did = not receive feedback on this one:=20 a) I am not sure that SMPTE really needs a formal URN, and why an = informal URN would not be sufficient. But this should be decided by the = community.=20 Note: draft version-02 introduced some justification about the need for = this new namespace in section 5 of the draft. But from my personal view = this mainly equals to "we need our(SMPTE) own URN which is exclusively = under our(SMPTE) control". As a reason this may not be considered a real = reason/value by itself and thus may not be sufficient.=20 b) As the organization seems mainly focussed on the North American = Continent, it might also be a good idea to pursue via independent expert = reviews the question whether there exist potential namespace conflicts = with other international organizations in this area (Motion Picture and = Television) like e.g. ARIB (Association of Radio Industries and = Businesses) or others.=20 Best regards, Tobias Gondrom __________________________________________ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/ =20 Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, = Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 = 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: = M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number = /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton, Walter K=F6hler ------_=_NextPart_001_01C8043C.56D6BA38 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [secdir] security review of draft-edwards-urn-smpte-02

Hello,

I = have re-reviewed this document = (draft-edwards-urn-smpte-02) = as part of the security directorate's ongoing effort to review all IETF = documents being processed by the IESG.  =

These = comments were written primarily for the benefit of the security area = directors.  Document editor should treat these comments just like = any other last call comments.

Note: this is a revisit of the document as the first = security review has been conducted on version-01 = on May 8th, = 2007 with no major findings = but 5 comments.

I still agree with the author that this document introduces no = security issues other than those normally associated with the use and = resolution of URNs in general.


All = comments from the former security review have been resolved. =

No = new problems have been introduced.


Which = leaves two = minor comments on version-02:

1. = minor = editorial comment:

Section 8 references:

Society of Motion Picture and Television = Engineers,

"Uniform Resource Names for SMPTE Resources", = SMPTE 2029,

<http://www.smpte.org> (to be = published).

Should be changed to

Society of Motion Picture and Television = Engineers,

"Uniform Resource Names for SMPTE Resources", = SMPTE 2029-2007

<http://www.smpte.org><= SPAN LANG=3D"de">

As = the SMPTE-2029-2007 document has been actually published (as had been required for the draft = to proceed).

Now = just the reference text needs to be updated.


2. = and the personal = comment/note = from the version-01 remains = as I did not receive feedback on this one:

a) I = am not sure that SMPTE really needs a formal URN, and why an informal = URN would not be sufficient. But this should be decided by the = community.

Note: = draft version-02 introduced some justification about the = need for this new namespace in section 5 of the = draft. = But from my personal = view this mainly equals to we need our(SMPTE) = own URN = which is exclusively under our(SMPTE) control. As a reason this may not be considered a real reason/value by = itself = and thus may = not be sufficient. =

b) As = the organization seems mainly focussed on the North American Continent, = it might also be a good idea to pursue via independent expert reviews = the question whether there exist potential namespace conflicts with = other international organizations in this area (Motion Picture and = Television) like e.g. ARIB (Association of Radio Industries and = Businesses) or others.



Best = regards, Tobias Gondrom




__________________________________________
Tobias = Gondrom
Head of = Open Text Security Team
Director, Product Security

Open = Text
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail:
mailto:tobias.gondrom@opentex= t.com
Internet: http://www.opentext.com/  =

Place = of Incorporation / Sitz der Gesellschaft: Open Text GmbH, = Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 = 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: = M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number = /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton, Walter K=F6hler

------_=_NextPart_001_01C8043C.56D6BA38-- --===============0019752620== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0019752620==-- From ietf-bounces@ietf.org Wed Oct 03 08:48:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3Vp-0007Xo-Ve; Wed, 03 Oct 2007 08:39:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIVM-0006zG-5M; Fri, 28 Sep 2007 12:15:52 -0400 Received: from newtla.xelerance.com ([193.110.157.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbIVK-0005mi-SW; Fri, 28 Sep 2007 12:15:52 -0400 Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id A12E9C024; Fri, 28 Sep 2007 12:16:20 -0400 (EDT) Date: Fri, 28 Sep 2007 12:16:20 -0400 (EDT) From: Paul Wouters To: Joe Abley In-Reply-To: <21112CF5-0ABE-4509-8B1D-1C5AB74FFDCB@ca.afilias.info> Message-ID: References: <200709281015.l8SAFwfq087916@bartok.nlnetlabs.nl> <20070928071931.GA21696@nic.fr> <200709281015.l8SAFwfq087916@bartok.nlnetlabs.nl> <3B1D547E-0F40-4A6D-B786-EB765E58A7F2@isc.org> <21112CF5-0ABE-4509-8B1D-1C5AB74FFDCB@ca.afilias.info> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Wed, 03 Oct 2007 08:39:18 -0400 Cc: dnsop@ietf.org, Paul Hoffman , ietf@ietf.org Subject: Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Fri, 28 Sep 2007, Joe Abley wrote: > I'm surprised by that comment. > > I think it's a common use case that organisations who deploy VPNs have split > DNS; that is, namespaces available through internal network resolvers that do > not appear in the global namespace. In my experience, it is normal for: > > - VPN client software to use IP addresses rather than names to establish a > secure tunnel with the home network If you are a worldwide organisation, you want to connect to the nearest VPN point, and not your "home vpn point". This is done by customising DNS answers (eg bind views or akamai like setups). The last thing I want is for my Dutch branch, to connect me to the company vpn in The Netherlands, when I'm in the US, crossing the atlantic twice. You only start to use the internal company's DNS server, after you have connected to the VPN - if only to resolve internal network only machines. Paul _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 08:48:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3Vq-0007Y0-I6; Wed, 03 Oct 2007 08:39:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbNOS-0003T8-V2; Fri, 28 Sep 2007 17:29:04 -0400 Received: from newtla.xelerance.com ([193.110.157.143]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbNOS-0008IJ-Kx; Fri, 28 Sep 2007 17:29:04 -0400 Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id F0589C029; Fri, 28 Sep 2007 17:29:43 -0400 (EDT) Date: Fri, 28 Sep 2007 17:29:43 -0400 (EDT) From: Paul Wouters To: Dean Anderson In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-Mailman-Approved-At: Wed, 03 Oct 2007 08:39:18 -0400 Cc: dnsop@ietf.org, Paul Hoffman , ietf@ietf.org Subject: Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Fri, 28 Sep 2007, Dean Anderson wrote: > Maybe its not mentioned because its not a practical solution. But > whatever the reason it isn't mentioned, a 25 million user VPN is not > going to happen with 10/8. A comcast person recently complained on PPML > that there wasn't enough RFC1918 space for their internal network. Time for them to migrate to IPv6? :) Paul _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 08:48:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3Vp-0007Xo-Ve; Wed, 03 Oct 2007 08:39:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIVM-0006zG-5M; Fri, 28 Sep 2007 12:15:52 -0400 Received: from newtla.xelerance.com ([193.110.157.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbIVK-0005mi-SW; Fri, 28 Sep 2007 12:15:52 -0400 Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id A12E9C024; Fri, 28 Sep 2007 12:16:20 -0400 (EDT) Date: Fri, 28 Sep 2007 12:16:20 -0400 (EDT) From: Paul Wouters To: Joe Abley In-Reply-To: <21112CF5-0ABE-4509-8B1D-1C5AB74FFDCB@ca.afilias.info> Message-ID: References: <200709281015.l8SAFwfq087916@bartok.nlnetlabs.nl> <20070928071931.GA21696@nic.fr> <200709281015.l8SAFwfq087916@bartok.nlnetlabs.nl> <3B1D547E-0F40-4A6D-B786-EB765E58A7F2@isc.org> <21112CF5-0ABE-4509-8B1D-1C5AB74FFDCB@ca.afilias.info> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Wed, 03 Oct 2007 08:39:18 -0400 Cc: dnsop@ietf.org, Paul Hoffman , ietf@ietf.org Subject: Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Fri, 28 Sep 2007, Joe Abley wrote: > I'm surprised by that comment. > > I think it's a common use case that organisations who deploy VPNs have split > DNS; that is, namespaces available through internal network resolvers that do > not appear in the global namespace. In my experience, it is normal for: > > - VPN client software to use IP addresses rather than names to establish a > secure tunnel with the home network If you are a worldwide organisation, you want to connect to the nearest VPN point, and not your "home vpn point". This is done by customising DNS answers (eg bind views or akamai like setups). The last thing I want is for my Dutch branch, to connect me to the company vpn in The Netherlands, when I'm in the US, crossing the atlantic twice. You only start to use the internal company's DNS server, after you have connected to the VPN - if only to resolve internal network only machines. Paul _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 08:48:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3Vq-0007Y0-I6; Wed, 03 Oct 2007 08:39:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbNOS-0003T8-V2; Fri, 28 Sep 2007 17:29:04 -0400 Received: from newtla.xelerance.com ([193.110.157.143]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbNOS-0008IJ-Kx; Fri, 28 Sep 2007 17:29:04 -0400 Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id F0589C029; Fri, 28 Sep 2007 17:29:43 -0400 (EDT) Date: Fri, 28 Sep 2007 17:29:43 -0400 (EDT) From: Paul Wouters To: Dean Anderson In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-Mailman-Approved-At: Wed, 03 Oct 2007 08:39:18 -0400 Cc: dnsop@ietf.org, Paul Hoffman , ietf@ietf.org Subject: Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Fri, 28 Sep 2007, Dean Anderson wrote: > Maybe its not mentioned because its not a practical solution. But > whatever the reason it isn't mentioned, a 25 million user VPN is not > going to happen with 10/8. A comcast person recently complained on PPML > that there wasn't enough RFC1918 space for their internal network. Time for them to migrate to IPv6? :) Paul _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 08:52:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3dm-0000pL-EG; Wed, 03 Oct 2007 08:47:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ictpv-0004ds-VY for ietf@ietf.org; Tue, 02 Oct 2007 22:19:43 -0400 Received: from inc.inetcore.com ([2001:200:562:101::11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ictps-00045L-N5 for ietf@ietf.org; Tue, 02 Oct 2007 22:19:41 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by inc.inetcore.com (Postfix) with ESMTP id C61E4D51CEC; Wed, 3 Oct 2007 11:19:15 +0900 (JST) In-Reply-To: <20071002133200.GI14394@login.ecs.soton.ac.uk> References: <01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com> <4697DC68.9060808@gmx.net> <03f001c804e0$92860060$6a01a8c0@DRTVnet1> <47024223.7000508@cs.utk.edu> <20071002133200.GI14394@login.ecs.soton.ac.uk> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <37DB6E3B-154B-4588-8CF6-26CD411A1DB0@inetcore.com> Content-Transfer-Encoding: 7bit From: Ruri Hiromi Date: Wed, 3 Oct 2007 11:19:12 +0900 To: Tim Chown X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -1.4 (-) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-Mailman-Approved-At: Wed, 03 Oct 2007 08:47:47 -0400 Cc: ietf@ietf.org Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org dedicate to ostriches... http://www.apple.com/en/downloads/dashboard/networking_security/ ipv420.html On 2007/10/02, at 22:32, Tim Chown wrote: > On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote: >> Ray Plzak wrote: >>> The shortage of IPv4 addresses in developing countries in a red >>> herring. >> that has to rank as one of the most bizarre statements that's ever >> been >> made on the ietf list. > > More of an ostrich than a herring? > > > .="""=._ > / ., .`. > /__(,_.-' || > ` /| || > / | || > \| || > ~~~~~ ~ |\ ~~!)~~~~~~~ > > > Tim > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf ------------------------------- Ruri Hiromi hiromi@inetcore.com _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 09:13:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3sG-00017P-6n; Wed, 03 Oct 2007 09:02:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3sC-0000Fb-K1 for ietf@ietf.org; Wed, 03 Oct 2007 09:02:45 -0400 Received: from alnrmhc15.comcast.net ([204.127.225.95]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id3rp-00009j-VK for ietf@ietf.org; Wed, 03 Oct 2007 09:02:22 -0400 Received: from [10.0.1.35] (c-66-31-246-32.hsd1.ma.comcast.net[66.31.246.32]) by comcast.net (alnrmhc15) with ESMTP id <20071003130220b15002achre>; Wed, 3 Oct 2007 13:02:21 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com> <4697DC68.9060808@gmx.net> <03f001c804e0$92860060$6a01a8c0@DRTVnet1> <47024223.7000508@cs.utk.edu> <20071002133200.GI14394@login.ecs.soton.ac.uk> <4702AC72.8070907@gmail.com> Date: Wed, 3 Oct 2007 09:00:36 -0400 To: Ray Plzak , Brian E Carpenter From: John Day Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Tim Chown , "ietf@ietf.org" Subject: RE: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org If IANA had any resolve there are at least 25 -30 Class A blocks that should be reclaimed and are not or should not be part of the public Internet address space. At 6:56 -0400 2007/10/03, Ray Plzak wrote: >Brian, > >My comment was regarding a head in the sand approach when it comes >to the recurring themes that the developing world can't IP address >space, whether it is v4 or v6. The fact is that they can get it from >the RIR like those in the developed regions can get it from their >RIRs. The real problem, in other words, putting head in sand, is to >substitute this address space access issue for the real one of what >can the recipients of the address space do with it when they get, >particularly if they have no hardware to run it on, no electricity >to power it, and no upstream willing to route it. It is those issues >that need to be hit head on if the Internet is to really grow in the >developing regions of the globe. > >Ray > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Tuesday, October 02, 2007 4:39 PM >> To: Ray Plzak >> Cc: Tim Chown; ietf@ietf.org >> Subject: Re: IPv4 to IPv6 transition >> >> Ray, >> >> I don't think it's quite fair to refer to ostriches >> when ARIN is already on record: >> http://www.arin.net/v6/v6-resolution.html >> >> Also, for those who like to see things in real time, >> there's always http://penrose.uk6x.com/ >> >> Regards >> Brian Carpenter >> University of Auckland >> >> >> >> >> On 2007-10-03 02:47, Ray Plzak wrote: >> > Head in the sand is substituting the statement "shortage of IP >> addresses" for the condition of the inability to use the addresses >> (take your pick when it comes to infrastructure deficiencies). >> > >> > Ray >> > >> >> -----Original Message----- >> >> From: Tim Chown [mailto:tjc@ecs.sotonFrom ietf-bounces@ietf.org Wed Oct 03 09:13:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3sG-00017P-6n; Wed, 03 Oct 2007 09:02:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3sC-0000Fb-K1 for ietf@ietf.org; Wed, 03 Oct 2007 09:02:45 -0400 Received: from alnrmhc15.comcast.net ([204.127.225.95]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id3rp-00009j-VK for ietf@ietf.org; Wed, 03 Oct 2007 09:02:22 -0400 Received: from [10.0.1.35] (c-66-31-246-32.hsd1.ma.comcast.net[66.31.246.32]) by comcast.net (alnrmhc15) with ESMTP id <20071003130220b15002achre>; Wed, 3 Oct 2007 13:02:21 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com> <4697DC68.9060808@gmx.net> <03f001c804e0$92860060$6a01a8c0@DRTVnet1> <47024223.7000508@cs.utk.edu> <20071002133200.GI14394@login.ecs.soton.ac.uk> <4702AC72.8070907@gmail.com> Date: Wed, 3 Oct 2007 09:00:36 -0400 To: Ray Plzak , Brian E Carpenter From: John Day Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Tim Chown , "ietf@ietf.org" Subject: RE: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org If IANA had any resolve there are at least 25 -30 Class A blocks that should be reclaimed and are not or should not be part of the public Internet address space. At 6:56 -0400 2007/10/03, Ray Plzak wrote: >Brian, > >My comment was regarding a head in the sand approach when it comes >to the recurring themes that the developing world can't IP address >space, whether it is v4 or v6. The fact is that they can get it from >the RIR like those in the developed regions can get it from their >RIRs. The real problem, in other words, putting head in sand, is to >substitute this address space access issue for the real one of what >can the recipients of the address space do with it when they get, >particularly if they have no hardware to run it on, no electricity >to power it, and no upstream willing to route it. It is those issues >that need to be hit head on if the Internet is to really grow in the >developing regions of the globe. > >Ray > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Tuesday, October 02, 2007 4:39 PM >> To: Ray Plzak >> Cc: Tim Chown; ietf@ietf.org >> Subject: Re: IPv4 to IPv6 transition >> >> Ray, >> >> I don't think it's quite fair to refer to ostriches >> when ARIN is already on record: >> http://www.arin.net/v6/v6-resolution.html >> >> Also, for those who like to see things in real time, >> there's always http://penrose.uk6x.com/ >> >> Regards >> Brian Carpenter >> University of Auckland >> >> >> >> >> On 2007-10-03 02:47, Ray Plzak wrote: >> > Head in the sand is substituting the statement "shortage of IP >> addresses" for the condition of the inability to use the addresses >> (take your pick when it comes to infrastructure deficiencies). >> > >> > Ray >> > >> >> -----Original Message----- >> >> From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] >> >> Sent: Tuesday, October 02, 2007 9:32 AM >> >> To: ietf@ietf.org >> >> Subject: Re: IPv4 to IPv6 transition >> >> >> >> On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote: >> >>> Ray Plzak wrote: >> >>>> The shortage of IPv4 addresses in developing countries in a red >> >> herring. >> >>> that has to rank as one of the most bizarre statements that's ever >> >> been >> >>> made on the ietf list. >> >> More of an ostrich than a herring? >> >> >> >> >> >> .="""=._ >> >> / ., .`. >> >> /__(,_.-' || >> >> ` /| || >> >> / | || >> >> \| || >> >> ~~~~~ ~ |\ ~~!)~~~~~~~ >> >> >> >> >> >> Tim >> >> >> >> _______________________________________________ >> >> Ietf mailing list >> >> Ietf@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/ietf >> > >> > >> > _______________________________________________ >> > Ietf mailing list >> > Ietf@ietf.org >> > https://www1.ietf.org/mailman/listinfo/ietf >> > > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 09:13:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3vt-0000lp-QL; Wed, 03 Oct 2007 09:06:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3vr-0000bY-9N for ietf@ietf.org; Wed, 03 Oct 2007 09:06:31 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id3vq-0004D6-2T for ietf@ietf.org; Wed, 03 Oct 2007 09:06:31 -0400 X-IronPort-AV: E=Sophos;i="4.21,224,1188802800"; d="scan'208";a="403642263" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 03 Oct 2007 06:06:29 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l93D6TUZ005425; Wed, 3 Oct 2007 06:06:29 -0700 Received: from pita.cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l93D6O0X012121; Wed, 3 Oct 2007 13:06:24 GMT Date: Wed, 3 Oct 2007 06:05:03 -0700 (PDT) From: Ole Jacobsen To: Marc Manthey In-Reply-To: Message-ID: References: <01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com> <4697DC68.9060808@gmx.net> <03f001c804e0$92860060$6a01a8c0@DRTVnet1> <47024223.7000508@cs.utk.edu> <20071002133200.GI14394@login.ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=840; t=1191416789; x=1192280789; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ole@cisco.com; z=From:=20Ole=20Jacobsen=20 |Subject:=20Re=3A=20IPv4=20to=20IPv6=20transition |Sender:=20; bh=ztR8ODdwTFx+I84dFdbSdyeAWWfJAFsfNpSeaQuppMc=; b=M0TJmoQhU/EHSBD2QwEmTe0N+k8EiVQDNe57tV+BqJNi1AdGEzsA0Sv+iRUYeyYeT5Yq/J2R q+N+rJstTFzXs4kGCL9UMKE4JIr8HQIfRMcpysCmeUZ1y6/1jyvg1hAR; Authentication-Results: sj-dkim-3; header.From=ole@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: IETF Discussion Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ole Jacobsen List-Id: IETF-Discussion List-Unsubscribe: > >> Sent: Tuesday, October 02, 2007 9:32 AM >> >> To: ietf@ietf.org >> >> Subject: Re: IPv4 to IPv6 transition >> >> >> >> On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote: >> >>> Ray Plzak wrote: >> >>>> The shortage of IPv4 addresses in developing countries in a red >> >> herring. >> >>> that has to rank as one of the most bizarre statements that's ever >> >> been >> >>> made on the ietf list. >> >> More of an ostrich than a herring? >> >> >> >> >> >> .="""=._ >> >> / ., .`. >> >> /__(,_.-' || >> >> ` /| || >> >> / | || >> >> \| || >> >> ~~~~~ ~ |\ ~~!)~~~~~~~ >> >> >> >> >> >> Tim >> >> >> >> _______________________________________________ >> >> Ietf mailing list >> >> Ietf@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/ietf >> > >> > >> > _______________________________________________ >> > Ietf mailing list >> > Ietf@ietf.org >> > https://www1.ietf.org/mailman/listinfo/ietf >> > > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 09:13:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3vt-0000lp-QL; Wed, 03 Oct 2007 09:06:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3vr-0000bY-9N for ietf@ietf.org; Wed, 03 Oct 2007 09:06:31 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id3vq-0004D6-2T for ietf@ietf.org; Wed, 03 Oct 2007 09:06:31 -0400 X-IronPort-AV: E=Sophos;i="4.21,224,1188802800"; d="scan'208";a="403642263" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 03 Oct 2007 06:06:29 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l93D6TUZ005425; Wed, 3 Oct 2007 06:06:29 -0700 Received: from pita.cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l93D6O0X012121; Wed, 3 Oct 2007 13:06:24 GMT Date: Wed, 3 Oct 2007 06:05:03 -0700 (PDT) From: Ole Jacobsen To: Marc Manthey In-Reply-To: Message-ID: References: <01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com> <4697DC68.9060808@gmx.net> <03f001c804e0$92860060$6a01a8c0@DRTVnet1> <47024223.7000508@cs.utk.edu> <20071002133200.GI14394@login.ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=840; t=1191416789; x=1192280789; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ole@cisco.com; z=From:=20Ole=20Jacobsen=20 |Subject:=20Re=3A=20IPv4=20to=20IPv6=20transition |Sender:=20; bh=ztR8ODdwTFx+I84dFdbSdyeAWWfJAFsfNpSeaQuppMc=; b=M0TJmoQhU/EHSBD2QwEmTe0N+k8EiVQDNe57tV+BqJNi1AdGEzsA0Sv+iRUYeyYeT5Yq/J2R q+N+rJstTFzXs4kGCL9UMKE4JIr8HQIfRMcpysCmeUZ1y6/1jyvg1hAR; Authentication-Results: sj-dkim-3; header.From=ole@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: IETF Discussion Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ole Jacobsen List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org It actually IS English, try installing, it localizes. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: ole@cisco.com URL: http://www.cisco.com/ipj On Wed, 3 Oct 2007, Marc Manthey wrote: > > On Oct 3, 2007, at 12:55 PM, Ruri Hiromi wrote: > >http://www.apple.com/jp/downloads/dashboard/networking_security/ipv420.html > > hi Ruri , > > well, i could imagine what its good for , but an english version would be > appreciated ;) > > cheers > > Marc > > -- > Marc Manthey - > LET - research + deployment > D- 50672 Cologne > Hildeboldplatz 1a > web: http://www.let.de > my xing profile > https://www.xing.com/profile/Marc_Manthey > phone &mobile: > 0049.221.355.80.32 > 0049.177.341.54.81 > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf 1.ietf.org/mailman/listinfo/ietf>, List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org It actually IS English, try installing, it localizes. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: ole@cisco.com URL: http://www.cisco.com/ipj On Wed, 3 Oct 2007, Marc Manthey wrote: > > On Oct 3, 2007, at 12:55 PM, Ruri Hiromi wrote: > >http://www.apple.com/jp/downloads/dashboard/networking_security/ipv420.html > > hi Ruri , > > well, i could imagine what its good for , but an english version would be > appreciated ;) > > cheers > > Marc > > -- > Marc Manthey - > LET - research + deployment > D- 50672 Cologne > Hildeboldplatz 1a > web: http://www.let.de > my xing profile > https://www.xing.com/profile/Marc_Manthey > phone &mobile: > 0049.221.355.80.32 > 0049.177.341.54.81 > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 09:14:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3vs-0000cR-VB; Wed, 03 Oct 2007 09:06:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3vp-0000ZM-2R for ietf@ietf.org; Wed, 03 Oct 2007 09:06:30 -0400 Received: from [2001:630:d0:f102:230:48ff:fe77:96e] (helo=owl.ecs.soton.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id3ve-0004C9-Hm for ietf@ietf.org; Wed, 03 Oct 2007 09:06:24 -0400 X-ECS-MailScanner-Watermark: 1192021553.36134@lsgR0mJWfRWRB8xSKyhB7g Received: from goose.ecs.soton.ac.uk (goose.ecs.soton.ac.uk [152.78.68.131]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id l93D5r5E023740 for ; Wed, 3 Oct 2007 14:05:53 +0100 X-ECS-MailScanner-Watermark: 1192021452.69292@crhkD5PNno/xZm5vxgC82Q Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe59:5f12]) by goose.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id l93D4Ctp009699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Oct 2007 14:04:12 +0100 Received: from login.ecs.soton.ac.uk (localhost.localdomain [127.0.0.1]) by login.ecs.soton.ac.uk (8.13.8/8.11.6) with ESMTP id l93D5eB5013254 for ; Wed, 3 Oct 2007 14:05:40 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.13.8/8.13.8/Submit) id l93D5erq013253 for ietf@ietf.org; Wed, 3 Oct 2007 14:05:40 +0100 Date: Wed, 3 Oct 2007 14:05:40 +0100 From: Tim Chown To: ietf@ietf.org Message-ID: <20071003130540.GC25531@login.ecs.soton.ac.uk> Mail-Followup-To: ietf@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-ECS-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Fri, Sep 28, 2007 at 05:29:43PM -0400, Paul Wouters wrote: > On Fri, 28 Sep 2007, Dean Anderson wrote: > > > Maybe its not mentioned because its not a practical solution. But > > whatever the reason it isn't mentioned, a 25 million user VPN is not > > going to happen with 10/8. A comcast person recently complained on PPML > > that there wasn't enough RFC1918 space for their internal network. > > Time for them to migrate to IPv6? :) http://www.6journal.org/archive/00000265/ -- Tim _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 09:14:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3sB-00010s-Nn; Wed, 03 Oct 2007 09:02:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3sA-00010l-3e for ietf@ietf.org; Wed, 03 Oct 2007 09:02:42 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id3s9-00045H-GJ for ietf@ietf.org; Wed, 03 Oct 2007 09:02:42 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id 01BE4233E9; Wed, 3 Oct 2007 22:02:36 +0900 (JST) To: marc@let.de In-Reply-To: Your message of "Wed, 3 Oct 2007 13:43:49 +0200" References: X-Mailer: Cue version 0.8 (070521-1856/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20071003130237.01BE4233E9@coconut.itojun.org> Date: Wed, 3 Oct 2007 22:02:36 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: -0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ietf@ietf.org Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > On Oct 3, 2007, at 12:55 PM, Ruri Hiromi wrote: > > http://www.apple.com/jp/downloads/dashboard/networking_security/ > > ipv420.html > > well, i could imagine what its good for , but an english version > would be appreciated ;) the widget itself is bilingual (english/japanese). itojun _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 10:07:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id4gI-0004NS-K2; Wed, 03 Oct 2007 09:54:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id4gH-0001Hj-Qy for ietf@ietf.org; Wed, 03 Oct 2007 09:54:29 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id4fv-0002GA-8N for ietf@ietf.org; Wed, 03 Oct 2007 09:54:07 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B74BA872C9; Wed, 3 Oct 2007 09:54:06 -0400 (EDT) To: ietf@ietf.org Message-Id: <20071003135406.B74BA872C9@mercury.lcs.mit.edu> Date: Wed, 3 Oct 2007 09:54:06 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: jnc@mercury.lcs.mit.edu Subject: Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > From: >> Second, you're talking about potentially orders of magnitude more >> data: for each destination, there are worldwide likely hundreds (or >> more) of ISP's which are likely to be viable backbone transits. >> ... >> With ISP's which are directly connected with a customer, one can >> assume that there's an implicit authorization, but what about steps >> past that? If one further assumes that by p connecting to q, p is >> transitively authorizing q (with respect to [destination] A), then >> that can be done with straightforward (albeit complex and expensive) >> security on routing. However, if you go that way, then you lose the >> ability for A to make assertions about which q's are not acceptable. >> However, if you go that way, then you lose the ability for A to >> assertions about which q's are not acceptable. If you add that back in >> as a policy knob ... > We have the technology to deal with orders of magnitude more data, > assuming that the task is delegated to servers, not to routers. I guess I wasn't explicit enough; I made a reference to "straightforward (albeit complex and expensive) security on routing", referring to automatic mechanisms, but didn't specifically describe them as automatic; nor did I specifically refer to the "policy knob" as being something that was manual. I'm talking about *configuration* data; i.e. something humans have to enter, and maintain. The issue is not the mechanical tasks of storing and distributing the data, but the human effort required to set up it and update it as needed, plus the likelihood (as always, when people are involved) of errors being introduced. Noel PS: The potential size of the problem is actually worse than I described above, because there's an additional axis of freedom. Not only do you have to multiply the number of destinations by the number of backbone transits, you also have to multiply by the number of destinations *again*, because destination A may think backbone transit q is fine, with respect to communicating with B, but not when it's communicating with C. Fundamentally, destination-vector systems (of which path-vector, such as BGP, are a subset) are just not suited to doing this kind of stuff. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 10:14:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id4pq-0001E1-IO; Wed, 03 Oct 2007 10:04:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id4po-0001BQ-TE for ietf@ietf.org; Wed, 03 Oct 2007 10:04:20 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id4pi-0006N7-MA for ietf@ietf.org; Wed, 03 Oct 2007 10:04:20 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F172F2596E6; Wed, 3 Oct 2007 16:04:05 +0200 (CEST) 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 13245-09; Wed, 3 Oct 2007 16:04:00 +0200 (CEST) Received: from [10.10.2.86] (unknown [62.154.197.69]) by eikenes.alvestrand.no (Postfix) with ESMTP id 67D1F259734; Wed, 3 Oct 2007 16:04:00 +0200 (CEST) Date: Wed, 03 Oct 2007 16:02:00 +0200 From: Harald Tveit Alvestrand To: Russ Housley , ietf@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 2.2 (++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org --On 2. oktober 2007 18:49 -0400 Russ Housley wrote: > The Secretariat tells me that Spammers are responding to TDMA queries so > that their mail goes through. They have made the suggestion that we > clear the list of people once per year. This would mean that a > legitimate user of a list that uses TDMA would get a TDMA query once a > year if they are not subscribed to any ietf.org mail list. There is no > TDMA query for people who are on at least one ietf.org mail list. > > Here is the info that I have: > >> > Russ wants to know how many people have responded to the TMDA >> > challenge but are not on any IETF mailing list. >> >> 1025 mail addresses have "confirmed" their address. I would bet that >> at least 20% of the confirmed are spam addresses (or autoconfirmed >> addresses) > > Thoughts? get a documented case (copy of the confirmation email + copy of the spam that got through) before jumping to conclusions. I don't think clearing the list is reasonable without relatively solid evidence that there are 200 spammers' addresses in that list. Interestingly, a confirmation email, with trace headers, is evidence of the location of a spammer that is far more solid than most kinds of evidence one can gather from just the spam; after all, the spammer was available at his MX to get and reply to the confirmation email. If the spammers were indeed auto-replying, I'd set up a honeypot running TMDA so that I could collect their whereabouts.... Harald _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 11:07:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id5gH-0001HV-Lz; Wed, 03 Oct 2007 10:58:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id5gF-0001DY-Sl; Wed, 03 Oct 2007 10:58:31 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id5gE-0008BM-Mf; Wed, 03 Oct 2007 10:58:31 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6F2EE48C4; Wed, 3 Oct 2007 10:58:21 -0400 (EDT) From: Sam Hartman To: Stephane Bortzmeyer References: <200709281015.l8SAFwfq087916@bartok.nlnetlabs.nl> <3B1D547E-0F40-4A6D-B786-EB765E58A7F2@isc.org> <20071003092538.GA31491@nic.fr> Date: Wed, 03 Oct 2007 10:58:21 -0400 In-Reply-To: <20071003092538.GA31491@nic.fr> (Stephane Bortzmeyer's message of "Wed, 3 Oct 2007 11:25:38 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: dnsop@ietf.org, ietf@ietf.org Subject: Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>>>> "Stephane" == Stephane Bortzmeyer writes: Stephane> But suggesting ORNS (Open Recursive Name Servers) for Stephane> the solution to this issue is, indeed, a bad idea (do Stephane> note I did not say the N word), for the reasons Stephane> explained in draft-ietf-dnsop-reflectors-are-evil-04.txt Stephane> (reflections attack). Hmm. All I get is that suggesting open recursive nameservers has the harm that it creates reflection attacks. The current text of section 4 to me says that you SHOULD NOT offer recursive name service by default and the generic recommendation is that you should not offer recursive name service to other clients than those you need. However if I've evaluated the harm caused by the attack, evaluated the costs of other solutions and concluded that the best tradeoff is running an open recursive nameserver, I can do so. That seems like a balanced and reasonable approach. If you intend the draft to same something else, you have some work to do. Stephane> There are other solutions to this issue and lists have Stephane> already been given in this thread *and* in the I-D we Stephane> discuss. These solutions are TSIG, local caching Stephane> resolvers and VPN. May be there is an editorial problem Stephane> if they are not well explained but the I-D does Stephane> completely cover the issue of romaing users. People have explained why the cost/benefit tradeoff may not favor these solutions. tsig is not realistic in the current software implementation space; it has promise for the future. VPN is very complicated and probably not worth it if all you want is more reliable nameservice. (I do understand the man-in-the-middle and transparent proxy issues). Caching resolvers are problematic for deployment complexity reasons . _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 11:22:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id5sH-0004UM-6b; Wed, 03 Oct 2007 11:10:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id5sG-0004U2-90 for ietf@ietf.org; Wed, 03 Oct 2007 11:10:56 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id5sE-0000C4-2q for ietf@ietf.org; Wed, 03 Oct 2007 11:10:56 -0400 X-IronPort-AV: E=Sophos;i="4.21,225,1188802800"; d="scan'208";a="229746784" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 03 Oct 2007 08:10:53 -0700 Received: from 64-142-29-214.dsl.static.sonic.net ([10.21.90.124]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l93DktcP016382; Wed, 3 Oct 2007 06:46:55 -0700 Message-ID: <4703B13E.2080708@cisco.com> Date: Wed, 03 Oct 2007 08:11:58 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Brian E Carpenter References: <4702FA84.1070806@gmail.com> In-Reply-To: <4702FA84.1070806@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=616; t=1191419215; x=1192283215; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20Spammers=20answering=20TMDA=20Queries |Sender:=20 |To:=20Brian=20E=20Carpenter=20; bh=ThofTcPvQP3k3JGn+/kBQVlj3dV5w8Kr0fFdpFAQRO8=; b=PboLtOS0m75Bn45K8oB7z/NL7Ok5sO9ag6E2kcEnRdF6bG2kTcFLguYsY79b2k4M3Aqs3RL8 ZGYsPtz1EAUySsqSZZ+4ktlNoTfLMZJ8grJ2j8VJFyLo5EGDT9k8nTUr; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ietf@ietf.org Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Brian E Carpenter wrote: > Speaking personally, I think annual reconfirmation is quite reasonable. > The message sent to the user should make it clear that it is an > annual process. Except... the annual confirmation is probably going to get accidentally deleted by a lot of people because they think it's the monthly notice. If this is a real problem, wouldn't it be better to take it up with the mailman folks since I'd expect that it's not just ietf? I've been working with them on dkim related stuff and they are quite reasonable folks. Maybe they have some ideas on this front. Mike _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 15:22:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id9SX-0001Ys-0v; Wed, 03 Oct 2007 15:00:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id9SU-0001Pi-Ek; Wed, 03 Oct 2007 15:00:34 -0400 Received: from diotima.switch.ch ([130.59.4.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id9ST-0003cN-W7; Wed, 03 Oct 2007 15:00:34 -0400 Received: (from leinen@localhost) by diotima.switch.ch (8.14.1+Sun/8.14.1) id l93J0O9t024890; Wed, 3 Oct 2007 21:00:25 +0200 (CEST) X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon.leinen@switch.ch using -f From: Simon Leinen To: Danny McPherson In-Reply-To: (Danny McPherson's message of "Tue, 2 Oct 2007 01:28:20 -0600") References: <200710020255.l922tadC023029@drugs.dv.isc.org> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z, @ttmwYVO7l`6OXXYR` Date: Wed, 03 Oct 2007 21:00:24 +0200 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Mark Andrews , dnsop-chairs@ietf.org, ietf@ietf.org, secdir@mit.edu, fneves@registro.br, iesg@ietf.org, Jeffrey Hutzelman , joao_damas@isc.org Subject: Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Danny McPherson writes: > Really? How many ISPs are you aware of that have > *decommissioned* every piece of routing gear in their > network in the past 7 years? I think we're an ISP (AS559), and we don't have any equipment that would be unable to filter against spoofed source addresses. In fact I think that even seven years ago all our equipment could do this. Yes, I know about certain "Engine-N" generations of certain linecards for certain "high-end" routers, but my sympathy to those ISPs who still use them is limited. (Especially with those ISPs that keep a few in their network just as an excuse for not deploying BCP39 anywhere :-) -- Simon. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 18:37:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdCbI-0003bg-7A; Wed, 03 Oct 2007 18:21:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdCNL-0006Jf-Ms for ietf@ietf.org; Wed, 03 Oct 2007 18:07:27 -0400 Received: from robin.verisign.com ([65.205.251.75]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdCFJ-0008Qv-C1 for ietf@ietf.org; Wed, 03 Oct 2007 17:59:09 -0400 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l93Luaka014023; Wed, 3 Oct 2007 14:56:36 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 14:59:03 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 3 Oct 2007 14:59:03 -0700 Message-ID: <2788466ED3E31C418E9ACC5C316615570462C0@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Spammers answering TMDA Queries Thread-Index: AcgF0WC9Ig9dNPQ7Qq+3p/4f0SPZvgANztVx From: "Hallam-Baker, Phillip" To: "Michael Thomas" , "Brian E Carpenter" X-OriginalArrivalTime: 03 Oct 2007 21:59:03.0635 (UTC) FILETIME=[9C919230:01C80608] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: ietf@ietf.org Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0907288261==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============0907288261== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80608.9C75DB90" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80608.9C75DB90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't see a problem if we eat our own dog food. The use of tdma type tech for mailing list subscriptions has been = considered best practice for over a decade. Personal use is nasty, = brutish and hopefully short. Allowing unsubscribed persons to post after a tdma authentication is a = courtesy, there is no obligation to extend it in the first place. Pooling the tdma responses across multiple ietf mailing lists is a = further courtesy. There is more we can do here but no more that we should feel obliged to = do - ecept for the fact that we are a standards organization and should = eat the dog food. In particular, sign the messages with dkim and deploy spf. Sent from my GoodLink Wireless Handheld (www.good.com) -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Wednesday, October 03, 2007 08:23 AM Pacific Standard Time To: Brian E Carpenter Cc: ietf@ietf.org Subject: Re: Spammers answering TMDA Queries Brian E Carpenter wrote: > Speaking personally, I think annual reconfirmation is quite = reasonable. > The message sent to the user should make it clear that it is an > annual process. Except... the annual confirmation is probably going to get accidentally deleted by a lot of people because they think it's the monthly notice. If this is a real problem, wouldn't it be better to take it up with the=20 mailman folks since I'd expect that it's not just ietf? I've been working with=20 them on dkim related stuff and they are quite reasonable folks. Maybe they have = some ideas on this front. Mike _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ------_=_NextPart_001_01C80608.9C75DB90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: Spammers answering TMDA Queries

I don't see a problem if we eat our own dog food.

The use of tdma type tech for mailing list subscriptions has been = considered best practice for over a decade. Personal use is nasty, = brutish and hopefully short.

Allowing unsubscribed persons to post after a tdma authentication is a = courtesy, there is no obligation to extend it in the first place.

Pooling the tdma responses across multiple ietf mailing lists is a = further courtesy.


There is more we can do here but no more that we should feel obliged to = do - ecept for the fact that we are a standards organization and should = eat the dog food.

In particular, sign the messages with dkim and deploy spf.



Sent from my GoodLink Wireless Handheld (www.good.com)

 -----Original Message-----
From:   Michael Thomas [mailto:mat@cisco.com]
Sent:   Wednesday, October 03, 2007 08:23 AM Pacific Standard = Time
To:     Brian E Carpenter
Cc:     ietf@ietf.org
Subject:        Re: Spammers = answering TMDA Queries

Brian E Carpenter wrote:
> Speaking personally, I think annual reconfirmation is quite = reasonable.
> The message sent to the user should make it clear that it is an
> annual process.

Except... the annual confirmation is probably going to get = accidentally
deleted by a lot of people because they think it's the monthly = notice.

If this is a real problem, wouldn't it be better to take it up with = the
mailman
folks since I'd expect that it's not just ietf? I've been working = with
them on
dkim related stuff and they are quite reasonable folks. Maybe they have = some
ideas on this front.

       Mike

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.or= g/mailman/listinfo/ietf

------_=_NextPart_001_01C80608.9C75DB90-- --===============0907288261== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0907288261==-- From ietf-bounces@ietf.org Wed Oct 03 19:12:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdDE9-0004JZ-QF; Wed, 03 Oct 2007 19:02:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdDE8-0004E1-1D for ietf@ietf.org; Wed, 03 Oct 2007 19:02:00 -0400 Received: from nz-out-0506.google.com ([64.233.162.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdDDt-0005tZ-SU for ietf@ietf.org; Wed, 03 Oct 2007 19:01:51 -0400 Received: by nz-out-0506.google.com with SMTP id n1so3260517nzf for ; Wed, 03 Oct 2007 16:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=skPkHPd0e3fOaNlU5r5fuCc+RApdS26u9IFR0n6Fl5Y=; b=fQV9f0tMKWpcCEy3spLFqmV7PamPhpfDM3KfanohvOebTzB52WTc3kG+xSTi0JN8VnUI/evvSv8WEZUPXNhNPvHFo9593rMXK+mjfTKNm4KNU3/Sex/4B8r5y0866poWEEMD48o6pAuPvLQji7BGl5lWoaIJsJgjJER7UEVVPTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZyZ2Fwqcv3iCakZdn9GFoagTdCTi000x4WBmo4vVcUn88jBlm49ToiUNWSyo12ksP+MGY7nJGK0qLPCRLWBjikyRvjWegaE4Uv8kkKKLPUTCfgVaRoJrXNZe0t/yzITCw7DTWFk+rixMfmk+aJdNKCBp9pGuibBNoKGee6FqZjY= Received: by 10.115.59.4 with SMTP id m4mr4636649wak.1191452476618; Wed, 03 Oct 2007 16:01:16 -0700 (PDT) Received: by 10.35.96.14 with HTTP; Wed, 3 Oct 2007 16:01:16 -0700 (PDT) Message-ID: Date: Wed, 3 Oct 2007 16:01:16 -0700 From: "Clint Chaplin" To: ietf@ietf.org In-Reply-To: <2788466ED3E31C418E9ACC5C316615570462C0@mou1wnexmb09.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2788466ED3E31C418E9ACC5C316615570462C0@mou1wnexmb09.vcorp.ad.vrsn.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I believe the term is "tmda", not "tdma". TDMA is a type of cell phone technology. On 10/3/07, Hallam-Baker, Phillip wrote: > > > > I don't see a problem if we eat our own dog food. > > The use of tdma type tech for mailing list subscriptions has been > considered best practice for over a decade. Personal use is nasty, brutish > and hopefully short. > > Allowing unsubscribed persons to post after a tdma authentication is a > courtesy, there is no obligation to extend it in the first place. > > Pooling the tdma responses across multiple ietf mailing lists is a further > courtesy. > > > There is more we can do here but no more that we should feel obliged to do > - ecept for the fact that we are a standards organization and should eat the > dog food. > > In particular, sign the messages with dkim and deploy spf. > > > > Sent from my GoodLink Wireless Handheld (www.good.com) > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, October 03, 2007 08:23 AM Pacific Standard Time > To: Brian E Carpenter > Cc: ietf@ietf.org > Subject: Re: Spammers answering TMDA Queries > > Brian E Carpenter wrote: > > Speaking personally, I think annual reconfirmation is quite reasonable. > > The message sent to the user should make it clear that it is an > > annual process. > > Except... the annual confirmation is probably going to get accidentally > deleted by a lot of people because they think it's the monthly notice. > > If this is a real problem, wouldn't it be better to take it up with the > mailman > folks since I'd expect that it's not just ietf? I've been working with > them on > dkim related stuff and they are quite reasonable folks. Maybe they have > some > ideas on this front. > > Mike > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > -- Clint (JOATMON) Chaplin Principal Engineer Corporate Standardization (US) SISA _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 20:30:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdEPL-0004tx-08; Wed, 03 Oct 2007 20:17:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdEPI-0004pg-T9 for ietf@ietf.org; Wed, 03 Oct 2007 20:17:36 -0400 Received: from adsl-65-67-187-82.dsl.rcsntx.swbell.net ([65.67.187.82] helo=defiant.dfw.nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdEPA-0003NX-5A for ietf@ietf.org; Wed, 03 Oct 2007 20:17:28 -0400 Received: from ssprunkxp (localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.13.8/8.13.8/Debian-3) with SMTP id l940HL8c022486; Wed, 3 Oct 2007 19:17:24 -0500 Message-ID: <07b601c8061b$f6c7ec00$433816ac@atlanta.polycom.com> From: "Stephen Sprunk" To: "John Day" References: <01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com><4697DC68.9060808@gmx.net> <03f001c804e0$92860060$6a01a8c0@DRTVnet1><47024223.7000508@cs.utk.edu><20071002133200.GI14394@login.ecs.soton.ac.uk><4702AC72.8070907@gmail.com> Date: Wed, 3 Oct 2007 19:00:33 -0500 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Virus-Scanned: ClamAV 0.91.1/4461/Wed Oct 3 03:50:48 2007 on defiant.dfw.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ietf@ietf.org Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Thus spake "John Day" > If IANA had any resolve there are at least 25 -30 Class A blocks > that should be reclaimed and are not or should not be part of the > public Internet address space. AFAIK, IANA does not have any reclamation procedures, nor have any every been assumed to exist. In any event, the legacy assignments were transferred to their respective RIRs during the ERX process, so it's the RIRs' problem now. I don't know what has been going on in the other RIRs, but in ARIN it's been (heatedly) discussed many times what to do with legacy assignments. Counsel recently made a statement that it doesn't appear that ARIN has any legal obligation to maintain registry services for legacy assignments, though it does have a moral one since that was a condition of ARIN's creation. Counsel also stated, however, it is unclear that ARIN could assign those same numbers to someone else later. There's quite a bit of history there, including the possibility that assignments made during the ARPAnet days (particularly to universities and defense contractors) were "Government Furnished Equipment" and thus only the government can take them back. There's a counter-theory that numbers cannot be property at all and ARIN can do whatever it wants. Nobody's really sure, least of all the lawyers who'd inevitably be arguing the issue in court when one (or more likely all) of those /8 holders sued ARIN for trying to reclaim them. It doesn't matter who's right in the end; ARIN would be bankrupted just trying to defend itself against several dozen Fortune 100 companies' legal departments... We're working on poFrom ietf-bounces@ietf.org Wed Oct 03 20:30:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdEPL-0004tx-08; Wed, 03 Oct 2007 20:17:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdEPI-0004pg-T9 for ietf@ietf.org; Wed, 03 Oct 2007 20:17:36 -0400 Received: from adsl-65-67-187-82.dsl.rcsntx.swbell.net ([65.67.187.82] helo=defiant.dfw.nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdEPA-0003NX-5A for ietf@ietf.org; Wed, 03 Oct 2007 20:17:28 -0400 Received: from ssprunkxp (localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.13.8/8.13.8/Debian-3) with SMTP id l940HL8c022486; Wed, 3 Oct 2007 19:17:24 -0500 Message-ID: <07b601c8061b$f6c7ec00$433816ac@atlanta.polycom.com> From: "Stephen Sprunk" To: "John Day" References: <01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com><4697DC68.9060808@gmx.net> <03f001c804e0$92860060$6a01a8c0@DRTVnet1><47024223.7000508@cs.utk.edu><20071002133200.GI14394@login.ecs.soton.ac.uk><4702AC72.8070907@gmail.com> Date: Wed, 3 Oct 2007 19:00:33 -0500 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Virus-Scanned: ClamAV 0.91.1/4461/Wed Oct 3 03:50:48 2007 on defiant.dfw.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ietf@ietf.org Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Thus spake "John Day" > If IANA had any resolve there are at least 25 -30 Class A blocks > that should be reclaimed and are not or should not be part of the > public Internet address space. AFAIK, IANA does not have any reclamation procedures, nor have any every been assumed to exist. In any event, the legacy assignments were transferred to their respective RIRs during the ERX process, so it's the RIRs' problem now. I don't know what has been going on in the other RIRs, but in ARIN it's been (heatedly) discussed many times what to do with legacy assignments. Counsel recently made a statement that it doesn't appear that ARIN has any legal obligation to maintain registry services for legacy assignments, though it does have a moral one since that was a condition of ARIN's creation. Counsel also stated, however, it is unclear that ARIN could assign those same numbers to someone else later. There's quite a bit of history there, including the possibility that assignments made during the ARPAnet days (particularly to universities and defense contractors) were "Government Furnished Equipment" and thus only the government can take them back. There's a counter-theory that numbers cannot be property at all and ARIN can do whatever it wants. Nobody's really sure, least of all the lawyers who'd inevitably be arguing the issue in court when one (or more likely all) of those /8 holders sued ARIN for trying to reclaim them. It doesn't matter who's right in the end; ARIN would be bankrupted just trying to defend itself against several dozen Fortune 100 companies' legal departments... We're working on policy proposals to address the issue the best we can, though, and if you wish to contribute please subscribe to PPML (and read the archives to get up to speed). S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 20:30:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdEK8-0005lO-8Y; Wed, 03 Oct 2007 20:12:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdEK7-0005hP-1L for ietf@ietf.org; Wed, 03 Oct 2007 20:12:15 -0400 Received: from harry.mail-abuse.org ([168.61.5.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdEK3-0003HD-JS for ietf@ietf.org; Wed, 03 Oct 2007 20:12:11 -0400 Received: from [10.2.164.149] (SJC-Office-NAT-218.Mail-Abuse.ORG [168.61.10.218]) by harry.mail-abuse.org (Postfix) with ESMTP id B9F2141442; Wed, 3 Oct 2007 17:12:10 -0700 (PDT) In-Reply-To: <2788466ED3E31C418E9ACC5C316615570462C0@mou1wnexmb09.vcorp.ad.vrsn.com> References: <2788466ED3E31C418E9ACC5C316615570462C0@mou1wnexmb09.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0FAFD2D5-F0A3-463D-860A-CF2509CF7E7C@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Date: Wed, 3 Oct 2007 17:11:58 -0700 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: IETF discussion list Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 3, 2007, at 2:59 PM, Hallam-Baker, Phillip wrote: > There is more we can do here but no more that we should feel > obliged to do - except for the fact that we are a standards > organization and should eat the dog food. > > In particular, sign the messages with dkim and deploy spf. Few problems should be caused by DKIM, although it might be difficult to claim DKIM solves a particular problem affecting IETF mailing lists. The same is not true for SPF. SPF is experimental, can be problematic, and is very likely unsafe for use with DNS. SPF carries suitable warnings indicating it may cause problems. SPF may interfere with the delivery of forwarded messages. SPF might be used in conjunction with Sender-ID. Suggested solutions for dealing with Sender-ID requires yet another version of SPF be published. Use of which might fall under: http://www.microsoft.com/downloads/results.aspx? pocId=&freetext=SenderID_License-Agreement.pdf&DisplayLang=en Possible application of Sender-ID will cause IETF lists to break once SPF is published. The purported use of SPF for curtailing forged DSNs requires policy settings which then create new problems. When desired, names rather than address lists should be used to register an email path. A name path approach avoids the dangerous DNS transactional issues. Rather than relying upon unscalable SPF address lists, instead an extension might be applied to DKIM. The DKIM extension could offer a means to prevent DSNs from being dropped when Mail From domains differ. http://www1.tools.ietf.org/wg/dkim/draft-otis-dkim-tpa-ssp-01.txt -Doug ___licy proposals to address the issue the best we can, though, and if you wish to contribute please subscribe to PPML (and read the archives to get up to speed). S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 20:30:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdEK8-0005lO-8Y; Wed, 03 Oct 2007 20:12:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdEK7-0005hP-1L for ietf@ietf.org; Wed, 03 Oct 2007 20:12:15 -0400 Received: from harry.mail-abuse.org ([168.61.5.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdEK3-0003HD-JS for ietf@ietf.org; Wed, 03 Oct 2007 20:12:11 -0400 Received: from [10.2.164.149] (SJC-Office-NAT-218.Mail-Abuse.ORG [168.61.10.218]) by harry.mail-abuse.org (Postfix) with ESMTP id B9F2141442; Wed, 3 Oct 2007 17:12:10 -0700 (PDT) In-Reply-To: <2788466ED3E31C418E9ACC5C316615570462C0@mou1wnexmb09.vcorp.ad.vrsn.com> References: <2788466ED3E31C418E9ACC5C316615570462C0@mou1wnexmb09.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0FAFD2D5-F0A3-463D-860A-CF2509CF7E7C@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Date: Wed, 3 Oct 2007 17:11:58 -0700 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: IETF discussion list Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 3, 2007, at 2:59 PM, Hallam-Baker, Phillip wrote: > There is more we can do here but no more that we should feel > obliged to do - except for the fact that we are a standards > organization and should eat the dog food. > > In particular, sign the messages with dkim and deploy spf. Few problems should be caused by DKIM, although it might be difficult to claim DKIM solves a particular problem affecting IETF mailing lists. The same is not true for SPF. SPF is experimental, can be problematic, and is very likely unsafe for use with DNS. SPF carries suitable warnings indicating it may cause problems. SPF may interfere with the delivery of forwarded messages. SPF might be used in conjunction with Sender-ID. Suggested solutions for dealing with Sender-ID requires yet another version of SPF be published. Use of which might fall under: http://www.microsoft.com/downloads/results.aspx? pocId=&freetext=SenderID_License-Agreement.pdf&DisplayLang=en Possible application of Sender-ID will cause IETF lists to break once SPF is published. The purported use of SPF for curtailing forged DSNs requires policy settings which then create new problems. When desired, names rather than address lists should be used to register an email path. A name path approach avoids the dangerous DNS transactional issues. Rather than relying upon unscalable SPF address lists, instead an extension might be applied to DKIM. The DKIM extension could offer a means to prevent DSNs from being dropped when Mail From domains differ. http://www1.tools.ietf.org/wg/dkim/draft-otis-dkim-tpa-ssp-01.txt -Doug _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ____________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 03 21:08:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdF1G-0003wc-C5; Wed, 03 Oct 2007 20:56:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdF1E-0003sd-54 for ietf@ietf.org; Wed, 03 Oct 2007 20:56:48 -0400 Received: from gal.iecc.com ([208.31.42.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdF18-0004HG-BG for ietf@ietf.org; Wed, 03 Oct 2007 20:56:42 -0400 Received: (qmail 32989 invoked from network); 4 Oct 2007 00:56:40 -0000 Received: from simone.iecc.com (208.31.42.47) by mail1.iecc.com with QMQP; 4 Oct 2007 00:56:40 -0000 Date: 4 Oct 2007 00:56:40 -0000 Message-ID: <20071004005640.75383.qmail@simone.iecc.com> From: John Levine To: ietf@ietf.org In-Reply-To: Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: harald@alvestrand.no Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>> 1025 mail addresses have "confirmed" their address. I would bet that >>> at least 20% of the confirmed are spam addresses (or autoconfirmed >>> addresses) >> >> Thoughts? Now that I think about it some more, regardless of the merits of TMDA or lack thereof, if those addresses aren't sending annoying mail, what's the problem? It's very unlikely that anyone is trying to scrape addresses from the list mail as it goes by. The volume is (by spammer standards) very small, and the addresses they'd get aren't exactly hot prospects for fake drugs and stock tips. Yes, a lot of them are probably random bystanders who auto-acked their way in, but I'd leave well enough alone. R's, John _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 02:58:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdKJD-0007yw-VA; Thu, 04 Oct 2007 02:35:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdKJB-0007s9-CP; Thu, 04 Oct 2007 02:35:41 -0400 Received: from netcore.fi ([193.94.160.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdKJA-0006ed-Qc; Thu, 04 Oct 2007 02:35:41 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l946ZRUg001041; Thu, 4 Oct 2007 09:35:27 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l946ZRUZ001038; Thu, 4 Oct 2007 09:35:27 +0300 Date: Thu, 4 Oct 2007 09:35:27 +0300 (EEST) From: Pekka Savola To: ken carlberg In-Reply-To: <67602DA7-6B73-422C-95D3-7D216E0F388F@g11.org.uk> Message-ID: References: <67602DA7-6B73-422C-95D3-7D216E0F388F@g11.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4461/Wed Oct 3 11:50:48 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.5 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00, TW_SV, TW_VW autolearn=no version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ietf@ietf.org, tsvwg@ietf.org Subject: Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Tue, 2 Oct 2007, ken carlberg wrote: > On Oct 2, 2007, at 10:11 AM, Pekka Savola wrote: >> It is not clear that consensus in the IETF and deployments is strong enough >> to approve/recommend any specific treatment for standards track DSCP >> values. > > could you expand on this observation? I don't recall when was the last (Diffserv-based) QoS talk at NANOG or similar operator-rich meeting. (Sure, there is the tutorial, but it doesn't count.) Seems like a potential indication that most typical ISPs aren't working on or interested in this, this stuff is so trivial, or that coordination is not necessary. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 07:24:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdOVO-0000qg-9I; Thu, 04 Oct 2007 07:04:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdOVL-0000pz-SK; Thu, 04 Oct 2007 07:04:31 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdOVL-0000Uk-IQ; Thu, 04 Oct 2007 07:04:31 -0400 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 8513721; Thu, 04 Oct 2007 07:04:29 -0400 In-Reply-To: References: <67602DA7-6B73-422C-95D3-7D216E0F388F@g11.org.uk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Eubanks Date: Thu, 4 Oct 2007 07:04:17 -0400 To: Pekka Savola X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ietf@ietf.org, tsvwg@ietf.org Subject: Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 4, 2007, at 2:35 AM, Pekka Savola wrote: > On Tue, 2 Oct 2007, ken carlberg wrote: >> On Oct 2, 2007, at 10:11 AM, Pekka Savola wrote: >>> It is not clear that consensus in the IETF and deployments is >>> strong enough to approve/recommend any specific treatment for >>> standards track DSCP values. >> >> could you expand on this observation? > > I don't recall when was the last (Diffserv-based) QoS talk at NANOG > or similar operator-rich meeting. (Sure, there is the tutorial, > but it doesn't count.) > > Seems like a potential indication that most typical ISPs aren't > working on or interested in this, this stuff is so trivial, or that > coordination is not necessary. Dear Pekka; FWIW, in the video conferencing world, DiffServe QOS is ubiquitous. (This is pretty frequently over internetworks, but not generally over the Internet.) The same is true for IPTV, but of course this is not yet internetwork much. I would rate it as too simple and too deployed for NANOG. Regards Marshall > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 07:44:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdOzc-00070J-IY; Thu, 04 Oct 2007 07:35:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdOzb-0006ur-3D for ietf@ietf.org; Thu, 04 Oct 2007 07:35:47 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdOzU-0003pH-TU for ietf@ietf.org; Thu, 04 Oct 2007 07:35:47 -0400 X-IronPort-AV: E=Sophos;i="4.21,229,1188802800"; d="scan'208";a="179076701" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 04 Oct 2007 04:35:25 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l94BZOxi018635; Thu, 4 Oct 2007 04:35:24 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l94BZOPC012911; Thu, 4 Oct 2007 11:35:24 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 04:35:23 -0700 Received: from [10.255.252.180] ([10.21.86.19]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 04:35:23 -0700 In-Reply-To: <2788466ED3E31C418E9ACC5C316615570462BD@mou1wnexmb09.vcorp.ad.vrsn.com> References: <2788466ED3E31C418E9ACC5C316615570462BD@mou1wnexmb09.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Date: Thu, 4 Oct 2007 07:35:19 -0400 To: "Hallam-Baker, Phillip" X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 04 Oct 2007 11:35:23.0384 (UTC) FILETIME=[A6C62780:01C8067A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=530; t=1191497724; x=1192361724; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Spammers=20answering=20TMDA=20Queries |Sender:=20; bh=Txuoh0wk0Kgc7nQMYTzeF3s+L0BKnYK6TcqBoPtC+bA=; b=omRzvUYLJUjvRBcOMY8p7988QZ/QPPBHgT3V94dXFz8Jm1t+X52NY1k5OqVFPIiR2A2D+u4M +BEaC51JgXXy7ql0h4sT+gn0/fROpnxfEDzp59lCBUQWPbqdynfkiPhuE8KmqYQx0ExYNZ/C3U 9FCKKItrEI5ll+jVxys2bf7eg=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ietf@ietf.org Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 2, 2007, at 9:02 PM, Hallam-Baker, Phillip wrote: > Should also consider if spf or dkim checks could cull the paypal spam. how many of us are now sending with DKIM or Microsoft's scheme? It might be worthwhile making ietf.org apply a policy to senders that would recognize normal participants and disallow known spam domains. -----BEGIN PGP SIGNATURE----- iD8DBQFHBM/3bjEdbHIsm0MRAmGJAJwPDlxxctrZg7bgk6zPM0geX0lxlQCgmKBf fwJfuKV3ObxwPOK/m6WhXbg= =QI1E -----END PGP SIGNATURE----- _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 11:26:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdSHT-0007ZY-3h; Thu, 04 Oct 2007 11:06:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdSHR-0007LK-Fj for ietf@ietf.org; Thu, 04 Oct 2007 11:06:25 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdSHF-00029T-RD for ietf@ietf.org; Thu, 04 Oct 2007 11:06:14 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l94Ed8xq095978; Thu, 4 Oct 2007 07:39:15 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Thu, 04 Oct 2007 08:06:01 -0700 X-PGP-Universal: processed; by terminus.local on Thu, 04 Oct 2007 08:06:01 -0700 In-Reply-To: References: <01d901c7c56c$b1d33fe0$373816ac@atlanta.polycom.com> <4697DC68.9060808@gmx.net> <03f001c804e0$92860060$6a01a8c0@DRTVnet1> <47024223.7000508@cs.utk.edu> <20071002133200.GI14394@login.ecs.soton.ac.uk> <4702AC72.8070907@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Date: Thu, 4 Oct 2007 08:05:53 -0700 To: John Day X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: IETF-Discussion Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org John, Which would those be? Thanks, -drc On Oct 3, 2007, at 6:00 AM, John Day wrote: > If IANA had any resolve there are at least 25 -30 Class A blocks > that should be reclaimed and are not or should not be part of the > public Internet address space. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 11:51:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdSrg-000443-LT; Thu, 04 Oct 2007 11:43:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdSrf-000418-2W for ietf@ietf.org; Thu, 04 Oct 2007 11:43:51 -0400 Received: from gal.iecc.com ([208.31.42.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdSrd-0003pW-Dd for ietf@ietf.org; Thu, 04 Oct 2007 11:43:50 -0400 Received: (qmail 46053 invoked from network); 4 Oct 2007 15:43:48 -0000 Received: from simone.iecc.com (208.31.42.47) by mail1.iecc.com with QMQP; 4 Oct 2007 15:43:48 -0000 Date: 4 Oct 2007 15:43:48 -0000 Message-ID: <20071004154348.79811.qmail@simone.iecc.com> From: John Levine To: ietf@ietf.org In-Reply-To: Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: fred@cisco.com Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >how many of us are now sending with DKIM or Microsoft's scheme? It >might be worthwhile making ietf.org apply a policy to senders that >would recognize normal participants and disallow known spam domains. Um, spammers haven't sent mail from "known spam domains" since about 2001. These days spam has 100% forged return addresses. DKIM and Sender-ID help tell forgeries from legit mail, but I haven't heard anyone say that forged mail purporting to be from list participants is an issue. Unless I am missing something, the amount of spam leaking into IETF lists is currently about zero. What problem are we trying to solve? R's, John _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 12:08:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdT8A-0003au-Qu; Thu, 04 Oct 2007 12:00:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdT86-00029m-2W for ietf@ietf.org; Thu, 04 Oct 2007 12:00:50 -0400 Received: from robin.verisign.com ([65.205.251.75]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdT80-0004YY-JT for ietf@ietf.org; Thu, 04 Oct 2007 12:00:44 -0400 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l94Fv7jV011107; Thu, 4 Oct 2007 08:57:07 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 08:59:36 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 4 Oct 2007 08:56:18 -0700 Message-ID: <2788466ED3E31C418E9ACC5C316615570534E4@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <20071004154348.79811.qmail@simone.iecc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Spammers answering TMDA Queries Thread-Index: AcgGnrhgOm75iIX1QhSTkp9OZVSYXAAADOzQ From: "Hallam-Baker, Phillip" To: "John Levine" , X-OriginalArrivalTime: 04 Oct 2007 15:59:36.0687 (UTC) FILETIME=[901437F0:01C8069F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: fred@cisco.com Subject: RE: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org The problem is the amount of time it is taking to moderate mail sent by = non subscribers. So far the score for KEYPROV has been 98% spam. But there were a couple = of messages that were very important that got trapped.=20 > -----Original Message----- > From: John Levine [mailto:johnl@iecc.com]=20 > Sent: Thursday, October 04, 2007 11:44 AM > To: ietf@ietf.org > Cc: fred@cisco.com > Subject: Re: Spammers answering TMDA Queries >=20 > >how many of us are now sending with DKIM or Microsoft's scheme? It=20 > >might be worthwhile making ietf.org apply a policy to senders that=20 > >would recognize normal participants and disallow known spam domains. >=20 > Um, spammers haven't sent mail from "known spam domains"=20 > since about 2001. These days spam has 100% forged return=20 > addresses. DKIM and Sender-ID help tell forgeries from legit=20 > mail, but I haven't heard anyone say that forged mail=20 > purporting to be from list participants is an issue. >=20 > Unless I am missing something, the amount of spam leaking=20 > into IETF lists is currently about zero. What problem are we=20 > trying to solve? >=20 > R's, > John >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 12:53:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdTiY-0007It-7o; Thu, 04 Oct 2007 12:38:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdTiW-0007I6-O1; Thu, 04 Oct 2007 12:38:28 -0400 Received: from alnrmhc13.comcast.net ([204.127.225.93]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdTiW-0005mz-Dp; Thu, 04 Oct 2007 12:38:28 -0400 Received: from [192.168.1.2] (c-69-250-218-72.hsd1.md.comcast.net[69.250.218.72]) by comcast.net (alnrmhc13) with SMTP id <20071004163826b13000e8oie>; Thu, 4 Oct 2007 16:38:27 +0000 In-Reply-To: References: <67602DA7-6B73-422C-95D3-7D216E0F388F@g11.org.uk> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: ken carlberg Date: Thu, 4 Oct 2007 12:38:24 -0400 To: Pekka Savola X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ietf@ietf.org, tsvwg@ietf.org Subject: Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > I don't recall when was the last (Diffserv-based) QoS talk at NANOG > or similar operator-rich meeting. (Sure, there is the tutorial, > but it doesn't count.) I would be concerned if outside groups spent time arguing "foo" is bad, or if they advocated other positions to the same issue. But I tend to feel quite uncomfortable with litmus tests based on inactivity of other groups/people. My personal view is that advocates of that line of reasoning place a bigger burden on themselves in providing specific in-depth arguments. > Seems like a potential indication that most typical ISPs aren't > working on or interested in this, this stuff is so trivial, or that > coordination is not necessary. i appreciate work that is trivial because its generally simple, easy to accomplish, and leads to fewer interoperability issues. as for ISPs, its fascinating the disparity of how quiet and talkative they are depending on what side of the NDA you are on :-) cheers, -ken _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 13:46:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdUcF-0006rx-S8; Thu, 04 Oct 2007 13:36:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdUcE-0006pO-A4 for ietf@ietf.org; Thu, 04 Oct 2007 13:36:02 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdUc9-0000sE-1Z for ietf@ietf.org; Thu, 04 Oct 2007 13:36:02 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 4 Oct 2007 10:36:07 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv4 to IPv6 transition Thread-Index: AcgFs3RvTfMK2Bn3Qz+etbeEnOFLRgA+RcYg References: From: "Michel Py" To: "IETF Discussion" X-Spam-Score: 1.0 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: RE: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > Ruri Hiromi wrote: > http://www.apple.com/jp/downloads/dashboard/networking_security/ipv420.h tml Each time I see one of these "days remaining before Armaggedon" counters, I can't help but remember what happened on January 1, 2000: nothing. Michel. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 13:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdUk4-0006pj-KU; Thu, 04 Oct 2007 13:44:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdUk3-0006pR-D6 for ietf@ietf.org; Thu, 04 Oct 2007 13:44:07 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdUk3-0007qf-2T for ietf@ietf.org; Thu, 04 Oct 2007 13:44:07 -0400 X-IronPort-AV: E=Sophos;i="4.21,231,1188802800"; d="scan'208";a="531455967" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 04 Oct 2007 10:44:04 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l94Hi4qB014662; Thu, 4 Oct 2007 10:44:04 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l94Hhs14011534; Thu, 4 Oct 2007 17:44:00 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 10:43:58 -0700 Received: from [10.255.252.137] ([10.21.95.221]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 10:43:58 -0700 In-Reply-To: <2788466ED3E31C418E9ACC5C316615570534E4@mou1wnexmb09.vcorp.ad.vrsn.com> References: <2788466ED3E31C418E9ACC5C316615570534E4@mou1wnexmb09.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Date: Thu, 4 Oct 2007 13:43:51 -0400 To: "Hallam-Baker, Phillip" X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 04 Oct 2007 17:43:58.0269 (UTC) FILETIME=[2445CED0:01C806AE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=705; t=1191519844; x=1192383844; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Spammers=20answering=20TMDA=20Queries |Sender:=20; bh=6M9ZHNRzuH8jN1QgWy7lu3OLj+VOttssiJg8SuIfa4c=; b=de1UT65SsH7sLr/bqfHuiWyN5N+ftRez3S2Ozwv2cPvjZOtBS9JzNqaCsHlItl5Y0v1w2Fq5 m0r9FkD5ho8WSENiD6u2RywuBaPzhgQSon8gsa5q/Sca81Basr3m5CcogWmxjMFS6kXK8jBQme F5BT5O8LBGCjMdTEdlxE8IZPc=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ietf@ietf.org Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 4, 2007, at 11:56 AM, Hallam-Baker, Phillip wrote: > The problem is the amount of time it is taking to moderate mail > sent by non subscribers. yes. For example, every email from @cisco.com is dkim-signed. The IETF can automagically dump any such email that is not signed, or for which the signature doesn't check out. I know that fred@cisco.com is one of many commonly-spoofed email addresses - I can tell that from the backscatter I find in my junk box. For how many of us is that true? -----BEGIN PGP SIGNATURE----- iD8DBQFHBSZXbjEdbHIsm0MRAt9UAJ9xVCpDMdC3spmPkmsTFCqZTNWY6ACffR0R lUEQvoA8i0OZXuU4r8TroLs= =0xUE -----END PGP SIGNATURE----- _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 13:56:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdUqj-0007gz-EJ; Thu, 04 Oct 2007 13:51:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdUqh-0007fn-Rr for ietf@ietf.org; Thu, 04 Oct 2007 13:50:59 -0400 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdUqb-0001LC-NR for ietf@ietf.org; Thu, 04 Oct 2007 13:50:59 -0400 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id DAF4DCBCD6; Thu, 4 Oct 2007 13:50:37 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k46DOf0OdIX; Thu, 4 Oct 2007 13:50:35 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by ka.cs.utk.edu (Postfix) with ESMTP id 4A1AECBCEA; Thu, 4 Oct 2007 13:50:27 -0400 (EDT) Message-ID: <470527DE.8010506@cs.utk.edu> Date: Thu, 04 Oct 2007 13:50:22 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Michel Py References: In-Reply-To: X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: IETF Discussion Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > http://www.apple.com/jp/downloads/dashboard/networking_security/ipv420.h > tml > > Each time I see one of these "days remaining before Armaggedon" > counters, I can't help but remember what happened on January 1, 2000: > nothing. > yes, but that's because people heeded the warnings, and prepared. if the same thing happens wrt IPv4 exhaustion, that will be fabulous. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 14:30:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdVJM-0000PI-TF; Thu, 04 Oct 2007 14:20:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdVJL-0000Lh-HX for ietf@ietf.org; Thu, 04 Oct 2007 14:20:35 -0400 Received: from revol2.enst.fr ([2001:660:330f:2::e] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdVJF-0002FT-9u for ietf@ietf.org; Thu, 04 Oct 2007 14:20:35 -0400 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id 5D1EAB8862 for ; Thu, 4 Oct 2007 20:20:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at enst.fr Received: from dhcp164-215.enst.fr (dhcp164-215.enst.fr [137.194.164.215]) by smtp2.enst.fr (Postfix) with ESMTP id 2E205B885D for ; Thu, 4 Oct 2007 20:20:12 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by dhcp164-215.enst.fr (Postfix) with ESMTP id E4723635D87 for ; Thu, 4 Oct 2007 20:20:03 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <470527DE.8010506@cs.utk.edu> References: <470527DE.8010506@cs.utk.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6D69802F-F58D-4149-A827-1ECD927675B3@wave-storm.com> Content-Transfer-Encoding: 7bit From: Artur Hecker Date: Thu, 4 Oct 2007 20:20:02 +0200 To: IETF Discussion X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 1.6 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi On 4 Oct 2007, at 19:50, Keith Moore wrote: > >> http://www.apple.com/jp/downloads/dashboard/networking_security/ >> ipv420.h >> tml >> >> Each time I see one of these "days remaining before Armaggedon" >> counters, I can't help but remember what happened on January 1, 2000: >> nothing. >> > yes, but that's because people heeded the warnings, and prepared. if > the same thing happens wrt IPv4 exhaustion, that will be fabulous. No doubt - that nicely paid off our profession so we should not complain :-) However, that's an intriguing discussion because I almost as often hear quite the contrary argument: indeed, given billions of USD and EUR spent on that issue, one could reasonably argue that the issue was overblown and ask to which degree this statement is true and what would have actually happened without all the pressure. So far, I could not find anything really useful on that (proofs?) but keep on hearing very opposite positions, but it's maybe just me? Does anybody have any established and sustained opinion on that and could provide verifiable if not objective data? How many critical bugs were really found in typical systems? What would have been the real impact? What could have happenned in terms of impact (meaning: it would definitely have happened, not the what-if analysis)? Was the cost higher than the estimated risk? thanks for any pointers artur _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 14:58:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdVgu-0005y4-1o; Thu, 04 Oct 2007 14:44:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdVgs-0005vM-KQ for ietf@ietf.org; Thu, 04 Oct 2007 14:44:54 -0400 Received: from ka.cs.utk.edu ([160.36.56.221]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdVgs-0001K9-85 for ietf@ietf.org; Thu, 04 Oct 2007 14:44:54 -0400 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id DDE43CBCD3; Thu, 4 Oct 2007 14:44:53 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8F9bE4AKz7H; Thu, 4 Oct 2007 14:44:49 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by ka.cs.utk.edu (Postfix) with ESMTP id CF0D3CBCC6; Thu, 4 Oct 2007 14:44:44 -0400 (EDT) Message-ID: <47053498.2000202@cs.utk.edu> Date: Thu, 04 Oct 2007 14:44:40 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Artur Hecker References: <470527DE.8010506@cs.utk.edu> <6D69802F-F58D-4149-A827-1ECD927675B3@wave-storm.com> In-Reply-To: <6D69802F-F58D-4149-A827-1ECD927675B3@wave-storm.com> X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: IETF Discussion Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>> Each time I see one of these "days remaining before Armaggedon" >>> counters, I can't help but remember what happened on January 1, 2000: >>> nothing. >> yes, but that's because people heeded the warnings, and prepared. if >> the same thing happens wrt IPv4 exhaustion, that will be fabulous. > > No doubt - that nicely paid off our profession so we should not > complain :-) > > However, that's an intriguing discussion because I almost as often > hear quite the contrary argument: indeed, given billions of USD and > EUR spent on that issue, one could reasonably argue that the issue was > overblown and ask to which degree this statement is true and what > would have actually happened without all the pressure. > > So far, I could not find anything really useful on that (proofs?) but > keep on hearing very opposite positions, but it's maybe just me? > > Does anybody have any established and sustained opinion on that and > could provide verifiable if not objective data? How many critical bugs > were really found in typical systems? What would have been the real > impact? What could have happenned in terms of impact (meaning: it > would definitely have happened, not the what-if analysis)? Was the > cost higher than the estimated risk? Well, presumably most of that money was spent on detailed analysis rather than on bug fixes. But I haven't heard of any significant effort to collect data on how many bugs were found or what there impact would have been had they not been fixed prior to y2k. And it's not clear how much value there would be in such an effort, because we're not going to run into another y2k like situation for at least 93 more years. (Okay, maybe in 2038 when the number of seconds after the UNIX epoch rolls past a 32-bit number). It would be hard to apply any lessons learned from y2k to the exhaustion of IPv4, because they're similar only in a very superficial way. Keith p.s. also, my impression is that a lot of businesses used the y2k as an excuse to replace old, crufty software with newer software (presumably with newer cruft), which might have produced benefits other than y2k resilience. so a cost-vs-benefit analysis would need to consider this. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 15:34:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWF6-0004xx-Cc; Thu, 04 Oct 2007 15:20:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWF5-0004kp-3H for ietf@ietf.org; Thu, 04 Oct 2007 15:20:15 -0400 Received: from robin.verisign.com ([65.205.251.75]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdWEw-0002qS-KO for ietf@ietf.org; Thu, 04 Oct 2007 15:20:07 -0400 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l94JHSUA020378; Thu, 4 Oct 2007 12:17:28 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 12:19:57 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 4 Oct 2007 12:16:39 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557053529@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Spammers answering TMDA Queries Thread-Index: AcgGrir+RRN6xZ9JTCOmP+fRuc6vyAADGS9Q From: "Hallam-Baker, Phillip" To: "Fred Baker" X-OriginalArrivalTime: 04 Oct 2007 19:19:57.0924 (UTC) FILETIME=[8D4B6A40:01C806BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ietf@ietf.org Subject: RE: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Absolutely, and in fact I see mailing list management as a natural early = adopter for DKIM filtering. The vast bulk of the spam I am moderating off the KEYPROV list is = phishing spam against five particular addresses, all of which implement = DKIM. My workload as a moderator can be cut by 80% by rejecting any = message from those addresses that is not DKIM signed. Mailing lists do not in general subscribe to mailing lists so the normal = arguments against discarding messages for failing DKIM compliance do not = apply.=20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Thursday, October 04, 2007 1:44 PM > To: Hallam-Baker, Phillip > Cc: John Levine; ietf@ietf.org > Subject: Re: Spammers answering TMDA Queries >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 > On Oct 4, 2007, at 11:56 AM, Hallam-Baker, Phillip wrote: >=20 > > The problem is the amount of time it is taking to moderate=20 > mail sent=20 > > by non subscribers. >=20 > yes. For example, every email from @cisco.com is dkim-signed.=20 > The IETF can automagically dump any such email that is not=20 > signed, or for which the signature doesn't check out. I know=20 > that fred@cisco.com is one of many commonly-spoofed email=20 > addresses - I can tell that from the backscatter I find in my=20 > junk box. >=20 > For how many of us is that true? > -----BEGIN PGP SIGNATURE----- >=20 > iD8DBQFHBSZXbjEdbHIsm0MRAt9UAJ9xVCpDMdC3spmPkmsTFCqZTNWY6ACffR0R > lUEQvoA8i0OZXuU4r8TroLs=3D > =3D0xUE > -----END PGP SIGNATURE----- >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 15:38:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWRR-0005UP-VR; Thu, 04 Oct 2007 15:33:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWRP-0005U0-TG for ietf@ietf.org; Thu, 04 Oct 2007 15:32:59 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdWRJ-0004zf-MI for ietf@ietf.org; Thu, 04 Oct 2007 15:32:59 -0400 X-IronPort-AV: E=Sophos;i="4.21,232,1188770400"; d="scan'208";a="154944204" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 04 Oct 2007 21:32:48 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l94JWlgM008732 for ; Thu, 4 Oct 2007 21:32:47 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l94JWlbR003451 for ; Thu, 4 Oct 2007 19:32:47 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 21:32:47 +0200 Received: from [10.1.0.20] ([10.61.67.57]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 21:32:47 +0200 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <46EAE465.8070104@dcrocker.net> References: <46EAE465.8070104@dcrocker.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ralph Droms Date: Thu, 4 Oct 2007 04:52:29 -0400 To: IETF-Discussion X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Oct 2007 19:32:47.0327 (UTC) FILETIME=[57E4FEF0:01C806BD] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15462.001 X-TM-AS-Result: No--17.551000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=556; t=1191526367; x=1192390367; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20Call=20for=20action=20vs.=20lost=20opportunity=20(Was =3A=20Re=3A=20Renumbering) |Sender:=20; bh=rQmHp4K8VhYOdh45XCmsw8HEn0vo6+zAvOr6BOFg8hA=; b=emPo715ETw8EZH1GInRB5JTtI+N+UN/+YxYu96O0PdmiJ2CFbqP6m1cZ+C/eHuB08Vq+yWqG V0YZtashG5/MnnOTFBJgyVJkfLxC/4a8WZ+3zu2pfu/nfLDMGsyRcPSj; Authentication-Results: ams-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -2.1 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Regarding transition: On Sep 14, 2007, at Sep 14, 2007,3:43 PM, Dave Crocker wrote: > > > Unless I've missed something rather basic, in the case of IPv6, > very little > attention was paid to facilitating transition by maximizing > interoperability > with the IPv4 installed base. Dave, I have to agree with you in this regard. We may have achieved neither significant new capabilities because IPv6 ~= IPv6+more_bits, nor ease of transition because transition wasn't thoroughly evaluated early on in the design process... - Ralph _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 15:44:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWXZ-0004vC-Pi; Thu, 04 Oct 2007 15:39:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWXY-0004sE-IP for ietf@ietf.org; Thu, 04 Oct 2007 15:39:20 -0400 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdWXT-0005CW-Bu for ietf@ietf.org; Thu, 04 Oct 2007 15:39:20 -0400 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id CB671103650; Thu, 4 Oct 2007 15:39:00 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uy133eIqZ-8n; Thu, 4 Oct 2007 15:38:56 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id 21904103611; Thu, 4 Oct 2007 15:38:56 -0400 (EDT) Message-ID: <4705414B.5000109@cs.utk.edu> Date: Thu, 04 Oct 2007 15:38:51 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2788466ED3E31C418E9ACC5C31661557053529@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <2788466ED3E31C418E9ACC5C31661557053529@mou1wnexmb09.vcorp.ad.vrsn.com> X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Fred Baker , ietf@ietf.org Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hallam-Baker, Phillip wrote: > Absolutely, and in fact I see mailing list management as a natural early adopter for DKIM filtering. the problem I have with DKIM filtering is that it is only effective for domains that can reasonably insist that all of the mail originated by users at that domain go through that domain's submission servers. this is a corner case, not the general case. sure the spammers will learn to not use DKIM domains, but they'll just move to other domains, and the vast majority of domains won't be able to use DKIM without seriously impairing their users' ability to send mail. of course, some of the large ISPs and MSPs like it that way. frankly I don't think IETF should have backed a proposal that was so unfairly biased toward a particular business model. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 15:44:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWYJ-0005sv-RE; Thu, 04 Oct 2007 15:40:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWYI-0005gJ-7T for ietf@ietf.org; Thu, 04 Oct 2007 15:40:06 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdWY5-0005DL-Va for ietf@ietf.org; Thu, 04 Oct 2007 15:40:00 -0400 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l94JaZ61021190; Thu, 4 Oct 2007 12:36:39 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 20:39:04 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 4 Oct 2007 12:35:47 -0700 Message-ID: <2788466ED3E31C418E9ACC5C3166155705352E@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <470527DE.8010506@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv4 to IPv6 transition Thread-Index: AcgGr8TkMM8zSH0qTOimV+j7hog/1gADQSnA From: "Hallam-Baker, Phillip" To: "Keith Moore" , "Michel Py" X-OriginalArrivalTime: 04 Oct 2007 19:39:04.0997 (UTC) FILETIME=[3900DD50:01C806BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: IETF Discussion Subject: RE: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org In the 1980s I worked on a chemical plant manufacturing chlorine and = CFCs. In the corner of the site there was a plant that had been = constructed but never put into production. The plant had been built to make a CFC substitute product when the Ozone = layer issue had first been raised but never went into production as it = was subsequently proved that the ozone layer fears had been greatly = exagerated and that it would be centuries or more before the significant = depletion would take effect. Today of course we have a massive hole in the ozone layer and the role = of CFCs is beyond serious dispute. More than half the CFCs that are = circulating in the upper atmosphere today were manufactured after we had = the technology to avoid the problem. So yes, Homo Sapiens is entirely capable of turning avoidable disaster = into disaster through inaction. > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu]=20 > Sent: Thursday, October 04, 2007 1:50 PM > To: Michel Py > Cc: IETF Discussion > Subject: Re: IPv4 to IPv6 transition >=20 >=20 > >=20 > http://www.apple.com/jp/downloads/dashboard/networking_security/ipv420 > > .h > > tml > > > > Each time I see one of these "days remaining before Armaggedon" > > counters, I can't help but remember what happened on=20 > January 1, 2000: > > nothing. > > =20 > yes, but that's because people heeded the warnings, and=20 > prepared. if the same thing happens wrt IPv4 exhaustion,=20 > that will be fabulous. >=20 >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 16:10:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWu6-0007Kp-3U; Thu, 04 Oct 2007 16:02:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWu4-0007Ie-6J for ietf@ietf.org; Thu, 04 Oct 2007 16:02:36 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdWu3-0005yS-0c for ietf@ietf.org; Thu, 04 Oct 2007 16:02:36 -0400 X-IronPort-AV: E=Sophos;i="4.21,232,1188802800"; d="scan'208";a="230689986" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 04 Oct 2007 13:02:34 -0700 Received: from 64-142-29-214.dsl.static.sonic.net ([10.21.85.17]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l94IcWBg021834; Thu, 4 Oct 2007 11:38:32 -0700 Message-ID: <4705471D.3060102@cisco.com> Date: Thu, 04 Oct 2007 13:03:41 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Keith Moore References: <2788466ED3E31C418E9ACC5C31661557053529@mou1wnexmb09.vcorp.ad.vrsn.com> <4705414B.5000109@cs.utk.edu> In-Reply-To: <4705414B.5000109@cs.utk.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=959; t=1191523113; x=1192387113; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20Spammers=20answering=20TMDA=20Queries |Sender:=20 |To:=20Keith=20Moore=20; bh=hJ+Hl8xiVXR27G1m5CsaZFNOzEy5K/YwExmMkxIWNMw=; b=lOz01qSrkj7pGLaQDqZ/ZR6H5MlpMCyxt5x/Dl7ef2Zb7niG7BteyOz/fLJAhnflLuOWFtEj PvzliChiQ3r12P5uu0X+jPQgrlNdZLLV22WAtgBxuds/FGATniP8agDN; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Fred Baker , ietf@ietf.org Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Keith Moore wrote: > the problem I have with DKIM filtering is that it is only effective for > domains that can reasonably insist that all of the mail originated by > users at that domain go through that domain's submission servers. this > is a corner case, not the general case. Back in the day, we didn't have any of this VeePeeEn tomfoolery. I could just telnet in and that was that. I'm sure that our IT folks paid dearly in time, equipment, and support to throw up that wall, yet they did it and as far as I can tell we all survived the move. I don't see anything especially different with mail: if you want accountability, you have to do real live work -- part of which is placing restrictions on access. TANSTAAFL. > sure the spammers will learn > to not use DKIM domains, but they'll just move to other domains, This is a feature, not a bug: I don't have to outrun the bear, I just need to outrun you. Mike _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 16:10:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWlx-0001jO-7p; Thu, 04 Oct 2007 15:54:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWlv-0001Ou-6f for ietf@ietf.org; Thu, 04 Oct 2007 15:54:11 -0400 Received: from ns1.qubic.net ([208.185.248.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdWll-0005fD-B4 for ietf@ietf.org; Thu, 04 Oct 2007 15:54:08 -0400 Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.2.Alpha0/8.14.2.Alpha0) with ESMTP id l94JrCJ0024098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Oct 2007 12:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1191527610; x=1191614010; bh=1WfyU6CyRllH+zyRiM3UPXuXUmagSVicIQ+0 F1IN2tk=; h=DomainKey-Signature:Message-Id:X-Mailer:Date:To:From: Subject:In-Reply-To:References:Mime-Version:Content-Type:Cc; b=K48 gdAFoJ6ajslcEPNEuWqe4v7G3Mq3TckUQQ3+mpTgMAoCbZYaSH6yQsPUT8UXSVABy8H rUqTlaDK0vMtkTBJwxk56YVyeqrOcoV5M+XBbSv+tCiWlKB0kFZsjBzw0Rf64TYz2DH Z1sk8NOLbBfgAJ6UA2lpE8p7NYRc6iXxdc= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=sBL5DOnCFDY3sPwXbA1Fpt1ZG9p0JQXcU+li2cGC5qKc8zkoUibKnu7UzNpWMdm/p R4/u0PlNf345KqMEQLbSPJTXMop3slb9bTcqa6OXqQIGE1qcUc26SafcmXepcF9QO3k jl1FsxXhztWPYdRh47C2HHAcgFpRWSoJjHA1In8= Message-Id: <6.2.5.6.2.20071004111028.031d08e0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 04 Oct 2007 12:53:01 -0700 To: ietf@ietf.org From: SM In-Reply-To: References: <2788466ED3E31C418E9ACC5C316615570534E4@mou1wnexmb09.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 10:43 04-10-2007, Fred Baker wrote: >yes. For example, every email from @cisco.com is dkim-signed. The >IETF can automagically dump any such email that is not signed, or for >which the signature doesn't check out. I know that fred@cisco.com is >one of many commonly-spoofed email addresses - I can tell that from >the backscatter I find in my junk box. Cisco.com would have to publish a SSP (draft-ietf-dkim-ssp) indicating that it signs all mail. Alternatively, one might apply heuristics to increase the spam probability if an email from @cisco.com is not dkim-signed. Spam can pass SPF, Sender-ID and are even DK and DKIM signed nowadays. One can't blame spammers for not being early adopters. :-) TMDA may cause backscatter. That could be avoided by rejecting email which is most likely spam at the MTA level and have the rest held for manual review. That should decrease the amount (98%) of mail requiring manual review. With such a system, you still need an alternate contact channel which the sender can use to get his/her message though if the it is rejected. Sometimes it's easier to alleviate the problem instead of solving it. draft-ietf-sipping-spam-05 ( http://www.ietf.org/internet-drafts/draft-ietf-sipping-spam-05.txt ) provides an interesting insight. Regards, -sm _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 16:14:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWzi-0001Mj-GD; Thu, 04 Oct 2007 16:08:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWzg-0001M2-Uf for ietf@ietf.org; Thu, 04 Oct 2007 16:08:24 -0400 Received: from diotima.switch.ch ([2001:620:0:4:203:baff:fe4c:d751]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdWzf-0006Aj-MQ for ietf@ietf.org; Thu, 04 Oct 2007 16:08:24 -0400 Received: (from leinen@localhost) by diotima.switch.ch (8.14.1+Sun/8.14.1) id l94K83pS000957; Thu, 4 Oct 2007 22:08:03 +0200 (CEST) X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon.leinen@switch.ch using -f From: Simon Leinen To: Fred Baker In-Reply-To: (Fred Baker's message of "Thu, 4 Oct 2007 13:43:51 -0400") References: <2788466ED3E31C418E9ACC5C316615570534E4@mou1wnexmb09.vcorp.ad.vrsn.com> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z, @ttmwYVO7l`6OXXYR` Date: Thu, 04 Oct 2007 22:08:02 +0200 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ietf@ietf.org Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Fred Baker writes: > On Oct 4, 2007, at 11:56 AM, Hallam-Baker, Phillip wrote: >> The problem is the amount of time it is taking to moderate mail >> sent by non subscribers. > yes. For example, every email from @cisco.com is dkim-signed. The > IETF can automagically dump any such email that is not signed, or for > which the signature doesn't check out. I know that fred@cisco.com is > one of many commonly-spoofed email addresses - I can tell that from > the backscatter I find in my junk box. > For how many of us is that true? FWIW, about 12% (14 out of 114) of the active non-spam senders to this list had DKIM-Signature headers in the past two weeks. I don't know enough about DKIM to tell whether the same assumption holds for the non-cisco.com sender domains (mostly gmail.com plus a few smaller ones): that mail from them can be considered spoofed if the DKIM headers are absent. : leinen@diotima[lists.ietf.censored]; cat `egrep -l -i '^DKIM-Signature:' *` | egrep -i '^From:' | sort | uniq -c | wc -l 14 : leinen@diotima[lists.ietf.censored]; cat * | egrep -i '^From:' | sort | uniq -c | wc -l 114 -- Simon. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 16:16:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdX49-0005z3-2k; Thu, 04 Oct 2007 16:13:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdX46-0005ec-HU for ietf@ietf.org; Thu, 04 Oct 2007 16:12:58 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdX46-0004br-5n for ietf@ietf.org; Thu, 04 Oct 2007 16:12:58 -0400 X-IronPort-AV: E=Sophos;i="4.21,232,1188770400"; d="scan'208";a="154945916" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 04 Oct 2007 22:12:57 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l94KCv7T032697 for ; Thu, 4 Oct 2007 22:12:57 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l94KCvbR012929 for ; Thu, 4 Oct 2007 20:12:57 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 22:12:57 +0200 Received: from [10.1.0.20] ([10.61.67.57]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 22:12:56 +0200 In-Reply-To: References: <46EAE465.8070104@dcrocker.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ralph Droms Date: Thu, 4 Oct 2007 16:12:56 -0400 To: Ralph Droms X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Oct 2007 20:12:57.0063 (UTC) FILETIME=[F4358770:01C806C2] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15462.001 X-TM-AS-Result: No--21.965700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=851; t=1191528777; x=1192392777; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20Call=20for=20action=20vs.=20lost=20opportunity=20(Was =3A=20Re=3A=20Renumbering) |Sender:=20; bh=fk14L4KkQHvydXv8qfnolPfyyteldH9e3pwpyFap2OM=; b=gGBskpfhuDkOj79J6RtRc4n2ZKBjZ9fKoYfnDfBtw50u8EQPO2WD/uLRV9E8z0w2tmPM4InU KjbdfRxozPX0BCMyB2YCuB5o2kTCyUkXiCAOgSRW7a7XMuVnI/EY2t+6; Authentication-Results: ams-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: IETF-Discussion Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Typo: should read IPv6 ~= IPv4+more_bits... - Ralph On Oct 4, 2007, at Oct 4, 2007,4:52 AM, Ralph Droms wrote: > Regarding transition: > > On Sep 14, 2007, at Sep 14, 2007,3:43 PM, Dave Crocker wrote: >> >> >> Unless I've missed something rather basic, in the case of IPv6, >> very little >> attention was paid to facilitating transition by maximizing >> interoperability >> with the IPv4 installed base. > Dave, I have to agree with you in this regard. We may have > achieved neither > significant new capabilities because IPv6 ~= IPv6+more_bits, nor > ease of > transition because transition wasn't thoroughly evaluated early on in > the design process... > > - Ralph > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 16:21:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdX8H-0007cW-W7; Thu, 04 Oct 2007 16:17:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdX8G-0007YA-GC for ietf@ietf.org; Thu, 04 Oct 2007 16:17:16 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdX8G-0004n9-1b for ietf@ietf.org; Thu, 04 Oct 2007 16:17:16 -0400 X-IronPort-AV: E=Sophos;i="4.21,232,1188802800"; d="scan'208";a="179213336" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 04 Oct 2007 13:17:15 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l94KHFNV025246; Thu, 4 Oct 2007 13:17:15 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l94KH2qZ025150; Thu, 4 Oct 2007 20:17:15 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 13:17:03 -0700 Received: from [10.255.252.137] ([10.21.67.162]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 13:17:03 -0700 In-Reply-To: <4705414B.5000109@cs.utk.edu> References: <2788466ED3E31C418E9ACC5C31661557053529@mou1wnexmb09.vcorp.ad.vrsn.com> <4705414B.5000109@cs.utk.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <88CF0FED-D133-462A-89FA-15695E2F1874@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Thu, 4 Oct 2007 16:17:00 -0400 To: Keith Moore X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 04 Oct 2007 20:17:03.0379 (UTC) FILETIME=[87065E30:01C806C3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1544; t=1191529035; x=1192393035; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Spammers=20answering=20TMDA=20Queries |Sender:=20; bh=GeH+bLuekSRI7GsvYWbI1/mzHUTdneFGcepfVrT1t2I=; b=cO7cECm3zop7GDEBdmrm2JbMzmYpKk95O1Qu6Kk9aBvPbsryaSEDx4+zPCEn3Ju5Ys4z+4H3 gbDytLWx1MgZgBPWOWu/gK+PMq5YU4oGnYSbiwwlWpPJDy18tS/fI+xx340S1RM/fC8rJ/hreW vUp1hR3WSP7MpxmEZzRnXPFz8=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ietf@ietf.org Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I will disagree with you there. DKIM allows the concept of a corporate signature - "I'm Cisco and I know who my employee is" or "I'm Yahoo and I know who my user is" - but it doesn't require it. What it does require is that if you are not going to use the corporate servers you need to provide and support the signature you use. The former is, IMHO, an important step in scalability. The latter is status quo with PGP and S/MIME. On Oct 4, 2007, at 3:38 PM, Keith Moore wrote: > Hallam-Baker, Phillip wrote: >> Absolutely, and in fact I see mailing list management as a natural > early adopter for DKIM filtering. > > the problem I have with DKIM filtering is that it is only effective > for > domains that can reasonably insist that all of the mail originated by > users at that domain go through that domain's submission servers. > this > is a corner case, not the general case. sure the spammers will learn > to not use DKIM domains, but they'll just move to other domains, > and the > vast majority of domains won't be able to use DKIM without seriously > impairing their users' ability to send mail. of course, some of the > large ISPs and MSPs like it that way. > > frankly I don't think IETF should have backed a proposal that was so > unfairly biased toward a particular business model. > > Keith -----BEGIN PGP SIGNATURE----- iD8DBQFHBUo8bjEdbHIsm0MRAj/5AJ9cUHumt53uReMxuHrxRvQeJCkvsgCg8UCq I/+91c9ik2rREvhAwz1vMyk= =G55s -----END PGP SIGNATURE----- _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 16:25:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXBr-0000IJ-R6; Thu, 04 Oct 2007 16:20:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXBp-0000Cl-2N for ietf@ietf.org; Thu, 04 Oct 2007 16:20:57 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdXBo-0004wz-Kt for ietf@ietf.org; Thu, 04 Oct 2007 16:20:56 -0400 X-IronPort-AV: E=Sophos;i="4.21,232,1188802800"; d="scan'208";a="404109935" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 04 Oct 2007 13:20:42 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l94KKfGW015467; Thu, 4 Oct 2007 13:20:41 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l94KKf0W005576; Thu, 4 Oct 2007 20:20:41 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 13:20:30 -0700 Received: from [10.255.252.137] ([10.21.67.162]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 13:20:30 -0700 In-Reply-To: <4705414B.5000109@cs.utk.edu> References: <2788466ED3E31C418E9ACC5C31661557053529@mou1wnexmb09.vcorp.ad.vrsn.com> <4705414B.5000109@cs.utk.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Date: Thu, 4 Oct 2007 16:20:29 -0400 To: Keith Moore X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 04 Oct 2007 20:20:30.0661 (UTC) FILETIME=[02931750:01C806C4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1195; t=1191529241; x=1192393241; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Spammers=20answering=20TMDA=20Queries |Sender:=20; bh=EzPgfE2C68EOIjCln7I1KEHGktZjoVDSB/htt1eYNYQ=; b=McKj58vC0SGmx+71l4n0KSkXFzS3M3ghU+6CNcdseRwcbyqpG5bJQa8zIfqg5d6spt8mFQRj fD2FiRgwvLs/leeZGwfGskUrUDt+8LXBcEiAbtO+7HvMVqMAv2IeoQ0i; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ietf@ietf.org Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 4, 2007, at 3:38 PM, Keith Moore wrote: > the problem I have with DKIM filtering is that it is only effective > for domains that can reasonably insist that all of the mail > originated by users at that domain go through that domain's > submission servers. this is a corner case, not the general > case. sure the spammers will learn to not use DKIM domains, but > they'll just move to other domains, and the vast majority of > domains won't be able to use DKIM without seriously impairing their > users' ability to send mail. of course, some of the large ISPs and > MSPs like it that way. well, at some point it seems to me that we can take the next step, which is to require all email to IETF lists to be signed. Offer to accept DKIM, Microsoft's (as in "gmail"), PGP, and S/MIME, but require the signature and require it to verify. We're probably not yet at that point, but for companies that follow the kind of policy in question, we can take a step. -----BEGIN PGP SIGNATURE----- iD8DBQFHBUsNbjEdbHIsm0MRAnojAKD5IKz4vVvaZ5Qm7JImgxfHzNPmMACeJt5K /45ux7qbMKmV2CdbBK7acSg= =N1+N -----END PGP SIGNATURE----- _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 16:27:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXEa-0003SI-FJ; Thu, 04 Oct 2007 16:23:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXEZ-0003Qg-Gm for ietf@ietf.org; Thu, 04 Oct 2007 16:23:47 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdXER-0006gN-7j for ietf@ietf.org; Thu, 04 Oct 2007 16:23:45 -0400 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l94KKmFc022866; Thu, 4 Oct 2007 13:20:48 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 13:23:18 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 4 Oct 2007 13:19:59 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557053533@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <6D69802F-F58D-4149-A827-1ECD927675B3@wave-storm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv4 to IPv6 transition Thread-Index: AcgGtMdAhMYDuLSZRB2oq3EXvobHDAACRY6A From: "Hallam-Baker, Phillip" To: "Artur Hecker" , "IETF Discussion" X-OriginalArrivalTime: 04 Oct 2007 20:23:18.0313 (UTC) FILETIME=[6680C190:01C806C4] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: Subject: RE: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org The Y2K issue was almost certainly overblown, but it is important to = understand the reasons as they do not apply in the IPv4 case. The reason Y2K gained so much attention was that there was almost = perfect alignment between the party able to fix the problem and the = party able to cause the fix to be implemented.=20 The issue began as many companies recognised that if they did not spend = money to avert the Y2K problem that they would be the ones to suffer the = loss. If this was the only dynamic Y2K would have received more or less the = attention it deserved. Instead the problem was compounded by a couple of = additional factors. The first was the Y2K vampire who consultant-like turned every victim = into a new source of infection. The first thing a Y2K vampire would do = on claiming a new victim was to send out letters to every supplier = demanding to know if their systems have passed a Y2K audit. Thus the = poison spread at exponential speed.=20 Knowing that your company stands to lose $1 million if there is a Y2k = issue might cause you to spend $750k to avoid it. Having your hundred or = so customers demand to know if you are Y2K compliant puts your entire = company revenues at risk.=20 The second part to the dynamic was that all contrarian voices (including = my own) were suppressed. The only Y2K stories that could be printed in = advance described the impending catastrophe. Folk like myself who were = skeptical were not going to be covered - even when we were pointing out = blatantly obvious points such as the fact that we should not be overly = concerned about the threat of Y2k in third world countries where the = power, telephone etc infrastructure are unreliable in any case and one = particular outage is not an issue. The only Y2K issue I am aware of is one that was paradoxically caused by = a Y2K concern. One of the oldest X.509 roots expired on Dec 31 1999. The = date had been chosen precisely because of Y2K concerns, the fix to the = specification had not yet been ratified as a standard. At the time the = root was created nobody had anticipated that the level of Y2K paranoia = would make that date a bad choice of day for a cert to expire. So how does this all relate to IPv4/6? It does not. The problem with the = IPv6 transition is that the cost and benefit are completely out of = phase. The cost falls on those who have IPv4 addresses, the benefits = acrue only to those who do not. If you have an IPv4 address the fact = that others do not is not going to make a huge difference to the benefit = you get from the network.=20 Metcalf's law is overstated, the value of a network to an individual = user is at best proportional to its size. In practice the Blockbuster = effect means that there are diminishing returns. A network of four = billion plus one users is worth more or less the same to me as a user as = a network of four billion. The fact that there could be one more user is = not something that would greatly encourage me to upgrade my kit. At best = the value of the network to existing users is going to be the log of the = number of users.=20 Looking back at my personal use of networks I can certainly agree that = the number of users increases the value. I have seen the Web grow from = 100 users to a billion. The value has not increased at anything like the = same rate. The Web is certainly more useful today than in 2000 or 1995 = or 1992 but the increase in value has been linear, not exponential. The = Web does not help me to find ten million times more useful information = today than it did in 1992. So the idea that we can rely on the Internet haves to invest money to = benefit the Internet have-nots on the scale necessary is unfortunately = misguided.=20 I do think that we can make the IPv6 transition work. I do not think = that we can just expect it to happen and for everything to turn out just = right. Or that merely convincing people that there is going to be a = problem will result in a solution. We have to think like marketting people. > -----Original Message----- > From: Artur Hecker [mailto:hecker@wave-storm.com]=20 > Sent: Thursday, October 04, 2007 2:20 PM > To: IETF Discussion > Subject: Re: IPv4 to IPv6 transition >=20 > Hi >=20 >=20 > On 4 Oct 2007, at 19:50, Keith Moore wrote: >=20 > > > >> http://www.apple.com/jp/downloads/dashboard/networking_security/ > >> ipv420.h > >> tml > >> > >> Each time I see one of these "days remaining before Armaggedon" > >> counters, I can't help but remember what happened on=20 > January 1, 2000: > >> nothing. > >> > > yes, but that's because people heeded the warnings, and=20 > prepared. if=20 > > the same thing happens wrt IPv4 exhaustion, that will be fabulous. >=20 > No doubt - that nicely paid off our profession so we should=20 > not complain :-) >=20 > However, that's an intriguing discussion because I almost as=20 > often hear quite the contrary argument: indeed, given=20 > billions of USD and EUR spent on that issue, one could=20 > reasonably argue that the issue was overblown and ask to=20 > which degree this statement is true and what would have=20 > actually happened without all the pressure. >=20 > So far, I could not find anything really useful on that=20 > (proofs?) but keep on hearing very opposite positions, but=20 > it's maybe just me? >=20 > Does anybody have any established and sustained opinion on=20 > that and could provide verifiable if not objective data? How=20 > many critical bugs were really found in typical systems? What=20 > would have been the real impact? What could have happenned in=20 > terms of impact (meaning: =20 > it would definitely have happened, not the what-if analysis)?=20 > Was the cost higher than the estimated risk? >=20 >=20 > thanks for any pointers > artur >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 16:33:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXKk-0005iT-6Q; Thu, 04 Oct 2007 16:30:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXKf-0005a4-RD for ietf@ietf.org; Thu, 04 Oct 2007 16:30:05 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdXKf-0005IR-CP for ietf@ietf.org; Thu, 04 Oct 2007 16:30:05 -0400 X-IronPort-AV: E=Sophos;i="4.21,232,1188802800"; d="scan'208";a="404112388" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 04 Oct 2007 13:30:04 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l94KU4LQ016915; Thu, 4 Oct 2007 13:30:04 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l94KU4PC028114; Thu, 4 Oct 2007 20:30:04 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 13:30:04 -0700 Received: from [10.255.252.137] ([10.21.67.162]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 13:30:04 -0700 In-Reply-To: References: <2788466ED3E31C418E9ACC5C316615570534E4@mou1wnexmb09.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Date: Thu, 4 Oct 2007 16:29:59 -0400 To: Simon Leinen X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 04 Oct 2007 20:30:04.0232 (UTC) FILETIME=[58731480:01C806C5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2128; t=1191529804; x=1192393804; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Spammers=20answering=20TMDA=20Queries |Sender:=20; bh=a/Hi7hDMSVxv8Q+utiEr6Q1glJ7L8g8T+f05PbRiU2U=; b=IHQD8cR5qF542SwF9xHUbXbP5+ylDRjpURawVdxJ3IVilEIeiUGCfUfCPieKYsHncEm53McW V3ljOyp3f5m6aRvmX0zvDH0tufP0egcxyMugi3cj8yKOni4baCERun4I4SeetWlBKjnMEpqwhx V1OxdGEunVnszrRgNf5phMIVs=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ietf@ietf.org Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As I understand it, the spammers were among the first adopters of dkim. My point is not that "spammers don't sign". Some spammers don't sign and can (eventually, not now) be dropped because they don't. Other spammers do sign and can be identified and shunned by policy. But certainly, spammers spoofing source addresses will be unable to sign as the spoofed sending domain, and can have their traffic summarily discarded as either being unsigned but purporting to come from a domain that signs or as having invalid signatures. Traffic with spoofed source addresses from domains that sign needs no moderation. The moderation load is the problem we're solving. On Oct 4, 2007, at 4:08 PM, Simon Leinen wrote: > Fred Baker writes: >> On Oct 4, 2007, at 11:56 AM, Hallam-Baker, Phillip wrote: > >>> The problem is the amount of time it is taking to moderate mail >>> sent by non subscribers. > >> yes. For example, every email from @cisco.com is dkim-signed. The >> IETF can automagically dump any such email that is not signed, or for >> which the signature doesn't check out. I know that fred@cisco.com is >> one of many commonly-spoofed email addresses - I can tell that from >> the backscatter I find in my junk box. > >> For how many of us is that true? > > FWIW, about 12% (14 out of 114) of the active non-spam senders to this > list had DKIM-Signature headers in the past two weeks. I don't know > enough about DKIM to tell whether the same assumption holds for the > non-cisco.com sender domains (mostly gmail.com plus a few smaller > ones): that mail from them can be considered spoofed if the DKIM > headers are absent. > > : leinen@diotima[lists.ietf.censored]; cat `egrep -l -i '^DKIM- > Signature:' *` | egrep -i '^From:' | sort | uniq -c | wc -l > 14 > : leinen@diotima[lists.ietf.censored]; cat * | egrep -i '^From:' | > sort | uniq -c | wc -l > 114 > -- > Simon. -----BEGIN PGP SIGNATURE----- iD8DBQFHBU1HbjEdbHIsm0MRAgnNAKDH4BEX5g/aAxHFtK0Ibk3/URKfOACgqqhH IDAsrh1QRfvxMWxkuEUpFIo= =BiFX -----END PGP SIGNATURE----- _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 16:33:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXJm-0004bk-6g; Thu, 04 Oct 2007 16:29:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXJk-0004SE-F9 for ietf@ietf.org; Thu, 04 Oct 2007 16:29:08 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdXJX-0006wf-E4 for ietf@ietf.org; Thu, 04 Oct 2007 16:29:01 -0400 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l94KPPIi026651; Thu, 4 Oct 2007 13:25:25 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 13:28:24 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 4 Oct 2007 13:25:05 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557053534@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <4705414B.5000109@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Spammers answering TMDA Queries Thread-Index: AcgGvjfEgJPfBrlCRTGG8HJK4YjXwgABc2Ug From: "Hallam-Baker, Phillip" To: "Keith Moore" X-OriginalArrivalTime: 04 Oct 2007 20:28:24.0013 (UTC) FILETIME=[1CB6DFD0:01C806C5] X-Spam-Score: -4.0 (----) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Fred Baker , ietf@ietf.org Subject: RE: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I fail to see your point here. Anyone can deploy DKIM, there is nothing unfair about the DKIM = architecture. The 'unfairness' that you appear to be complaining about is that DKIM = solves a problem that only targets a relatively small number of Internet = domains, although the effects of that attack are seen by everyone.=20 Impersonation of a trusted brand is always going to assit a social = engineering attack if this is possible. I do not understand the = ideological calculus under which we should do nothing to protect = consumers against attacks of this nature because we can't all have a = trusted brand. > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu]=20 > Sent: Thursday, October 04, 2007 3:39 PM > To: Hallam-Baker, Phillip > Cc: Fred Baker; ietf@ietf.org > Subject: Re: Spammers answering TMDA Queries >=20 > Hallam-Baker, Phillip wrote: > > Absolutely, and in fact I see mailing list management as a natural > early adopter for DKIM filtering. >=20 > the problem I have with DKIM filtering is that it is only=20 > effective for domains that can reasonably insist that all of=20 > the mail originated by > users at that domain go through that domain's submission=20 > servers. this > is a corner case, not the general case. sure the spammers will learn > to not use DKIM domains, but they'll just move to other=20 > domains, and the vast majority of domains won't be able to=20 > use DKIM without seriously impairing their users' ability to=20 > send mail. of course, some of the large ISPs and MSPs like=20 > it that way.=20 >=20 > frankly I don't think IETF should have backed a proposal that=20 > was so unfairly biased toward a particular business model. >=20 > Keith >=20 >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 17:03:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXgn-0007rp-2R; Thu, 04 Oct 2007 16:52:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXgl-0007iC-1G for ietf@ietf.org; Thu, 04 Oct 2007 16:52:55 -0400 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdXge-0008KR-C7 for ietf@ietf.org; Thu, 04 Oct 2007 16:52:55 -0400 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id A22461035D2; Thu, 4 Oct 2007 16:52:43 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtgRtLyF6zV2; Thu, 4 Oct 2007 16:52:41 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id 7753D1035A7; Thu, 4 Oct 2007 16:52:40 -0400 (EDT) Message-ID: <47055293.4080200@cs.utk.edu> Date: Thu, 04 Oct 2007 16:52:35 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Michael Thomas References: <2788466ED3E31C418E9ACC5C31661557053529@mou1wnexmb09.vcorp.ad.vrsn.com> <4705414B.5000109@cs.utk.edu> <4705471D.3060102@cisco.com> In-Reply-To: <4705471D.3060102@cisco.com> X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Fred Baker , ietf@ietf.org Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >> the problem I have with DKIM filtering is that it is only effective >> for domains that can reasonably insist that all of the mail >> originated by users at that domain go through that domain's >> submission servers. this is a corner case, not the general case. > > Back in the day, we didn't have any of this VeePeeEn tomfoolery. I > could just telnet in and that was that. I'm sure that our IT folks > paid dearly in time, equipment, and support to throw up that wall, yet > they did it and as far as I can tell we all survived the move. I > don't see anything especially different with mail: if you want > accountability, you have to do real live work -- part of which is > placing restrictions on access. TANSTAAFL. what you are failing to see is just how much reliance on VPNs (and source IPs) to do authentication cripples the network. sure it's better than nothing, but it's also very inflexible and an architectural dead end. (and the problem with TANSTAAFL is that you can use it to justify any kind of brain damage you want, as long as there's some minor associated benefit) >> sure the spammers will learn to not use DKIM domains, but they'll >> just move to other domains, > This is a feature, not a bug: I don't have to outrun the bear, I just > need to outrun you. I'll remind you that as a condition to working in IETF we are all pledged to use our judgment as to what's best for the Internet as a whole...not just for those who can run faster than others. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 17:20:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXvw-0005FY-IV; Thu, 04 Oct 2007 17:08:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXvv-00059Z-7U for ietf@ietf.org; Thu, 04 Oct 2007 17:08:35 -0400 Received: from bes.cs.utk.edu ([160.36.56.220]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdXvu-00075A-S4 for ietf@ietf.org; Thu, 04 Oct 2007 17:08:35 -0400 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id 5D7A01035FD; Thu, 4 Oct 2007 17:08:34 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIovi+qXBu4g; Thu, 4 Oct 2007 17:08:30 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id 505B6103593; Thu, 4 Oct 2007 17:08:25 -0400 (EDT) Message-ID: <47055645.1050209@cs.utk.edu> Date: Thu, 04 Oct 2007 17:08:21 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2788466ED3E31C418E9ACC5C31661557053534@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <2788466ED3E31C418E9ACC5C31661557053534@mou1wnexmb09.vcorp.ad.vrsn.com> X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Fred Baker , ietf@ietf.org Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hallam-Baker, Phillip wrote: > I fail to see your point here. > > Anyone can deploy DKIM, there is nothing unfair about the DKIM architecture. it artificially changes the relative value of domain names. it makes them more like brand names, where you have to work to build a domain's reputation in order to get people to trust it. it means that domains which are associated with large user communities with a good reputation will be more trusted than domains with small user communities, even when those domains are equally diligent. in that way DKIM favors the interests of large concerns over small ones. so it's not surprising that several large concerns backed it. but that doesn't mean it's a good thing for the Internet as a whole. > The 'unfairness' that you appear to be complaining about is that DKIM solves a problem that only targets a relatively small number of Internet domains, although the effects of that attack are seen by everyone. > indeed, DKIM might help address the phishing problem, if that's what you're talking about. and large concerns are disproportionally affected by phishing. but ultimately I think there's only a small chance of DKIM helping the phishing problem much, because of user interface issues and because there are lots of ways to fool people into thinking that they're responding to a FemtoSquishy email without having femtosquishy.com in the From address or signature. > Impersonation of a trusted brand is always going to assit a social engineering attack if this is possible. I do not understand the ideological calculus under which we should do nothing to protect consumers against attacks of this nature because we can't all have a trusted brand. > using DKIM to discourage phishing is a different use case than using it to authenticate to IETF lists. just because it might work well for the former (if indeed it does) does not mean it can be relied on to work well for the latter. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 17:20:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXxt-0006pU-3m; Thu, 04 Oct 2007 17:10:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXxr-0006lc-Nb for ietf@ietf.org; Thu, 04 Oct 2007 17:10:35 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdXxl-0000o0-FW for ietf@ietf.org; Thu, 04 Oct 2007 17:10:35 -0400 Received: from [192.168.0.2] (adsl-67-127-53-203.dsl.pltn13.pacbell.net [67.127.53.203]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l94L9v0l025867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Oct 2007 14:09:58 -0700 Message-ID: <470556A5.3070008@dcrocker.net> Date: Thu, 04 Oct 2007 14:09:57 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ietf@ietf.org References: <2788466ED3E31C418E9ACC5C31661557053529@mou1wnexmb09.vcorp.ad.vrsn.com> <4705414B.5000109@cs.utk.edu> <88CF0FED-D133-462A-89FA-15695E2F1874@cisco.com> In-Reply-To: <88CF0FED-D133-462A-89FA-15695E2F1874@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Folks, Fred Baker wrote: > I will disagree with you there. DKIM allows the concept of a corporate > signature - "I'm Cisco and I know who my employee is" or "I'm Yahoo and > I know who my user is" - but it doesn't require it. What it does require This is a key point. A DKIM is signature is an affirmative statement of responsibility by the Domain owner, *for that message*. So when a signature is present, you have an accountable entity. Whether you actually have any trust in that entity is a separate (and more interesting) question. Assessment mechanisms for an authenticated domain name, do not have any standards yet. For that matter, a standard that signals that a site signs all mail containing their domain in a particular field is also a matter still awaiting standardization. At the moment, the "I sign everything" construct is ad hoc. A domain can know it about itself, of course, so that cisco can detect inbound mail that forges cisco's domain. For now, other recipient sites require ad hoc lists. What DKIM has not yet been established for, is filtering out bad mail. Although the "I sign everything" construct is expected to help this, there is no meaningful track record that it really works. More generally, this thread has been dominated by views that there are single, simple, well-understood solutions for the problem(s) being cited. Among the anti-abuse community, the consensus is that effective mechanisms are not singular, not simple, and not yet well-understood. On the average, the public community -- and I'm afraid that the IETF mailing list appears to fall into the broad, non-technical category -- entirely underestimates the sophistication of modern email abuse mechanisms. John Levine and others have been making this point on the thread, but it does not seem to be registering. Having mail receivers at ietf.org take note of email authentication is a Good Thing. Assuming that this is going to "solve" any particular email problem is not. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 17:20:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXvw-0005FY-IV; Thu, 04 Oct 2007 17:08:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXvv-00059Z-7U for ietf@ietf.org; Thu, 04 Oct 2007 17:08:35 -0400 Received: from bes.cs.utk.edu ([160.36.56.220]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdXvu-00075A-S4 for ietf@ietf.org; Thu, 04 Oct 2007 17:08:35 -0400 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id 5D7A01035FD; Thu, 4 Oct 2007 17:08:34 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIovi+qXBu4g; Thu, 4 Oct 2007 17:08:30 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id 505B6103593; Thu, 4 Oct 2007 17:08:25 -0400 (EDT) Message-ID: <47055645.1050209@cs.utk.edu> Date: Thu, 04 Oct 2007 17:08:21 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2788466ED3E31C418E9ACC5C31661557053534@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <2788466ED3E31C418E9ACC5C31661557053534@mou1wnexmb09.vcorp.ad.vrsn.com> X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Fred Baker , ietf@ietf.org Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hallam-Baker, Phillip wrote: > I fail to see your point here. > > Anyone can deploy DKIM, there is nothing unfair about the DKIM architecture. it artificially changes the relative value of domain names. it makes them more like brand names, where you have to work to build a domain's reputation in order to get people to trust it. it means that domains which are associated with large user communities with a good reputation will be more trusted than domains with small user communities, even when those domains are equally diligent. in that way DKIM favors the interests of large concerns over small ones. so it's not surprising that several large concerns backed it. but that doesn't mean it's a good thing for the Internet as a whole. > The 'unfairness' that you appear to be complaining about is that DKIM solves a problem that only targets a relatively small number of Internet domains, although the effects of that attack are seen by everyone. > indeed, DKIM might help address the phishing problem, if that's what you're talking about. and large concerns are disproportionally affected by phishing. but ultimately I think there's only a small chance of DKIM helping the phishing problem much, because of user interface issues and because there are lots of ways to fool people into thinking that they're responding to a FemtoSquishy email without having femtosquishy.com in the From address or signature. > Impersonation of a trusted brand is always going to assit a social engineering attack if this is possible. I do not understand the ideological calculus under which we should do nothing to protect consumers against attacks of this nature because we can't all have a trusted brand. > using DKIM to discourage phishing is a different use case than using it to authenticate to IETF lists. just because it might work well for the former (if indeed it does) does not mean it can be relied on to work well for the latter. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 17:20:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXxt-0006pU-3m; Thu, 04 Oct 2007 17:10:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXxr-0006lc-Nb for ietf@ietf.org; Thu, 04 Oct 2007 17:10:35 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdXxl-0000o0-FW for ietf@ietf.org; Thu, 04 Oct 2007 17:10:35 -0400 Received: from [192.168.0.2] (adsl-67-127-53-203.dsl.pltn13.pacbell.net [67.127.53.203]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l94L9v0l025867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Oct 2007 14:09:58 -0700 Message-ID: <470556A5.3070008@dcrocker.net> Date: Thu, 04 Oct 2007 14:09:57 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ietf@ietf.org References: <2788466ED3E31C418E9ACC5C31661557053529@mou1wnexmb09.vcorp.ad.vrsn.com> <4705414B.5000109@cs.utk.edu> <88CF0FED-D133-462A-89FA-15695E2F1874@cisco.com> In-Reply-To: <88CF0FED-D133-462A-89FA-15695E2F1874@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Folks, Fred Baker wrote: > I will disagree with you there. DKIM allows the concept of a corporate > signature - "I'm Cisco and I know who my employee is" or "I'm Yahoo and > I know who my user is" - but it doesn't require it. What it does require This is a key point. A DKIM is signature is an affirmative statement of responsibility by the Domain owner, *for that message*. So when a signature is present, you have an accountable entity. Whether you actually have any trust in that entity is a separate (and more interesting) question. Assessment mechanisms for an authenticated domain name, do not have any standards yet. For that matter, a standard that signals that a site signs all mail containing their domain in a particular field is also a matter still awaiting standardization. At the moment, the "I sign everything" construct is ad hoc. A domain can know it about itself, of course, so that cisco can detect inbound mail that forges cisco's domain. For now, other recipient sites require ad hoc lists. What DKIM has not yet been established for, is filtering out bad mail. Although the "I sign everything" construct is expected to help this, there is no meaningful track record that it really works. More generally, this thread has been dominated by views that there are single, simple, well-understood solutions for the problem(s) being cited. Among the anti-abuse community, the consensus is that effective mechanisms are not singular, not simple, and not yet well-understood. On the average, the public community -- and I'm afraid that the IETF mailing list appears to fall into the broad, non-technical category -- entirely underestimates the sophistication of modern email abuse mechanisms. John Levine and others have been making this point on the thread, but it does not seem to be registering. Having mail receivers at ietf.org take note of email authentication is a Good Thing. Assuming that this is going to "solve" any particular email problem is not. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 17:22:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdY6F-0004qP-9C; Thu, 04 Oct 2007 17:19:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdY6B-0004KV-FN; Thu, 04 Oct 2007 17:19:11 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdY6B-0007ZO-1s; Thu, 04 Oct 2007 17:19:11 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.1/8.12.5/1.0) with ESMTP id l94LJ99H010017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 Oct 2007 14:19:10 -0700 Received: from [10.255.251.136] (vpn-10-50-0-32.qualcomm.com [10.50.0.32]) by sabrina.qualcomm.com (8.14.1/8.13.6/1.0) with ESMTP id l94LJ8Xh029062; Thu, 4 Oct 2007 14:19:08 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 4 Oct 2007 17:19:07 -0400 To: The IESG From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ietf@ietf.org Subject: Re: On Appeals of IESG and Area Director Actions and Decisions X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 4:34 PM -0400 10/4/07, The IESG wrote: >The IESG re-affirms that its reading of RFC 2026 is that any action >made by an Area Director or the IESG may by made the subject of the >conflict resolution mechanisms set out in Section 6.5 of RFC 2026. >The IESG further wishes to highlight that the primary aim of the >appeals mechanism set out there is to resolve conflicts and move the >IETF as a whole towards consensus, and it urges all participants to >approach them in that light. > Thanks very much for your early consideration of this matter; I appreciate very much the IESG taking this out of "lore" and making a positive statement on this. It is not clear from this whether this will be a statement of the IESG as are those found at http://www.ietf.org/IESG/Statements.html . I encourage the IESG to make it available there, as it seems to me more likely that those attempting to understand this issue will find it there than by going through email archives. My thanks again, regards, Ted Hardie _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 17:35:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdYDw-0005Vh-GZ; Thu, 04 Oct 2007 17:27:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdYDu-0005VQ-C9 for ietf@ietf.org; Thu, 04 Oct 2007 17:27:10 -0400 Received: from wa-out-1112.google.com ([209.85.146.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdYDt-00007b-He for ietf@ietf.org; Thu, 04 Oct 2007 17:27:10 -0400 Received: by wa-out-1112.google.com with SMTP id k40so500833wah for ; Thu, 04 Oct 2007 14:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=2ZjTLKhbUt49Dn8EWhvi7PahjhQ/kiDgZFaGrUn+yCI=; b=t3lzGE7hDzckaPuZgnEqkjZw5tRoiCSH64oy6nWIfgK7tOqVwEso7t3ypSGRO3yP6Rb3RNzs8WE+Zr/PkH3gNUQOYROYRtaBZ55QlqZ4FEKjtOdYpkqtvXRWkskP/p40I7y9uDNELOVU8tHaq0lRzjw/o1PbgKWFgXAeVrI7Nv4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=L4jug3zEi64JJJ7JuRiSNtvN1ZTZR8d5a3Oe+jFrd+G/DyiBF13KqM/3bCuEnMdbE5LORs0lfbNPP0FH4LyMldN8dEp8FbMeBHzJSm9F6ibRXxU26xIzLSb329gdVR9xW8rDia7KuWco3s7vF2FSwZwzqG1OdXx4JokVAlI1L14= Received: by 10.115.79.1 with SMTP id g1mr6320600wal.1191533227095; Thu, 04 Oct 2007 14:27:07 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id j7sm4557515wah.2007.10.04.14.27.02 (version=SSLv3 cipher=RC4-MD5); Thu, 04 Oct 2007 14:27:04 -0700 (PDT) Message-ID: <47055AA3.40605@gmail.com> Date: Fri, 05 Oct 2007 10:26:59 +1300 From: Brian E Carpenter User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ken carlberg References: <67602DA7-6B73-422C-95D3-7D216E0F388F@g11.org.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: tsvwg@ietf.org, Pekka Savola , ietf@ietf.org Subject: Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-05 05:38, ken carlberg wrote: > >> I don't recall when was the last (Diffserv-based) QoS talk at NANOG or >> similar operator-rich meeting. (Sure, there is the tutorial, but it >> doesn't count.) > > I would be concerned if outside groups spent time arguing "foo" is bad, > or if they advocated other positions to the same issue. But I tend to > feel quite uncomfortable with litmus tests based on inactivity of other > groups/people. My personal view is that advocates of that line of > reasoning place a bigger burden on themselves in providing specific > in-depth arguments. > >> Seems like a potential indication that most typical ISPs aren't >> working on or interested in this, this stuff is so trivial, or that >> coordination is not necessary. > > i appreciate work that is trivial because its generally simple, easy to > accomplish, and leads to fewer interoperability issues. as for ISPs, > its fascinating the disparity of how quiet and talkative they are > depending on what side of the NDA you are on :-) In any case, if Pekka is correct, that's *exactly* why this draft and RFC 4594 are needed - to lay a minimum foundation on which ISPs can build operational practices and SLAs. It's always been clear to me that voice and video would be the main drivers for uptake of diffserv, and Marshall's comments confirm that. As that type of traffic grows, ISPs won't have any choice. Guidnace from the IETF seems entirely appropriate. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 18:43:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdZFh-0001pP-Bu; Thu, 04 Oct 2007 18:33:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdZFe-0001ed-TD; Thu, 04 Oct 2007 18:33:02 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdZFP-0004fO-SB; Thu, 04 Oct 2007 18:32:54 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 7BE7933C21; Thu, 4 Oct 2007 15:28:12 -0700 (PDT) Date: Thu, 04 Oct 2007 15:28:11 -0700 From: Eric Rescorla To: secdir@ietf.org, ietf@ietf.org, lemonade@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071004222812.7BE7933C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: Subject: Comments on draft-ietf-lemonade-reconnect-client-06 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org $Id: draft-ietf-lemonade-reconnect-client-06-rev.txt,v 1.1 2007/10/04 22:25:53 ekr Exp $ OVERALL This document describes an extension to IMAP to provide faster synchronization between client and server. As far as I can tell, the optimizations are: - Removing one round trip needed to discover which messages have been expunged. - A more compact representation of the list of expunged messages I have some skepticism about the importance of these optimizations. The document does not come with any performance measurements, and 1 RTT really isn't that much. In particular, I wonder if VANISHED really saves that much bandwidth over EXPUNGED if compression is in use. I don't know what standard is being used to decide whether optimizations of this type are worthwhile. I found this document fairly hard to read. I understand that it's a delta to IMAP and requires quite a bit of knowledge of IMAP to understand, but I think it could have been written to be more clear about how it changes IMAP's behavior in each case. In particular, the examples would be improved by always having New and Old and having some sort of indicator of exactly which PDUs have changed and why. DETAILED COMMENTS S 2. This would be improved by some overall diagram of the new and old behavior and some measurement, even an ad hoc one, of the performance improvement. S 3.1. Conceptually, the client provides a small sample of sequence numbers for which it knows the corresponding UIDs. The server then compares each sequence number and UID pair the client provides with the current state of the mailbox. If a pair matches, then the client knows of any expunges up to, and including, the message, and thus will not include that range in the VANISHED response, even if the "mod-sequence-value" provided by the client is too old for the server to have data of when those messages were expunged. This is probably my ignorance of IMAP, but how can this happen? Why doesn't the client have a mod-sequence-value corresponds to these UIDs? S: * VANISHED (EARLIER) 1:2,4:5,7:8,10:11,13:14 [...] 29998:29999,30001:30002,30004:30005,30007:30008 This [...] hides the data you're optimizing away, right? This would help if it were called out more clearly. S 3.3, 3.4, 3.5. These would all benefit from a statement of how they differ from 3501, rather than just stating new rules. If the server is capable of storing modification sequences for the selected mailbox, it MUST increment the per-mailbox mod-sequence if at least one message was permanently removed due to the execution of the EXPUNGE command. For each permanently removed message the server MUST remember the incremented mod-sequence and corresponding UID. If at least one message got expunged, the server MUST send the updated per-mailbox modification sequence using the HIGHESTMODSEQ response code (defined in [CONDSTORE]) in the tagged OK response. So, this is repeated in all three sections. That seems less than optimal. Rather than refing 3501, it would probably be good to point out why the message #s are as they are in these examples, due to auto-decrement. S 3.6. The VANISHED response has two forms. The first form contains the EARLIER tag, which signifies that the response was caused by a UID FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command. This response is sent if the UID set parameter to the UID FETCH (VANISHED) command includes UIDs of messages that are no longer in the mailbox. When the client sees a VANISHED EARLIER response it MUST NOT decrement message sequence numbers for each successive message in the mailbox. The second form doesn't contain the EARLIER tag and is described below. Once a client has used "(VANISHED)" with a UID FETCH or "(QRESYNC)" with SELECT/EXAMINE command, the server SHOULD use the VANISHED response without the EARLIER tag instead of the EXPUNGE response. The server SHOULD continue using VANISHED in lieu of EXPUNGE for the duration of the connection. In particular this affects the EXPUNGE [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as well as messages expunged in other connections. Such VANISHED response MUST NOT contain the EARLIER tag. This is pretty unclear to the non-IMAP expert. Could you explain in english what this is trying to accomplish in the document, not just specify the protocol mechanics. In the example, swap before and after. Also, it would be good to show an example of (EARLIER). S 4.1. Strictly speaking, a server implementation that doesn't remember modsequences associated with expunged messages can be considered compliant with this specification. Such implementations return all expunged messages specified in the UID set of the UID FETCH (VANISHED) command every time, without paying attention to the specified CHANGEDSINCE modsequence. Such implementations are discouraged, as they can end up returning VANISHED responses bigger than the result of a UID SEARCH command for the same UID set. Isn't this inconsistent with: If the server is capable of storing modification sequences for the selected mailbox, it MUST increment the per-mailbox mod-sequence if at least one message was permanently removed due to the execution of the EXPUNGE command. For each permanently removed message the server MUST remember the incremented mod-sequence and corresponding UID. If at least one message got expunged, the server MUST send the updated per-mailbox modification sequence using the HIGHESTMODSEQ response code (defined in [CONDSTORE]) in the tagged OK response. If not, why not? S 5. The client MUST also take note of any MODSEQ FETCH data items received from the server. Whenever the client receives a tagged response to a command, it calculates the highest value among all MODSEQ FETCH data items received since the last tagged response. If this value is bigger than the client's copy of the HIGHESTMODSEQ value, then the client MUST use this value as its new HIGHESTMODSEQ value. So, I probably misunderstand something, but my read of 4551 made it seem like you could do a MODSEQ FETCH that would not return all the metadata for every message. In that case, wouldn't this procedure risk you having a modseq that is higher than some messages you haven't examined yet? What am I missing. I don't see any new security issues in this document. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 18:46:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdZPi-0001Id-UK; Thu, 04 Oct 2007 18:43:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdZPh-0001IS-Ly for ietf@ietf.org; Thu, 04 Oct 2007 18:43:25 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdZPh-000337-7P for ietf@ietf.org; Thu, 04 Oct 2007 18:43:25 -0400 X-IronPort-AV: E=Sophos;i="4.21,232,1188802800"; d="scan'208";a="230784962" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 04 Oct 2007 15:43:24 -0700 Received: from 64-142-29-214.dsl.static.sonic.net ([10.82.242.189]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l94LJJUl028488; Thu, 4 Oct 2007 14:19:21 -0700 Message-ID: <47056CCC.1060803@cisco.com> Date: Thu, 04 Oct 2007 15:44:28 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Keith Moore References: <2788466ED3E31C418E9ACC5C31661557053529@mou1wnexmb09.vcorp.ad.vrsn.com> <4705414B.5000109@cs.utk.edu> <4705471D.3060102@cisco.com> <47055293.4080200@cs.utk.edu> In-Reply-To: <47055293.4080200@cs.utk.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2382; t=1191532762; x=1192396762; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20Spammers=20answering=20TMDA=20Queries |Sender:=20 |To:=20Keith=20Moore=20; bh=M4198SRY4NMWzvYpHRqlQGzYGvnWfiOrNUJR4tcWn58=; b=EVkaJaG3cVu0V0ujRi0P/msnelunV5Poyt3/Kwz7zzyZ8JC7OGDKQfM/z6tZth5Txvvsrbtn +B4w9EF74a5hmnA2m+B6/66XoKpjCi8Avu/xaakxCuIk54/MdBx7R1eB; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Fred Baker , ietf@ietf.org Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Keith Moore wrote: >>> the problem I have with DKIM filtering is that it is only effective >>> for domains that can reasonably insist that all of the mail >>> originated by users at that domain go through that domain's >>> submission servers. this is a corner case, not the general case. >>> >> Back in the day, we didn't have any of this VeePeeEn tomfoolery. I >> could just telnet in and that was that. I'm sure that our IT folks >> paid dearly in time, equipment, and support to throw up that wall, yet >> they did it and as far as I can tell we all survived the move. I >> don't see anything especially different with mail: if you want >> accountability, you have to do real live work -- part of which is >> placing restrictions on access. TANSTAAFL. >> > what you are failing to see is just how much reliance on VPNs (and > source IPs) to do authentication cripples the network. sure it's better > than nothing, but it's also very inflexible and an architectural dead end. > C'est la guerre. In fact, I'm well aware of all of those things, and I'll even allow that our IT folks were probably aware of all of those things too -- they undoubtedly took a lot of flak from the Eldar who probably said the same thing. I'm also pretty sure that they would dismiss anybody who told them to tear out their VPN gear because it cripples the network and is an architectural dead. Same goes for email. >>> sure the spammers will learn to not use DKIM domains, but they'll >>> just move to other domains, >>> >> This is a feature, not a bug: I don't have to outrun the bear, I just >> need to outrun you. >> > I'll remind you that as a condition to working in IETF we are all > pledged to use our judgment as to what's best for the Internet as a > whole...not just for those who can run faster than others. > I guess I must have been in the bar when they had that pledge of allegiance. But even allowing that there is any such pledge, to the degree that we enable domains to control who uses their name and be accountable when they behave badly is certainly a net good thing IMO. Your original makes it sound like there's some inherent right to be heard. There isn't. If you don't want to be accountable, then maybe I just don't want to bother sorting your wheat from chaff. Mike _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 04 20:40:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idb0f-00038S-1j; Thu, 04 Oct 2007 20:25:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idb0c-0002yA-NB for ietf@ietf.org; Thu, 04 Oct 2007 20:25:38 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idb0W-0008Bl-JQ for ietf@ietf.org; Thu, 04 Oct 2007 20:25:38 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 6920E1EE2DF; Thu, 4 Oct 2007 20:25:17 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqbCReJ2Yuxh; Thu, 4 Oct 2007 20:25:13 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 62A4E1EE2D7; Thu, 4 Oct 2007 20:25:10 -0400 (EDT) Message-ID: <4705845F.10809@cs.utk.edu> Date: Thu, 04 Oct 2007 20:25:03 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Michael Thomas References: <2788466ED3E31C418E9ACC5C31661557053529@mou1wnexmb09.vcorp.ad.vrsn.com> <4705414B.5000109@cs.utk.edu> <4705471D.3060102@cisco.com> <47055293.4080200@cs.utk.edu> <47056CCC.1060803@cisco.com> In-Reply-To: <47056CCC.1060803@cisco.com> X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Fred Baker , ietf@ietf.org Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > I guess I must have been in the bar when they had that pledge of > allegiance. But > even allowing that there is any such pledge, to the degree that we > enable domains > to control who uses their name and be accountable when they behave > badly is > certainly a net good thing IMO. domains don't behave well or badly. they're just names. and I don't think it's in the internet's interest to require people to associate themselves with what is essentially a brand name in order to be heard. using DKIM for spam filtering pretty much does that. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 05 01:01:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdfBj-0007ih-8z; Fri, 05 Oct 2007 00:53:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdfBh-0007iW-8K for ietf@ietf.org; Fri, 05 Oct 2007 00:53:21 -0400 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdfBg-0005L8-NX for ietf@ietf.org; Fri, 05 Oct 2007 00:53:21 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l954rIhc018935 for ; Fri, 5 Oct 2007 00:53:18 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l954rIMH669180 for ; Fri, 5 Oct 2007 00:53:18 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l954rDKg024418 for ; Fri, 5 Oct 2007 00:53:13 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l954rChH024200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Oct 2007 00:53:12 -0400 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.14.1/8.12.5) with ESMTP id l954r2q1021399 for ; Fri, 5 Oct 2007 00:53:02 -0400 Received: (from narten@localhost) by rotala.raleigh.ibm.com (8.14.1/8.14.1/Submit) id l954r2kj021386 for ietf@ietf.org; Fri, 5 Oct 2007 00:53:02 -0400 Date: Fri, 5 Oct 2007 00:53:02 -0400 From: Thomas Narten Message-Id: <200710050453.l954r2kj021386@rotala.raleigh.ibm.com> To: ietf@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: Weekly posting summary for ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Total of 149 messages in the last 7 days. script run at: Fri Oct 5 00:53:02 EDT 2007 Messages | Bytes | Who --------+------+--------+----------+------------------------ 7.38% | 11 | 6.12% | 53001 | moore@cs.utk.edu 5.37% | 8 | 5.56% | 48115 | mark_andrews@isc.org 4.70% | 7 | 5.46% | 47258 | pbaker@verisign.com 2.01% | 3 | 7.79% | 67389 | tgondrom@opentext.com 4.70% | 7 | 4.84% | 41929 | brian.e.carpenter@gmail.com 4.70% | 7 | 4.37% | 37830 | danny@tcb.net 3.36% | 5 | 3.51% | 30391 | fred@cisco.com 3.36% | 5 | 2.73% | 23667 | bortzmeyer@nic.fr 3.36% | 5 | 2.18% | 18856 | itojun@itojun.org 2.68% | 4 | 2.79% | 24102 | plzak@arin.net 2.68% | 4 | 2.50% | 21602 | mat@cisco.com 2.68% | 4 | 2.27% | 19684 | dhc2@dcrocker.net 2.68% | 4 | 1.97% | 17077 | hartmans-ietf@mit.edu 2.68% | 4 | 1.93% | 16669 | johnl@iecc.com 2.01% | 3 | 1.82% | 15774 | paul.hoffman@vpnc.org 0.67% | 1 | 3.01% | 26031 | elisa.boschi@hitachi-eu.com 2.01% | 3 | 1.65% | 14290 | jabley@ca.afilias.info 2.01% | 3 | 1.43% | 12336 | paul@xelerance.com 1.34% | 2 | 1.65% | 14297 | ekr@networkresonance.com 1.34% | 2 | 1.31% | 11350 | rdroms@cisco.com 1.34% | 2 | 1.23% | 10631 | nicolas.williams@sun.com 1.34% | 2 | 1.20% | 10396 | sm@resistor.net 1.34% | 2 | 1.20% | 10390 | dotis@mail-abuse.org 1.34% | 2 | 1.19% | 10278From ietf-bounces@ietf.org Fri Oct 05 01:01:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdfBj-0007ih-8z; Fri, 05 Oct 2007 00:53:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdfBh-0007iW-8K for ietf@ietf.org; Fri, 05 Oct 2007 00:53:21 -0400 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdfBg-0005L8-NX for ietf@ietf.org; Fri, 05 Oct 2007 00:53:21 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l954rIhc018935 for ; Fri, 5 Oct 2007 00:53:18 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l954rIMH669180 for ; Fri, 5 Oct 2007 00:53:18 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l954rDKg024418 for ; Fri, 5 Oct 2007 00:53:13 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l954rChH024200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Oct 2007 00:53:12 -0400 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.14.1/8.12.5) with ESMTP id l954r2q1021399 for ; Fri, 5 Oct 2007 00:53:02 -0400 Received: (from narten@localhost) by rotala.raleigh.ibm.com (8.14.1/8.14.1/Submit) id l954r2kj021386 for ietf@ietf.org; Fri, 5 Oct 2007 00:53:02 -0400 Date: Fri, 5 Oct 2007 00:53:02 -0400 From: Thomas Narten Message-Id: <200710050453.l954r2kj021386@rotala.raleigh.ibm.com> To: ietf@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: Weekly posting summary for ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Total of 149 messages in the last 7 days. script run at: Fri Oct 5 00:53:02 EDT 2007 Messages | Bytes | Who --------+------+--------+----------+------------------------ 7.38% | 11 | 6.12% | 53001 | moore@cs.utk.edu 5.37% | 8 | 5.56% | 48115 | mark_andrews@isc.org 4.70% | 7 | 5.46% | 47258 | pbaker@verisign.com 2.01% | 3 | 7.79% | 67389 | tgondrom@opentext.com 4.70% | 7 | 4.84% | 41929 | brian.e.carpenter@gmail.com 4.70% | 7 | 4.37% | 37830 | danny@tcb.net 3.36% | 5 | 3.51% | 30391 | fred@cisco.com 3.36% | 5 | 2.73% | 23667 | bortzmeyer@nic.fr 3.36% | 5 | 2.18% | 18856 | itojun@itojun.org 2.68% | 4 | 2.79% | 24102 | plzak@arin.net 2.68% | 4 | 2.50% | 21602 | mat@cisco.com 2.68% | 4 | 2.27% | 19684 | dhc2@dcrocker.net 2.68% | 4 | 1.97% | 17077 | hartmans-ietf@mit.edu 2.68% | 4 | 1.93% | 16669 | johnl@iecc.com 2.01% | 3 | 1.82% | 15774 | paul.hoffman@vpnc.org 0.67% | 1 | 3.01% | 26031 | elisa.boschi@hitachi-eu.com 2.01% | 3 | 1.65% | 14290 | jabley@ca.afilias.info 2.01% | 3 | 1.43% | 12336 | paul@xelerance.com 1.34% | 2 | 1.65% | 14297 | ekr@networkresonance.com 1.34% | 2 | 1.31% | 11350 | rdroms@cisco.com 1.34% | 2 | 1.23% | 10631 | nicolas.williams@sun.com 1.34% | 2 | 1.20% | 10396 | sm@resistor.net 1.34% | 2 | 1.20% | 10390 | dotis@mail-abuse.org 1.34% | 2 | 1.19% | 10278 | jhutz@cmu.edu 1.34% | 2 | 1.17% | 10096 | jnc@mercury.lcs.mit.edu 1.34% | 2 | 1.14% | 9853 | tjc@ecs.soton.ac.uk 1.34% | 2 | 1.12% | 9733 | iljitsch@muada.com 1.34% | 2 | 1.10% | 9532 | pekkas@netcore.fi 1.34% | 2 | 1.06% | 9198 | ruri@bugest.net 1.34% | 2 | 1.05% | 9098 | simon.leinen@switch.ch 1.34% | 2 | 0.95% | 8231 | carlberg@g11.org.uk 1.34% | 2 | 0.92% | 8004 | michel@arneill-py.sacramento.ca.us 0.67% | 1 | 1.19% | 10320 | marc@let.de 0.67% | 1 | 1.05% | 9067 | ldondeti@qualcomm.com 0.67% | 1 | 0.90% | 7816 | narten@us.ibm.com 0.67% | 1 | 0.82% | 7110 | olaf@nlnetlabs.nl 0.67% | 1 | 0.81% | 7018 | john-ietf@jck.com 0.67% | 1 | 0.80% | 6910 | ned.freed@mrochek.com 0.67% | 1 | 0.78% | 6754 | jeanjour@comcast.net 0.67% | 1 | 0.76% | 6604 | jordi.palet@consulintel.es 0.67% | 1 | 0.74% | 6421 | clint.chaplin@gmail.com 0.67% | 1 | 0.71% | 6161 | philemon@drtvnet.cg 0.67% | 1 | 0.71% | 6112 | stephen@sprunk.org 0.67% | 1 | 0.67% | 5803 | michael.dillon@bt.com 0.67% | 1 | 0.66% | 5685 | bonnie.l.gorsic@boeing.com 0.67% | 1 | 0.66% | 5672 | aboba@internaut.com 0.67% | 1 | 0.65% | 5627 | arifumi@nttv6.net 0.67% | 1 | 0.63% | 5444 | ole@cisco.com 0.67% | 1 | 0.63% | 5416 | tony@att.com 0.67% | 1 | 0.63% | 5410 | remi.denis-courmont@nokia.com 0.67% | 1 | 0.62% | 5324 | donald.eastlake@motorola.com 0.67% | 1 | 0.61% | 5301 | hecker@wave-storm.com 0.67% | 1 | 0.59% | 5129 | scott@kitterman.com 0.67% | 1 | 0.59% | 5123 | jari.arkko@piuha.net 0.67% | 1 | 0.57% | 4917 | tme@multicasttech.com 0.67% | 1 | 0.54% | 4660 | dcrocker@bbiw.net 0.67% | 1 | 0.54% | 4630 | ic56@rogers.com 0.67% | 1 | 0.52% | 4531 | joao_damas@isc.org 0.67% | 1 | 0.51% | 4392 | jtk@northwestern.edu 0.67% | 1 | 0.51% | 4388 | hardie@qualcomm.com 0.67% | 1 | 0.51% | 4382 | spencer@mcsr-labs.org 0.67% | 1 | 0.50% | 4336 | hiromi@inetcore.com 0.67% | 1 | 0.49% | 4248 | drc@virtualized.org 0.67% | 1 | 0.45% | 3854 | housley@vigilsec.com 0.67% | 1 | 0.44% | 3765 | jaap@nlnetlabs.nl --------+------+--------+----------+------------------------ 100.00% | 149 |100.00% | 865418 | Total _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 05 01:01:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idexi-0002XD-2C; Fri, 05 Oct 2007 00:38:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idexg-0002Vx-Lg for ietf@ietf.org; Fri, 05 Oct 2007 00:38:52 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idexc-0006jB-Bd for ietf@ietf.org; Fri, 05 Oct 2007 00:38:52 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 4 Oct 2007 21:38:59 -0700 Message-ID: In-Reply-To: <6D69802F-F58D-4149-A827-1ECD927675B3@wave-storm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv4 to IPv6 transition Thread-Index: AcgGs6DYqyR73VlnTQ+YRfsebFw9aQAR628g References: <470527DE.8010506@cs.utk.edu> <6D69802F-F58D-4149-A827-1ECD927675B3@wave-storm.com> From: "Michel Py" Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idexi-0002XD-2C; Fri, 05 Oct 2007 00:38:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idexg-0002Vx-Lg for ietf@ietf.org; Fri, 05 Oct 2007 00:38:52 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idexc-0006jB-Bd for ietf@ietf.org; Fri, 05 Oct 2007 00:38:52 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 4 Oct 2007 21:38:59 -0700 Message-ID: In-Reply-To: <6D69802F-F58D-4149-A827-1ECD927675B3@wave-storm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv4 to IPv6 transition Thread-Index: AcgGs6DYqyR73VlnTQ+YRfsebFw9aQAR628g References: <470527DE.8010506@cs.utk.edu> <6D69802F-F58D-4149-A827-1ECD927675B3@wave-storm.com> From: "Michel Py" To: "IETF Discussion" X-Spam-Score: 1.0 (+) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Subject: RE: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>> Michel Py wrote: >>> Each time I see one of these "days remaining before >>> Armageddon" counters, I can't help but remember what >>> happened on January 1, 2000: nothing. >> Keith Moore wrote: >> yes, but that's because people heeded the warnings, and prepared. if >> the same thing happens wrt IPv4 exhaustion, that will be fabulous. FUD. Nothing is going to happen the day the last v4 block is allocated. Nothing is going to happen for days. Nothing is going to happen for weeks. Nothing is going to happen for months. Contrary to Y2K, when it was conceivable (and did happen, at a very small scale) that something would crash because a counter rolled to "00" because the software written 20 years before did not plan for it, what will happen the day IPv4 is exhausted is zip, nada, nothing. Some obscure player will not get addresses, the business will go instead to an established player who has feasted on IPv4 for years and has built both fat and a respectable stockpile in their cellar, and the world will continue to spin. > Artur Hecker wrote: > No doubt - that nicely paid off our profession so > we should not > complain :-) :-D > indeed, given billions of USD and EUR spent on that issue, one > could reasonably argue that the issue was overblown and ask to > which degree this statement is true and what would have actually > happened without all the pressure. Indeed. I mostly agree with the Phillip Hallam-Baker's post later on. > Does anybody have any established and sustained opinion on that > and could provide verifiable if not objective data? How many > critical bugs were really found in typical systems? We will never know that. There were scores of people who billed tons of money to take care of it; you don't expect that they will admit to spending all this time finding nothing, would you? But on the other end, most of the Y2K audit teams were internal so they kept their dirty laundry in the family. In the end, it does not matter. Y2K was about compliance, and compliance is about making sure it fits the requirements checklist, which means it's defendable in court, and does not mean it actually works. > What would have been the real impact? What could have > happened in terms of impact (meaning: it would definitely > have happened, not the what-if analysis)? Nobody will ever know that either. What could have happened if the dinosaurs were not extinct? What could have happened if we did not drop a nuke on Japan to end the war? What could have happened if the Germans got a nuke before we did? What could have happened if the soviets beat us to the moon? What could have happened if John Kennedy was not assassinated? What could have happened if the telephone was not invented? > Was the cost higher than the estimated risk? Nobody will ever know that either, but one thing is sure: it would have been a lot cheaper without the legal liability buffalo dung that was associated with it. > Phillip Hallam-Baker wrote: > The first was the Y2K vampire who consultant-like turned every victim > into a new source of infection. The first thing a Y2K vampire would do > on claiming a new victim was to send out letters to every supplier > demanding to know if their systems have passed a Y2K audit. Thus the > poison spread at exponential speed. This is no different than a pyramid scheme or a virus: the only way out is full speed ahead and hope that you will not be part of the casualties. > We have to think like maramento.ca.us> To: "IETF Discussion" X-Spam-Score: 1.0 (+) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Subject: RE: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>> Michel Py wrote: >>> Each time I see one of these "days remaining before >>> Armageddon" counters, I can't help but remember what >>> happened on January 1, 2000: nothing. >> Keith Moore wrote: >> yes, but that's because people heeded the warnings, and prepared. if >> the same thing happens wrt IPv4 exhaustion, that will be fabulous. FUD. Nothing is going to happen the day the last v4 block is allocated. Nothing is going to happen for days. Nothing is going to happen for weeks. Nothing is going to happen for months. Contrary to Y2K, when it was conceivable (and did happen, at a very small scale) that something would crash because a counter rolled to "00" because the software written 20 years before did not plan for it, what will happen the day IPv4 is exhausted is zip, nada, nothing. Some obscure player will not get addresses, the business will go instead to an established player who has feasted on IPv4 for years and has built both fat and a respectable stockpile in their cellar, and the world will continue to spin. > Artur Hecker wrote: > No doubt - that nicely paid off our profession so > we should not > complain :-) :-D > indeed, given billions of USD and EUR spent on that issue, one > could reasonably argue that the issue was overblown and ask to > which degree this statement is true and what would have actually > happened without all the pressure. Indeed. I mostly agree with the Phillip Hallam-Baker's post later on. > Does anybody have any established and sustained opinion on that > and could provide verifiable if not objective data? How many > critical bugs were really found in typical systems? We will never know that. There were scores of people who billed tons of money to take care of it; you don't expect that they will admit to spending all this time finding nothing, would you? But on the other end, most of the Y2K audit teams were internal so they kept their dirty laundry in the family. In the end, it does not matter. Y2K was about compliance, and compliance is about making sure it fits the requirements checklist, which means it's defendable in court, and does not mean it actually works. > What would have been the real impact? What could have > happened in terms of impact (meaning: it would definitely > have happened, not the what-if analysis)? Nobody will ever know that either. What could have happened if the dinosaurs were not extinct? What could have happened if we did not drop a nuke on Japan to end the war? What could have happened if the Germans got a nuke before we did? What could have happened if the soviets beat us to the moon? What could have happened if John Kennedy was not assassinated? What could have happened if the telephone was not invented? > Was the cost higher than the estimated risk? Nobody will ever know that either, but one thing is sure: it would have been a lot cheaper without the legal liability buffalo dung that was associated with it. > Phillip Hallam-Baker wrote: > The first was the Y2K vampire who consultant-like turned every victim > into a new source of infection. The first thing a Y2K vampire would do > on claiming a new victim was to send out letters to every supplier > demanding to know if their systems have passed a Y2K audit. Thus the > poison spread at exponential speed. This is no different than a pyramid scheme or a virus: the only way out is full speed ahead and hope that you will not be part of the casualties. > We have to think like marketting people. Phillip, although I agree with the rest of your post, I am not sure about this part. One of the IPv6 problems is that it was sold by marketing before engineers could actually make it work. Remember all these miraculous features: small DFZ, easy renumbering, etc? Tell me where these features are today besides the imagination of marketing-minded people who sold them before making sure that they could actually be delivered. Two things happened along the road: First, as you have explained, people realized that the Y2K FUD was overblown and are not willing to spend the same money on IPv6. Second, the dot-com bubble burst, and the IPv6 forklift upgrade that could have been financed by all this capital money pouring from the sky did not take off. IPv6: sold by marketing before the concept was even proven. Designed by protocol purity zealots who can't make it cheap enough to be economically deployable. It reminds me of the Concorde supersonic aircraft: it could have been a success if the supersonic boom could be suppressed and if the price of oil did not skyrocket. A few were built and were operated with much hype on a confidential scale for many years. Where can you see one today? In a museum. Michel. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ketting people. Phillip, although I agree with the rest of your post, I am not sure about this part. One of the IPv6 problems is that it was sold by marketing before engineers could actually make it work. Remember all these miraculous features: small DFZ, easy renumbering, etc? Tell me where these features are today besides the imagination of marketing-minded people who sold them before making sure that they could actually be delivered. Two things happened along the road: First, as you have explained, people realized that the Y2K FUD was overblown and are not willing to spend the same money on IPv6. Second, the dot-com bubble burst, and the IPv6 forklift upgrade that could have been financed by all this capital money pouring from the sky did not take off. IPv6: sold by marketing before the concept was even proven. Designed by protocol purity zealots who can't make it cheap enough to be economically deployable. It reminds me of the Concorde supersonic aircraft: it could have been a success if the supersonic boom could be suppressed and if the price of oil did not skyrocket. A few were built and were operated with much hype on a confidential scale for many years. Where can you see one today? In a museum. Michel. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 05 01:23:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdfVK-0006Vw-GE; Fri, 05 Oct 2007 01:13:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdfVI-0006R2-ID for ietf@ietf.org; Fri, 05 Oct 2007 01:13:36 -0400 Received: from harry.mail-abuse.org ([168.61.5.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdfVF-000629-2a for ietf@ietf.org; Fri, 05 Oct 2007 01:13:33 -0400 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 19EBA414DF; Thu, 4 Oct 2007 22:13:32 -0700 (PDT) In-Reply-To: <4705845F.10809@cs.utk.edu> References: <2788466ED3E31C418E9ACC5C31661557053529@mou1wnexmb09.vcorp.ad.vrsn.com> <4705414B.5000109@cs.utk.edu> <4705471D.3060102@cisco.com> <47055293.4080200@cs.utk.edu> <47056CCC.1060803@cisco.com> <4705845F.10809@cs.utk.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1536631E-A7F4-402A-B913-7AD491A50F35@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Date: Thu, 4 Oct 2007 22:13:28 -0700 To: Keith Moore X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Michael Thomas , Fred Baker , ietf@ietf.org Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 4, 2007, at 5:25 PM, Keith Moore wrote: > >> I guess I must have been in the bar when they had that pledge of >> allegiance. But even allowing that there is any such pledge, to >> the degree that we enable domains to control who uses their name >> and be accountable when they behave badly is certainly a net good >> thing IMO. > > domains don't behave well or badly. they're just names. and I > don't think it's in the internet's interest to require people to > associate themselves with what is essentially a brand name in order > to be heard. using DKIM for spam filtering pretty much does that. DKIM might ensure a message, about to be dropped, generates a non- delivery notification instead. With extensions to DKIM, such as TPA- SSP, even email-addresses within different domains from those used for DKIM signing could make assurances. When a message hits a snag, TPA-SSP offers assurances that the domain in question is not being spoofed. TPA-SSP is extensible and allows a user to associate their email domain with any number of DKIM signing domains. Individuals may be where TPA-SSP finds support. TPA-SSP also allows sub-domains differentiate signing policies. Secure use of sub- domains and Third-Party domains might be a feature corporations put to good use as well. The TPA-SSP mechanism allows principal domains to sign transactional emails and yet safely permit employees to send to mailing lists that also sign with DKIM. DKIM can be very flexible. However, the DKIM cryptographic process may place a sizeable burden upon receivers, especially when spam is in excess of 99%. -Doug _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 05 07:43:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdlDI-0007g7-Tr; Fri, 05 Oct 2007 07:19:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdlDA-0007XF-NA; Fri, 05 Oct 2007 07:19:16 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdlD9-0000EA-5x; Fri, 05 Oct 2007 07:19:16 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 5 Oct 2007 12:19:12 +0100 Message-ID: <47061D7C.5080808@isode.com> Date: Fri, 05 Oct 2007 12:18:20 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Eric Rescorla References: <20071004222812.7BE7933C21@delta.rtfm.com> In-Reply-To: <20071004222812.7BE7933C21@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Cc: lemonade@ietf.org, iesg@ietf.org, Dave Cridland , ietf@ietf.org, secdir@ietf.org Subject: Re: Comments on draft-ietf-lemonade-reconnect-client-06 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi Eric, Thank you for your comments. (Today is about the worst time for me to reply to your comments, as I am going on holidays tomorrow.) Eric Rescorla wrote: >$Id: draft-ietf-lemonade-reconnect-client-06-rev.txt,v 1.1 2007/10/04 22:25:53 ekr Exp $ > > >OVERALL >This document describes an extension to IMAP to provide faster >synchronization between client and server. As far as I can >tell, the optimizations are: > >- Removing one round trip needed to discover which messages > have been expunged. > > Yes, if compared to the case when the client/server also implement the CONDSTORE extension (RFC 4551). (Actually it removed 2 round trips per mailbox synchronization.) When compared to RFC 3501, this extension can potentially provides huge bandwidth saving. If a client wants to synchronize flag changes in a mailbox, the client needs to fetch flags for *all* mailboxes. For a 30,000 message mailbox that I currently have is quite painful over a slow link. >- A more compact representation of the list of expunged > messages > > Correct. >I have some skepticism about the importance of these optimizations. > > See above. >The document does not come with any performance measurements, >and 1 RTT really isn't that much. In particular, I wonder if >VANISHED really saves that much bandwidth over EXPUNGED if >compression is in use. I don't know what standard is being >used to decide whether optimizations of this type are worthwhile. > > I will let Dave comment on this. Just a couple of extra comments: 1). As I mentioned above, this extension saves 2 round trips per mailbox synchronization. A user might have multiple mailboxes. 2). This is mostly useful for mobile clients which can experience frequent connection loss. >I found this document fairly hard to read. I understand that it's >a delta to IMAP and requires quite a bit of knowledge of IMAP >to understand, but I think it could have been written to be >more clear about how it changes IMAP's behavior in each case. >In particular, the examples would be improved by always >having New and Old and having some sort of indicator of exactly >which PDUs have changed and why. > > Right. >DETAILED COMMENTS >S 2. >This would be improved by some overall diagram of the new and >old behavior and some measurement, even an ad hoc one, of >the performance improvement. > > Ok. An older version of this document had some numbers, but people complained about "irrelevant text". See section 2.1 of (Note that the protocol has changed substantially since, but the basic observation is still correct.) >S 3.1. > > Conceptually, the client provides a small sample of sequence numbers > for which it knows the corresponding UIDs. The server then compares > each sequence number and UID pair the client provides with the > current state of the mailbox. If a pair matches, then the client > knows of any expunges up to, and including, the message, and thus > will not include that range in the VANISHED response, even if the > "mod-sequence-value" provided by the client is too old for the server > to have data of when those messages were expunged. > >This is probably my ignorance of IMAP, but how can this happen? Why >doesn't the client have a mod-sequence-value corresponds to these >UIDs? > > I will let Dave explain this. > S: * VANISHED (EARLIER) 1:2,4:5,7:8,10:11,13:14 [...] > 29998:29999,30001:30002,30004:30005,30007:30008 > >This [...] hides the data you're optimizing away, right? This >would help if it were called out more clearly. > > Yes. I will add a sentence on this. >S 3.3, 3.4, 3.5. >These would all benefit from a statement of how they differ from >3501, rather than just stating new rules. > > (Actually, 3.5 updates UID EXPUNGE which was defined in RFC 4315.) Right. I believe some people wanted to see sections replacing the old definitions, as opposed to just pointing out the difference from RFC 3501. The following text in section 2 summarizes the difference: This document puts additional requirements on a server implementing the [CONDSTORE] extension. Each mailbox that supports persistent storage of mod-sequences, i.e., for which the server has sent a HIGHESTMODSEQ untagged OK response code on a successful SELECT/ EXAMINE, MUST increment the per-mailbox mod-sequence when one or more messages are expunged due to EXPUNGE, UID EXPUNGE or CLOSE; the server MUST associate the incremented mod-sequence with the UIDs of the expunged messages. I can try to add a sentence to each one of 3.3, 3.4 and 3.5 to clarify that. > If the server is capable of storing modification sequences for the > selected mailbox, it MUST increment the per-mailbox mod-sequence if > at least one message was permanently removed due to the execution of > the EXPUNGE command. For each permanently removed message the server > MUST remember the incremented mod-sequence and corresponding UID. If > at least one message got expunged, the server MUST send the updated > per-mailbox modification sequence using the HIGHESTMODSEQ response > code (defined in [CONDSTORE]) in the tagged OK response. > >So, this is repeated in all three sections. That seems less than >optimal. > >Rather than refing 3501, it would probably be good to point out >why the message #s are as they are in these examples, due to >auto-decrement. > > I've added a clarifying sentence to sections 3.3 and 3.5. I don't think section 3.4 needs to change. >S 3.6. > The VANISHED response has two forms. The first form contains the > EARLIER tag, which signifies that the response was caused by a UID > FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command. This > response is sent if the UID set parameter to the UID FETCH (VANISHED) > command includes UIDs of messages that are no longer in the mailbox. > When the client sees a VANISHED EARLIER response it MUST NOT > decrement message sequence numbers for each successive message in the > mailbox. > > The second form doesn't contain the EARLIER tag and is described > below. Once a client has used "(VANISHED)" with a UID FETCH or > "(QRESYNC)" with SELECT/EXAMINE command, the server SHOULD use the > VANISHED response without the EARLIER tag instead of the EXPUNGE > response. The server SHOULD continue using VANISHED in lieu of > EXPUNGE for the duration of the connection. In particular this > affects the EXPUNGE [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as > well as messages expunged in other connections. Such VANISHED > response MUST NOT contain the EARLIER tag. > >This is pretty unclear to the non-IMAP expert. Could you explain >in english what this is trying to accomplish in the document, >not just specify the protocol mechanics. > > Basically the VANISHED response is used for 2 purposes: to report UIDs of messages expunged earlier and to report UIDs of messages expunged now. The difference between the two is that in the former case the client doesn't need to decrement the number of messages in the mailbox, while in the latter case it must. The former can be distinguished from the latter by presence of the "(EARLIER)" label. >In the example, swap before and after. Also, it would be good >to show an example of (EARLIER). > > Ok. >S 4.1. > Strictly speaking, a server implementation that doesn't remember > modsequences associated with expunged messages can be considered > compliant with this specification. Such implementations return all > expunged messages specified in the UID set of the UID FETCH > (VANISHED) command every time, without paying attention to the > specified CHANGEDSINCE modsequence. Such implementations are > discouraged, as they can end up returning VANISHED responses bigger > than the result of a UID SEARCH command for the same UID set. > >Isn't this inconsistent with: > > If the server is capable of storing modification sequences for the > selected mailbox, it MUST increment the per-mailbox mod-sequence if > at least one message was permanently removed due to the execution of > the EXPUNGE command. For each permanently removed message the server > MUST remember the incremented mod-sequence and corresponding UID. If > at least one message got expunged, the server MUST send the updated > per-mailbox modification sequence using the HIGHESTMODSEQ response > code (defined in [CONDSTORE]) in the tagged OK response. > >If not, why not? > > No, there is no inconsistency: "a server implementation that doesn't remember modsequences" == "a server is incapable of storing modsequences". The second paragraph you quoted is conditional on server's ability to store modsequences. This behaviour is optional for servers. >S 5. > The client MUST also take note of any MODSEQ FETCH data items > received from the server. Whenever the client receives a tagged > response to a command, it calculates the highest value among all > MODSEQ FETCH data items received since the last tagged response. If > this value is bigger than the client's copy of the HIGHESTMODSEQ > value, then the client MUST use this value as its new HIGHESTMODSEQ > value. > >So, I probably misunderstand something, but my read of 4551 made >it seem like you could do a MODSEQ FETCH that would not return >all the metadata for every message. > Yes, if the client issues a FETCH MODSEQ for a subset of messages. However the previous paragraph in the same section requires the client to perform a full synchronization. >In that case, wouldn't this >procedure risk you having a modseq that is higher than some >messages you haven't examined yet? What am I missing. > > The intent of this paragraph is to talk about unsolicited FETCH MODSEQ returned by the server *after* a full synchronization is complete (the previous paragraph in the same section). So the situation you describe can't happen, because the server is required to send all unsolicited FETCH MODSEQ responses. The beginning of this paragraph is ambiguous, so I suggest that it should be clarified by changing the first quoted sentence to read: After completing full synchronization, the client MUST also take note of any MODSEQ FETCH data items received from the server. >I don't see any new security issues in this document. > > Regards, Alexey _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 05 11:16:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdopD-0005Jn-Dv; Fri, 05 Oct 2007 11:10:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdopA-0005FF-GD; Fri, 05 Oct 2007 11:10:44 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idop3-0000Ur-2r; Fri, 05 Oct 2007 11:10:42 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id l95FAR6Z004709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2007 08:10:27 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id l95FAP4S013851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Oct 2007 08:10:26 -0700 Date: Fri, 5 Oct 2007 08:10:23 -0700 (PDT) From: Mark Crispin To: Eric Rescorla In-Reply-To: <20071005145321.F200933C21@delta.rtfm.com> Message-ID: References: <20071004222812.7BE7933C21@delta.rtfm.com> <47061D7C.5080808@isode.com> <20071005145321.F200933C21@delta.rtfm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.10.5.74657 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__C230066_P2 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ietf@ietf.org, secdir@ietf.org, lemonade@ietf.org, iesg@ietf.org, Dave Cridland , Alexey Melnikov Subject: Re: [lemonade] Re: Comments on draft-ietf-lemonade-reconnect-client-06 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Fri, 5 Oct 2007, Eric Rescorla wrote: >> When compared to RFC 3501, this extension can potentially provides huge >> bandwidth saving. If a client wants to synchronize flag changes in a >> mailbox, the client needs to fetch flags for *all* mailboxes. For a >> 30,000 message mailbox that I currently have is quite painful over a >> slow link. > I don't think it makes sense to compare this to 3501 without 4551, > since 4551 is already an RFC. The question is whether this document > should be advanced. What's the optimization compared > to 4551? Also, you say it's "quite painful" now. How much less > painful is it with this document. How about if compression is > used. This seems like something > where measurements would be nice. +1. Assuming that a typical FLAGS response is about 40 octets, then fetching all flags is 1,200,000 octets. This may be a bit slow over a 2.5G wireless network, but "quite painful" overstates the case somewhat. Also, this is only an issue for "disconnected" clients that insist upon synchronizing a local copy with the server. True "online" clients don't have this issue, and don't care about flags in messages that the user isn't viewing. Being an online client kind of guy, I see the problem as a flaw in the disconnected client model, especially as the whole idea of reconnect seems to be to make disconnected have similar real-time characteristics as online. I sympathize, but only to aFrom ietf-bounces@ietf.org Fri Oct 05 11:16:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdopD-0005Jn-Dv; Fri, 05 Oct 2007 11:10:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdopA-0005FF-GD; Fri, 05 Oct 2007 11:10:44 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idop3-0000Ur-2r; Fri, 05 Oct 2007 11:10:42 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id l95FAR6Z004709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2007 08:10:27 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id l95FAP4S013851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Oct 2007 08:10:26 -0700 Date: Fri, 5 Oct 2007 08:10:23 -0700 (PDT) From: Mark Crispin To: Eric Rescorla In-Reply-To: <20071005145321.F200933C21@delta.rtfm.com> Message-ID: References: <20071004222812.7BE7933C21@delta.rtfm.com> <47061D7C.5080808@isode.com> <20071005145321.F200933C21@delta.rtfm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.10.5.74657 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__C230066_P2 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ietf@ietf.org, secdir@ietf.org, lemonade@ietf.org, iesg@ietf.org, Dave Cridland , Alexey Melnikov Subject: Re: [lemonade] Re: Comments on draft-ietf-lemonade-reconnect-client-06 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Fri, 5 Oct 2007, Eric Rescorla wrote: >> When compared to RFC 3501, this extension can potentially provides huge >> bandwidth saving. If a client wants to synchronize flag changes in a >> mailbox, the client needs to fetch flags for *all* mailboxes. For a >> 30,000 message mailbox that I currently have is quite painful over a >> slow link. > I don't think it makes sense to compare this to 3501 without 4551, > since 4551 is already an RFC. The question is whether this document > should be advanced. What's the optimization compared > to 4551? Also, you say it's "quite painful" now. How much less > painful is it with this document. How about if compression is > used. This seems like something > where measurements would be nice. +1. Assuming that a typical FLAGS response is about 40 octets, then fetching all flags is 1,200,000 octets. This may be a bit slow over a 2.5G wireless network, but "quite painful" overstates the case somewhat. Also, this is only an issue for "disconnected" clients that insist upon synchronizing a local copy with the server. True "online" clients don't have this issue, and don't care about flags in messages that the user isn't viewing. Being an online client kind of guy, I see the problem as a flaw in the disconnected client model, especially as the whole idea of reconnect seems to be to make disconnected have similar real-time characteristics as online. I sympathize, but only to a limited degree. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 05 11:16:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdocO-0004Fk-1V; Fri, 05 Oct 2007 10:57:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdocL-0004Ay-1b; Fri, 05 Oct 2007 10:57:29 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdocE-0007rS-Ux; Fri, 05 Oct 2007 10:57:23 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id F200933C21; Fri, 5 Oct 2007 07:53:21 -0700 (PDT) Date: Fri, 05 Oct 2007 07:53:21 -0700 From: Eric Rescorla To: Alexey Melnikov In-Reply-To: <47061D7C.5080808@isode.com> References: <20071004222812.7BE7933C21@delta.rtfm.com> <47061D7C.5080808@isode.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071005145321.F200933C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: ietf@ietf.org, secdir@ietf.org, lemonade@ietf.org, iesg@ietf.org, Dave Cridland Subject: Re: Comments on draft-ietf-lemonade-reconnect-client-06 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At Fri, 05 Oct 2007 12:18:20 +0100, Alexey Melnikov wrote: > > Hi Eric, > Thank you for your comments. > > (Today is about the worst time for me to reply to your comments, as I am > going on holidays tomorrow.) > > Eric Rescorla wrote: > > >$Id: draft-ietf-lemonade-reconnect-client-06-rev.txt,v 1.1 2007/10/04 22:25:53 ekr Exp $ > > > > > >OVERALL > >This document describes an extension to IMAP to provide faster > >synchronization between client and server. As far as I can > >tell, the optimizations are: > > > >- Removing one round trip needed to discover which messages > > have been expunged. > > > > > Yes, if compared to the case when the client/server also implement the > CONDSTORE extension (RFC 4551). > (Actually it removed 2 round trips per mailbox synchronization.) > > When compared to RFC 3501, this extension can potentially provides huge > bandwidth saving. If a client wants to synchronize flag changes in a > mailbox, the client needs to fetch flags for *all* mailboxes. For a > 30,000 message mailbox that I currently have is quite painful over a > slow link. I don't think it makes sense to compare this to 3501 without 4551, since 4551 is already an RFC. The question is whether this document should be advanced. What's the optimization compared to 4551? Also, you say it's "quite painful" now. How much less painful is it with this document. How about if compression is used. This seems like something where measurements would be nice. > >DETAILED COMMENTS > >S 2. > >This would be improved by some overall diagram of the new and > >old behavior and some measurement, even an ad hoc one, of > >the performance improvement. > > > > > Ok. An older version of this document had some numbers, but people > complained about "irrelevant text". Maybe I'm missing something, but those comparisons are to 3501, not CONDSTORE, right? > >S 3.3, limited degree. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 05 11:16:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdocO-0004Fk-1V; Fri, 05 Oct 2007 10:57:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdocL-0004Ay-1b; Fri, 05 Oct 2007 10:57:29 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdocE-0007rS-Ux; Fri, 05 Oct 2007 10:57:23 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id F200933C21; Fri, 5 Oct 2007 07:53:21 -0700 (PDT) Date: Fri, 05 Oct 2007 07:53:21 -0700 From: Eric Rescorla To: Alexey Melnikov In-Reply-To: <47061D7C.5080808@isode.com> References: <20071004222812.7BE7933C21@delta.rtfm.com> <47061D7C.5080808@isode.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071005145321.F200933C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: ietf@ietf.org, secdir@ietf.org, lemonade@ietf.org, iesg@ietf.org, Dave Cridland Subject: Re: Comments on draft-ietf-lemonade-reconnect-client-06 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At Fri, 05 Oct 2007 12:18:20 +0100, Alexey Melnikov wrote: > > Hi Eric, > Thank you for your comments. > > (Today is about the worst time for me to reply to your comments, as I am > going on holidays tomorrow.) > > Eric Rescorla wrote: > > >$Id: draft-ietf-lemonade-reconnect-client-06-rev.txt,v 1.1 2007/10/04 22:25:53 ekr Exp $ > > > > > >OVERALL > >This document describes an extension to IMAP to provide faster > >synchronization between client and server. As far as I can > >tell, the optimizations are: > > > >- Removing one round trip needed to discover which messages > > have been expunged. > > > > > Yes, if compared to the case when the client/server also implement the > CONDSTORE extension (RFC 4551). > (Actually it removed 2 round trips per mailbox synchronization.) > > When compared to RFC 3501, this extension can potentially provides huge > bandwidth saving. If a client wants to synchronize flag changes in a > mailbox, the client needs to fetch flags for *all* mailboxes. For a > 30,000 message mailbox that I currently have is quite painful over a > slow link. I don't think it makes sense to compare this to 3501 without 4551, since 4551 is already an RFC. The question is whether this document should be advanced. What's the optimization compared to 4551? Also, you say it's "quite painful" now. How much less painful is it with this document. How about if compression is used. This seems like something where measurements would be nice. > >DETAILED COMMENTS > >S 2. > >This would be improved by some overall diagram of the new and > >old behavior and some measurement, even an ad hoc one, of > >the performance improvement. > > > > > Ok. An older version of this document had some numbers, but people > complained about "irrelevant text". Maybe I'm missing something, but those comparisons are to 3501, not CONDSTORE, right? > >S 3.3, 3.4, 3.5. > >These would all benefit from a statement of how they differ from > >3501, rather than just stating new rules. > > > > > (Actually, 3.5 updates UID EXPUNGE which was defined in RFC 4315.) > > Right. I believe some people wanted to see sections replacing the old > definitions, as opposed to just pointing out the difference from RFC 3501. As a wordsmithing issue, I would recommend adding a single clarificatory master section with these replacement definitions as subsections. > >S 3.6. > > The VANISHED response has two forms. The first form contains the > > EARLIER tag, which signifies that the response was caused by a UID > > FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command. This > > response is sent if the UID set parameter to the UID FETCH (VANISHED) > > command includes UIDs of messages that are no longer in the mailbox. > > When the client sees a VANISHED EARLIER response it MUST NOT > > decrement message sequence numbers for each successive message in the > > mailbox. > > > > The second form doesn't contain the EARLIER tag and is described > > below. Once a client has used "(VANISHED)" with a UID FETCH or > > "(QRESYNC)" with SELECT/EXAMINE command, the server SHOULD use the > > VANISHED response without the EARLIER tag instead of the EXPUNGE > > response. The server SHOULD continue using VANISHED in lieu of > > EXPUNGE for the duration of the connection. In particular this > > affects the EXPUNGE [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as > > well as messages expunged in other connections. Such VANISHED > > response MUST NOT contain the EARLIER tag. > > > >This is pretty unclear to the non-IMAP expert. Could you explain > >in english what this is trying to accomplish in the document, > >not just specify the protocol mechanics. > > > > > Basically the VANISHED response is used for 2 purposes: to report UIDs > of messages expunged earlier and to report UIDs of messages expunged now. > The difference between the two is that in the former case the client > doesn't need to decrement the number of messages in the mailbox, while > in the latter case it must. > The former can be distinguished from the latter by presence of the > "(EARLIER)" label. OK. That could be clearer in the main text. > >S 4.1. > > Strictly speaking, a server implementation that doesn't remember > > modsequences associated with expunged messages can be considered > > compliant with this specification. Such implementations return all > > expunged messages specified in the UID set of the UID FETCH > > (VANISHED) command every time, without paying attention to the > > specified CHANGEDSINCE modsequence. Such implementations are > > discouraged, as they can end up returning VANISHED responses bigger > > than the result of a UID SEARCH command for the same UID set. > > > >Isn't this inconsistent with: > > > > If the server is capable of storing modification sequences for the > > selected mailbox, it MUST increment the per-mailbox mod-sequence if > > at least one message was permanently removed due to the execution of > > the EXPUNGE command. For each permanently removed message the server > > MUST remember the incremented mod-sequence and corresponding UID. If > > at least one message got expunged, the server MUST send the updated > > per-mailbox modification sequence using the HIGHESTMODSEQ response > > code (defined in [CONDSTORE]) in the tagged OK response. > > > >If not, why not? > > > > > No, there is no inconsistency: > > "a server implementation that doesn't remember modsequences" == "a > server is incapable of storing modsequences". > The second paragraph you quoted is conditional on server's ability to > store modsequences. This behaviour is optional for servers. OK. I misread this. Thanks. > >S 5. > > The client MUST also take note of any MODSEQ FETCH data items > > received from the server. Whenever the client receives a tagged > > response to a command, it calculates the highest value among all > > MODSEQ FETCH data3.4, 3.5. > >These would all benefit from a statement of how they differ from > >3501, rather than just stating new rules. > > > > > (Actually, 3.5 updates UID EXPUNGE which was defined in RFC 4315.) > > Right. I believe some people wanted to see sections replacing the old > definitions, as opposed to just pointing out the difference from RFC 3501. As a wordsmithing issue, I would recommend adding a single clarificatory master section with these replacement definitions as subsections. > >S 3.6. > > The VANISHED response has two forms. The first form contains the > > EARLIER tag, which signifies that the response was caused by a UID > > FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command. This > > response is sent if the UID set parameter to the UID FETCH (VANISHED) > > command includes UIDs of messages that are no longer in the mailbox. > > When the client sees a VANISHED EARLIER response it MUST NOT > > decrement message sequence numbers for each successive message in the > > mailbox. > > > > The second form doesn't contain the EARLIER tag and is described > > below. Once a client has used "(VANISHED)" with a UID FETCH or > > "(QRESYNC)" with SELECT/EXAMINE command, the server SHOULD use the > > VANISHED response without the EARLIER tag instead of the EXPUNGE > > response. The server SHOULD continue using VANISHED in lieu of > > EXPUNGE for the duration of the connection. In particular this > > affects the EXPUNGE [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as > > well as messages expunged in other connections. Such VANISHED > > response MUST NOT contain the EARLIER tag. > > > >This is pretty unclear to the non-IMAP expert. Could you explain > >in english what this is trying to accomplish in the document, > >not just specify the protocol mechanics. > > > > > Basically the VANISHED response is used for 2 purposes: to report UIDs > of messages expunged earlier and to report UIDs of messages expunged now. > The difference between the two is that in the former case the client > doesn't need to decrement the number of messages in the mailbox, while > in the latter case it must. > The former can be distinguished from the latter by presence of the > "(EARLIER)" label. OK. That could be clearer in the main text. > >S 4.1. > > Strictly speaking, a server implementation that doesn't remember > > modsequences associated with expunged messages can be considered > > compliant with this specification. Such implementations return all > > expunged messages specified in the UID set of the UID FETCH > > (VANISHED) command every time, without paying attention to the > > specified CHANGEDSINCE modsequence. Such implementations are > > discouraged, as they can end up returning VANISHED responses bigger > > than the result of a UID SEARCH command for the same UID set. > > > >Isn't this inconsistent with: > > > > If the server is capable of storing modification sequences for the > > selected mailbox, it MUST increment the per-mailbox mod-sequence if > > at least one message was permanently removed due to the execution of > > the EXPUNGE command. For each permanently removed message the server > > MUST remember the incremented mod-sequence and corresponding UID. If > > at least one message got expunged, the server MUST send the updated > > per-mailbox modification sequence using the HIGHESTMODSEQ response > > code (defined in [CONDSTORE]) in the tagged OK response. > > > >If not, why not? > > > > > No, there is no inconsistency: > > "a server implementation that doesn't remember modsequences" == "a > server is incapable of storing modsequences". > The second paragraph you quoted is conditional on server's ability to > store modsequences. This behaviour is optional for servers. OK. I misread this. Thanks. > >S 5. > > The client MUST also take note of any MODSEQ FETCH data items > > received from the server. Whenever the client receives a tagged > > response to a command, it calculates the highest value among all > > MODSEQ FETCH data items received since the last tagged response. If > > this value is bigger than the client's copy of the HIGHESTMODSEQ > > value, then the client MUST use this value as its new HIGHESTMODSEQ > > value. > > > >So, I probably misunderstand something, but my read of 4551 made > >it seem like you could do a MODSEQ FETCH that would not return > >all the metadata for every message. > > > Yes, if the client issues a FETCH MODSEQ for a subset of messages. > However the previous paragraph in the same section requires the client > to perform a full synchronization. OK. > >In that case, wouldn't this > >procedure risk you having a modseq that is higher than some > >messages you haven't examined yet? What am I missing. > > > > > The intent of this paragraph is to talk about unsolicited FETCH MODSEQ > returned by the server *after* a full synchronization is complete (the > previous paragraph in the same section). So the situation you describe > can't happen, because the server is required to send all unsolicited > FETCH MODSEQ responses. > The beginning of this paragraph is ambiguous, so I suggest that it > should be clarified by changing the first quoted sentence to read: > > After completing full synchronization, the client MUST also take note of > any MODSEQ FETCH data items received from the server. WFM. -Ekr _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf items received since the last tagged response. If > > this value is bigger than the client's copy of the HIGHESTMODSEQ > > value, then the client MUST use this value as its new HIGHESTMODSEQ > > value. > > > >So, I probably misunderstand something, but my read of 4551 made > >it seem like you could do a MODSEQ FETCH that would not return > >all the metadata for every message. > > > Yes, if the client issues a FETCH MODSEQ for a subset of messages. > However the previous paragraph in the same section requires the client > to perform a full synchronization. OK. > >In that case, wouldn't this > >procedure risk you having a modseq that is higher than some > >messages you haven't examined yet? What am I missing. > > > > > The intent of this paragraph is to talk about unsolicited FETCH MODSEQ > returned by the server *after* a full synchronization is complete (the > previous paragraph in the same section). So the situation you describe > can't happen, because the server is required to send all unsolicited > FETCH MODSEQ responses. > The beginning of this paragraph is ambiguous, so I suggest that it > should be clarified by changing the first quoted sentence to read: > > After completing full synchronization, the client MUST also take note of > any MODSEQ FETCH data items received from the server. WFM. -Ekr _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 05 11:41:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdpBY-0007gV-5n; Fri, 05 Oct 2007 11:33:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXOq-0003kP-NY; Thu, 04 Oct 2007 16:34:24 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdXOq-0005Um-Go; Thu, 04 Oct 2007 16:34:24 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id DB4A8175DC; Thu, 4 Oct 2007 20:34:13 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IdXOf-0004ej-E3; Thu, 04 Oct 2007 16:34:13 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: IETF Announcement list From: The IESG Message-Id: Date: Thu, 04 Oct 2007 16:34:13 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-Mailman-Approved-At: Fri, 05 Oct 2007 11:33:49 -0400 Cc: ietf@ietf.org Subject: On Appeals of IESG and Area Director Actions and Decisions X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org The IESG re-affirms that its reading of RFC 2026 is that any action made by an Area Director or the IESG may by made the subject of the conflict resolution mechanisms set out in Section 6.5 of RFC 2026. The IESG further wishes to highlight that the primary aim of the appeals mechanism set out there is to resolve conflicts and move the IETF as a whole towards consensus, and it urges all participants to approach them in that light. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 05 12:56:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdqJN-0000Bg-Lq; Fri, 05 Oct 2007 12:46:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdqJK-0008Tv-RV for ietf@ietf.org; Fri, 05 Oct 2007 12:45:58 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdqJK-00035d-9s for ietf@ietf.org; Fri, 05 Oct 2007 12:45:58 -0400 Received: from [163.117.139.34] (nirrti.it.uc3m.es [163.117.139.34]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l95Ggjnp065530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Oct 2007 18:42:47 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <470527DE.8010506@cs.utk.edu> <6D69802F-F58D-4149-A827-1ECD927675B3@wave-storm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D2AFBEC-CEE1-435A-AE2C-E0591BAE91FE@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Fri, 5 Oct 2007 18:45:28 +0200 To: Michel Py X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, score=-1.7 required=3.5 tests=AWL,BAYES_00, ILJQX_SUBJ_NUMINWORD autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: IETF Discussion Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 5-okt-2007, at 6:38, Michel Py wrote: > Nothing is going to happen the day the last v4 block is allocated. > Nothing is going to happen for days. Nothing is going to happen for > weeks. Sure. > Nothing is going to happen for months. Not so sure. The big ISPs that work in blocks of a million or so addresses will be the first ones to see their requests turned down because addresses are out of stock. Presumably, they'll need those addresses to connect new customers. If you happen to request a new connection around that time you'll see an effect. >> Does anybody have any established and sustained opinion on that >> and could provide verifiable if not objective data? How many >> critical bugs were really found in typical systems? > We will never know that. There were scores of people who billed > tons of > money to take care of it; you don't expect that they will admit to > spending all this time finding nothing, would you? I think some pretty much have. I'm sure that if the Y2K issue had been ignored there'd been lots of problems with individual systems. The part that was unlikely (but not impossible) from the beginning were all the domino effects. A router won't stop routing if it is set to the wrong time of day. I'm pretty sure a plane won't stop flying, either. But in that particular case, "pretty sure" is not exactly good enough... _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 05 13:22:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdqlK-0002ZJ-Tm; Fri, 05 Oct 2007 13:14:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdqlH-0002TB-VG; Fri, 05 Oct 2007 13:14:51 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdqlB-0004lu-2Z; Fri, 05 Oct 2007 13:14:51 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 5 Oct 2007 18:14:32 +0100 Message-ID: <470670B0.3000603@isode.com> Date: Fri, 05 Oct 2007 18:13:20 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Eric Rescorla References: <20071004222812.7BE7933C21@delta.rtfm.com> <47061D7C.5080808@isode.com> <20071005145321.F200933C21@delta.rtfm.com> In-Reply-To: <20071005145321.F200933C21@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: lemonade@ietf.org, iesg@ietf.org, Dave Cridland , ietf@ietf.org, secdir@ietf.org Subject: Re: Comments on draft-ietf-lemonade-reconnect-client-06 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Eric Rescorla wrote: >At Fri, 05 Oct 2007 12:18:20 +0100, >Alexey Melnikov wrote: > > >>Hi Eric, >>Thank you for your comments. >> >>(Today is about the worst time for me to reply to your comments, as I am >>going on holidays tomorrow.) >> >>Eric Rescorla wrote: >> >>>$Id: draft-ietf-lemonade-reconnect-client-06-rev.txt,v 1.1 2007/10/04 22:25:53 ekr Exp $ >>> >>> >>>OVERALL >>>This document describes an extension to IMAP to provide faster >>>synchronization between client and server. As far as I can >>>tell, the optimizations are: >>> >>>- Removing one round trip needed to discover which messages >>> have been expunged. >>> >>> >>Yes, if compared to the case when the client/server also implement the >>CONDSTORE extension (RFC 4551). >>(Actually it removed 2 round trips per mailbox synchronization.) >> >>When compared to RFC 3501, this extension can potentially provides huge >>bandwidth saving. If a client wants to synchronize flag changes in a >>mailbox, the client needs to fetch flags for *all* mailboxes. For a >>30,000 message mailbox that I currently have is quite painful over a >>slow link. >> >I don't think it makes sense to compare this to 3501 without 4551, >since 4551 is already an RFC. The question is whether this document >should be advanced. What's the optimization compared >to 4551? > CONDSTORE can significantly reduce bandwidth in some cases. It doesn't reduce the number of roundtrips. QRESYNC reduces number of roundtrips when compared to CONDSTORE or base IMAP. It can also reduce bandwidth in some cases (on top of the bandwidth reduction given by CONDSTORE). >Also, you say it's "quite painful" now. How much less >painful is it with this document. How about if compression is >used. This seems like something where measurements would be nice. > Yes. Dave will answer this ;-). >>>DETAILED COMMENTS >>>S 2. >>>This would be improved by some overall diagram of the new and >>>old behavior and some measurement, even an ad hoc one, of >>>the performance improvement. >>> >>> >>Ok. An older version of this document had some numbers, but people >>complained about "irrelevant text". >> >Maybe I'm missing something, but those comparisons are to 3501, >not CONDSTORE, right? > > Yes. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 05 13:46:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idr4h-0001Jk-QZ; Fri, 05 Oct 2007 13:34:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idr4g-0001Jf-Dr for ietf@ietf.org; Fri, 05 Oct 2007 13:34:54 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idr4a-0005qX-4u for ietf@ietf.org; Fri, 05 Oct 2007 13:34:54 -0400 Received: from pc6 (1Cust179.tnt24.lnd4.gbr.da.uu.net [62.188.151.179]) by astro.systems.pipex.net (Postfix) with SMTP id 3C4BEE0000B0 for ; Fri, 5 Oct 2007 18:34:20 +0100 (BST) Message-ID: <09f601c8076c$a2211a80$0601a8c0@pc6> From: "Tom.Petch" To: "ietf" References: <2788466ED3E31C418E9ACC5C316615570462C0@mou1wnexmb09.vcorp.ad.vrsn.com> Date: Fri, 5 Oct 2007 18:26:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Tom.Petch" List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org ---- Original Message ----- From: "Clint Chaplin" To: Sent: Thursday, October 04, 2007 1:01 AM Subject: Re: Spammers answering TMDA Queries > I believe the term is "tmda", not "tdma". > Never mind how it is spelt, what is it? Something to do with e-mail, something associated with spam, something that may or may not affect my ability to participate with the 'IETF' now or in future. But what is it? An explanation for one not familiar with MX and mail list administration would be appreciated. Tom Petch PS no need to explain SPF, DKIM etc, those have been hammered enough on this list. > TDMA is a type of cell phone technology. > > On 10/3/07, Hallam-Baker, Phillip wrote: > > > > > > > > I don't see a problem if we eat our own dog food. > > > > The use of tdma type tech for mailing list subscriptions has been > > considered best practice for over a decade. Personal use is nasty, brutish > > and hopefully short. > > > > Allowing unsubscribed persons to post after a tdma authentication is a > > courtesy, there is no obligation to extend it in the first place. > > > > Pooling the tdma responses across multiple ietf mailing lists is a further > > courtesy. > > > > > > There is more we can do here but no more that we should feel obliged to do > > - ecept for the fact that we are a standards organization and should eat the > > dog food. > > > > In particular, sign the messages with dkim and deploy spf. > > > > > > > > Sent from my GoodLink Wireless Handheld (www.good.com) > > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Wednesday, October 03, 2007 08:23 AM Pacific Standard Time > > To: Brian E Carpenter > > Cc: ietf@ietf.org > > Subject: Re: Spammers answering TMDA Queries > > > > Brian E Carpenter wrote: > > > Speaking personally, I think annual reconfirmation is quite reasonable. > > > The message sent to the user should make it clear that it is an > > > annual process. > > > > Except... the annual confirmation is probably going to get accidentally > > deleted by a lot of people because they think it's the monthly notice. > > > > If this is a real problem, wouldn't it be better to take it up with the > > mailman > > folks since I'd expect that it's not just ietf? I've been working with > > them on > > dkim related stuff and they are quite reasonable folks. Maybe they have > > some > > ideas on this front. > > > > Mike > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf > > > > > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf > > > > > > > -- > Clint (JOATMON) Chaplin > Principal Engineer > Corporate Standardization (US) > SISA > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 05 17:23:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IduHz-0003Xc-Td; Fri, 05 Oct 2007 17:00:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IduHz-0003W0-1p for ietf@ietf.org; Fri, 05 Oct 2007 17:00:51 -0400 Received: from harry.mail-abuse.org ([168.61.5.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IduHs-0004B1-IB for ietf@ietf.org; Fri, 05 Oct 2007 17:00:44 -0400 Received: from [10.2.164.149] (SJC-Office-NAT-218.Mail-Abuse.ORG [168.61.10.218]) by harry.mail-abuse.org (Postfix) with ESMTP id B040F4142A; Fri, 5 Oct 2007 14:00:43 -0700 (PDT) In-Reply-To: <09f601c8076c$a2211a80$0601a8c0@pc6> References: <2788466ED3E31C418E9ACC5C316615570462C0@mou1wnexmb09.vcorp.ad.vrsn.com> <09f601c8076c$a2211a80$0601a8c0@pc6> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Message-Id: From: Douglas Otis Date: Fri, 5 Oct 2007 14:00:38 -0700 To: "Tom.Petch" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ietf Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0166053233==" Errors-To: ietf-bounces@ietf.org --===============0166053233== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-709958210; protocol="application/pkcs7-signature" --Apple-Mail-2-709958210 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > But what is it? A step beyond grey listing. Transfer by reference is another alternative. http://wiki.tmda.net/ -Doug --Apple-Mail-2-709958210 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQzCCBj8w ggUnoAMCAQICEQDPkOSlY+yj84uKhgvUeK2MMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNF UlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTA3MTAw NTAwMDAwMFoXDTA4MTAwNDIzNTk1OVowgdwxNTAzBgNVBAsTLENvbW9kbyBUcnVzdCBOZXR3b3Jr IC0gUEVSU09OQSBOT1QgVkFMSURBVEVEMUYwRAYDVQQLEz1UZXJtcyBhbmQgQ29uZGl0aW9ucyBv ZiB1c2U6IGh0dHA6Ly93d3cuY29tb2RvLm5ldC9yZXBvc2l0b3J5MR8wHQYDVQQLExYoYykyMDAz IENvbW9kbyBMaW1pdGVkMRUwEwYDVQQDEwxEb3VnbGFzIE90aXMxIzAhBgkqhkiG9w0BCQEWFGRv dGlzQG1haWwtYWJ1c2Uub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt+29qHsN yJzMRTVSENTX/tMCiHocW5apY/v+qNaXs+HhnmJYRABZXzKMdmoN53leO59GtNUe+QvL7brqqnpC 20k8gbZ/fbasUOBFc7Fz0B6dwd8h9Q1oc/HBEZ7wszr3kD1s4M0rLbFl2ObyFyDu3ddzkXauLfGp bJvXxEiqprTyoecoWTRr4aVS1VIQWYdE6t6r7Pv8KmMDbmNFmiRBm49Eqd54+27KrucyH1LKz4se RKyT2OntCBskxsp5Zn+Fy+UJptYPxMbINnySJdrCgA+qO9E3rivvozWqp7yoZNQWKXh7tQ+vYWex BwIMrHs97ZRGn7rBMsPeER9wS9xskQIDAQABo4ICJjCCAiIwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFNY9JnRpzBbdu/Atrm5Ke/cY7nwGMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwfAYIKwYBBQUHAQEEcDBuMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwNAYIKwYBBQUHMAKGKGh0dHA6 Ly9jcnQuY29tb2RvLm5ldC9VVE5BQUFDbGllbnRDQS5jcnQwHwYDVR0RBBgwFoEUZG90aXNAbWFp bC1hYnVzZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBAIYYFYH00QyhBNuf8DDkXtKcmJLEh0BZGqe4 GGc+vK1OLbfQwHWpoo+d1cBQUHUlXyDqRrS2ezUmuZo8ate+CfKvRAmefVZDOAxQrXa9lKQ2vmNH YSIPv2EjlLeyCs/MUVIScSiuyPrYhlKpWWYcXpzLkSOs2mjCkiaJ7YFBbHQs9y6+SySwHP6wxdch vkKNrNurIQp+PaaRqs+FUZOj3L6Bcy4G8seOpQNGbKyoHG5DIAmrTd45lt6VSK+Sp79JJ9fkfM2Z 3mLewwFEdhTH6LNRpdGKTINglmfMedD1WVwmHyart/n7Bj62CY5ROJNH50hBfy1W/Dxn++a8DuUx cxQxggP/MIID+wIBATCBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5T YWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExho dHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRAM+Q5KVj7KPzi4qGC9R4rYwwCQYFKw4DAhoFAKCCAg8w GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcxMDA1MjEwMDM5WjAj BgkqhkiG9w0BCQQxFgQUhka30NhQL80pOgTpTF3WdXdItH4wgdUGCSsGAQQBgjcQBDGBxzCBxDCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwG A1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVz dC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBF bWFpbAIRAM+Q5KVj7KPzi4qGC9R4rYwwgdcGCyqGSIb3DQEJEAILMYHHoIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAz5Dk pWPso/OLioYL1HitjDANBgkqhkiG9w0BAQEFAASCAQAprJmXLZr5T5vDKJmp0Xq82yXxFJ415s4j 9MGW3caCPRZ/CFhdutQi/1PbWgtPU1+VrSwAkEvffQTB4ueYmiVhrHjqlWYHZODynOtUI9wqtFbE rdSEIvhKpFwbJV9G8WMmIGU5KdUni0sORPfwUjMlbLWNZiwWkFjbXFPnrBLSiHJPI+kuN9FxhDsN mP2EWO1SYgdn6MGtBOlDMIykDPDBhm0pGlyzScZe621r55Yc7BNzFNjbUUt+k0ujnSkZl/ogjXLz jqUyTVQ/3jK+H9dTphmY09asXt2rkmWrr0tIiWt4rq+nhxv6kYi7zogiJwBqXbtyzibQSMm/zaHi 9Y+YAAAAAAAA --Apple-Mail-2-709958210-- --===============0166053233== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0166053233==-- From ietf-bounces@ietf.org Fri Oct 05 18:41:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idvhb-0006uG-Sr; Fri, 05 Oct 2007 18:31:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdvhT-0006r8-6P for ietf@ietf.org; Fri, 05 Oct 2007 18:31:15 -0400 Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdvhR-0007KW-PK for ietf@ietf.org; Fri, 05 Oct 2007 18:31:15 -0400 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id l95MUoK8073844; Sat, 6 Oct 2007 08:30:51 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200710052230.l95MUoK8073844@drugs.dv.isc.org> To: Iljitsch van Beijnum From: Mark Andrews In-reply-to: Your message of "Fri, 05 Oct 2007 18:45:28 +0200." <3D2AFBEC-CEE1-435A-AE2C-E0591BAE91FE@muada.com> Date: Sat, 06 Oct 2007 08:30:50 +1000 X-Spam-Score: -1.4 (-) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Michel Py , IETF Discussion Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > On 5-okt-2007, at 6:38, Michel Py wrote: > > > Nothing is going to happen the day the last v4 block is allocated. > > Nothing is going to happen for days. Nothing is going to happen for > > weeks. > > Sure. > > > Nothing is going to happen for months. > > Not so sure. The big ISPs that work in blocks of a million or so > addresses will be the first ones to see their requests turned down > because addresses are out of stock. Presumably, they'll need those > addresses to connect new customers. If you happen to request a new > connection around that time you'll see an effect. > > >> Does anybody have any established and sustained opinion on that > >> and could provide verifiable if not objective data? How many > >> critical bugs were really found in typical systems? > > > We will never know that. There were scores of people who billed > > tons of > > money to take care of it; you don't expect that they will admit to > > spending all this time finding nothing, would you? > > I think some pretty much have. > > I'm sure that if the Y2K issue had been ignored there'd been lots of > problems with individual systems. The part that was unlikely (but not > impossible) from the beginning were all the domino effects. A router > won't stop routing if it is set to the wrong time of day. I'm pretty > sure a plane won't stop flying, either. But in that particular case, > "pretty sure" is not exactly good enough... There have been fighter jets that couldn't cross the date line as the navigation computers crashes/gave wrong readings. The pilots that discovered this had to be escorted back by other aircraft with working navigation. > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 05 19:09:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdwBu-0007GR-9e; Fri, 05 Oct 2007 19:02:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdwBs-0006vA-QT for ietf@ietf.org; Fri, 05 Oct 2007 19:02:40 -0400 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdwBi-0008SC-8i for ietf@ietf.org; Fri, 05 Oct 2007 19:02:36 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l95N29RT017866; Fri, 5 Oct 2007 19:02:09 -0400 (EDT) Received: from [18.18.1.160] (NOME-KING.MIT.EDU [18.18.1.160]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l95N27tW021475 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 5 Oct 2007 19:02:08 -0400 (EDT) In-Reply-To: References: <2788466ED3E31C418E9ACC5C316615570462C0@mou1wnexmb09.vcorp.ad.vrsn.com> <09f601c8076c$a2211a80$0601a8c0@pc6> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8D190DB2-C53A-4D5E-BC19-F450997425B5@mit.edu> From: Ken Raeburn Date: Fri, 5 Oct 2007 19:02:06 -0400 To: Douglas Otis X-Mailer: Apple Mail (2.752.2) X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ietf Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 5, 2007, at 17:00, Douglas Otis wrote: >> But what is it? > > A step beyond grey listing. "Beyond" implies "in vaguely the same direction". From skimming the TMDA description, I don't see that at all. Ken _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 06 01:16:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ie1mM-0004K7-C8; Sat, 06 Oct 2007 01:00:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ie1mK-00049e-5v for ietf@ietf.org; Sat, 06 Oct 2007 01:00:40 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ie1mD-0000ko-Ud for ietf@ietf.org; Sat, 06 Oct 2007 01:00:40 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Oct 2007 22:00:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <3D2AFBEC-CEE1-435A-AE2C-E0591BAE91FE@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv4 to IPv6 transition Thread-Index: AcgHb0V1TS7cZBEUR7yJS0S7uot+HQAXEwQg References: <470527DE.8010506@cs.utk.edu> <6D69802F-F58D-4149-A827-1ECD927675B3@wave-storm.com> <3D2AFBEC-CEE1-435A-AE2C-E0591BAE91FE@muada.com> From: "Michel Py" To: "Iljitsch van Beijnum" X-Spam-Score: 1.0 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: IETF Discussion Subject: RE: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >> Michel Py wrote: >> Nothing is going to happen for months. > Iljitsch van Beijnum wrote: > Not so sure. The big ISPs that work in blocks of a million or > so addresses will be the first ones to see their requests turned > down because addresses are out of stock. Presumably, they'll need > those addresses to connect new customers. If you happen to request > a new connection around that time you'll see an effect. Then they can begin to reclaim the waste in their own backyard. I know first hand scores of customers who: - Have been allocated a block of addresses and NAT out of the /30 of the T1 link. The blocks can be reclaimed easily. - Have been allocated a /28 without asking for it and all they use is a single IP. During the good old ipv6mh days, we could have hoped that IPv6 would be deployed in time; this is no longer the case. Think about the following: even if in 3 years 50% of hosts were IPv6-only capable, it would not diminish the need for IPv4. All the double-NAT tricks, unused address reclaim, config cleanup etc are going to happen now no matter what. I'm not saying it's going to be easy or cheap, but as long as there is a need for v4 it will happen. The unanswered question is: are all these tricks going to be enough to keep operating IPv4. Nobody knows, but almost everyone who already has a v4 address can wait. I am sad so read Y2K-like FUD and counters. The name of the game is: wait, see how much it hurts, and do something about it when the pain becomes unbearable. Most people will try vicodin before opting for the surgery, especially when dealing with a disease that has not killed anyone yet. You can't change that. Michel. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 06 10:26:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeAIi-0007Ar-7l; Sat, 06 Oct 2007 10:06:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeAIg-00077h-EZ for ietf@ietf.org; Sat, 06 Oct 2007 10:06:38 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IeAIf-0006q7-SS for ietf@ietf.org; Sat, 06 Oct 2007 10:06:38 -0400 Received: from [163.117.139.34] (nirrti.it.uc3m.es [163.117.139.34]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l96E3LLW088935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 6 Oct 2007 16:03:22 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <470527DE.8010506@cs.utk.edu> <6D69802F-F58D-4149-A827-1ECD927675B3@wave-storm.com> <3D2AFBEC-CEE1-435A-AE2C-E0591BAE91FE@muada.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Sat, 6 Oct 2007 16:06:05 +0200 To: Michel Py X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, score=-1.7 required=3.5 tests=AWL,BAYES_00, ILJQX_SUBJ_NUMINWORD autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: IETF Discussion Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 6-okt-2007, at 7:00, Michel Py wrote: > Think about the following: even if in 3 years 50% of hosts were > IPv6-only capable, it would not diminish the need for IPv4. All the > double-NAT tricks, unused address reclaim, config cleanup etc are > going > to happen now no matter what. I'm not saying it's going to be easy or > cheap, but as long as there is a need for v4 it will happen. > The unanswered question is: are all these tricks going to be enough to > keep operating IPv4. Nobody knows, but almost everyone who already > has a > v4 address can wait. Well, if in the forseeable future (3 years is a bit short, though) 50% of all hosts has IPv6 connectivity, I would call that a resounding success. (I'll even take 25 or even 10 % or whatever is enough to make most ISPs deploy IPv6 in their networks.) That the other 50/75/90% is still IPv6-only wouldn't be a problem: presumably, IPv4 works for them so there is no need to add IPv6. The tricky part is what happens to people that run into limitations that exist in IPv4 but not in IPv6. (NAT, hard to get enough addresses, that kind of stuff.) So far, deploying IPv6 to work around these problems has rarely been a workable option. But hopefully, it will become one in the next few years. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 06 16:27:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeFsw-0003VM-12; Sat, 06 Oct 2007 16:04:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeFst-0003UO-3L for ietf@ietf.org; Sat, 06 Oct 2007 16:04:23 -0400 Received: from rv-out-0910.google.com ([209.85.198.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IeFsr-0005Yl-TF for ietf@ietf.org; Sat, 06 Oct 2007 16:04:23 -0400 Received: by rv-out-0910.google.com with SMTP id l15so378088rvb for ; Sat, 06 Oct 2007 13:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=SbGRT/P9ltw5pML1KZaF6DuSIe9tUsNfYJze+AHABBo=; b=gbNW6sOORjCfHWYR5/+/eM+oygYKlvMuVqdv0mW4OFmCLxD+iRkjE3r3g8L4LCBICy4EIdJjl/SjP7eImoFouz/s711pgnM9j+3jelR9qA70pMf/Y/cO4aEBUsDj1AJaPBuHCxGP4FBiKmFLsdrYcqcIBynWQ6K7rdCVg7snl4E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=g8WS/EU75bBeZtNr+KUCB5Twnitz2h2hB3Awz5rzw3Gt+LB2zsjvtbykoeoQf3IofKf2KjrD6/yQV4EBBwEA5clf4HpkIxu9qfuFHQKfQ3LvWcgryf8dytvHeqGDpP3mKNK3BG1NsanK6DmsbQtItpQnG7YW5lcWgDoy4MbBR10= Received: by 10.141.51.15 with SMTP id d15mr199987rvk.1191701053718; Sat, 06 Oct 2007 13:04:13 -0700 (PDT) Received: from ?10.1.1.7? ( [222.153.1.229]) by mx.google.com with ESMTPS id g6sm7583849rvb.2007.10.06.13.04.12 (version=SSLv3 cipher=RC4-MD5); Sat, 06 Oct 2007 13:04:13 -0700 (PDT) Message-ID: <4707EA34.7000709@gmail.com> Date: Sun, 07 Oct 2007 09:04:04 +1300 From: Brian E Carpenter User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ietf References: <2788466ED3E31C418E9ACC5C316615570462C0@mou1wnexmb09.vcorp.ad.vrsn.com> <09f601c8076c$a2211a80$0601a8c0@pc6> <8D190DB2-C53A-4D5E-BC19-F450997425B5@mit.edu> In-Reply-To: <8D190DB2-C53A-4D5E-BC19-F450997425B5@mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-06 12:02, Ken Raeburn wrote: > On Oct 5, 2007, at 17:00, Douglas Otis wrote: >>> But what is it? >> >> A step beyond grey listing. > > "Beyond" implies "in vaguely the same direction". From skimming the > TMDA description, I don't see that at all. In any case, the IETF config for TMDA is a white list only, as far as I know. All known subscribers to IETF lists are automaticaly white listed, and anyone else has to respond once to a challenge to become white listed. Mail from non-white listed senders goes into manual moderation. That's all. Not perfect, but it stops a heck of a lot of spam. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 06 16:27:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeG3O-0004eu-U4; Sat, 06 Oct 2007 16:15:14 -0400 Received: from [10.9From ietf-bounces@ietf.org Sat Oct 06 16:27:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeFsw-0003VM-12; Sat, 06 Oct 2007 16:04:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeFst-0003UO-3L for ietf@ietf.org; Sat, 06 Oct 2007 16:04:23 -0400 Received: from rv-out-0910.google.com ([209.85.198.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IeFsr-0005Yl-TF for ietf@ietf.org; Sat, 06 Oct 2007 16:04:23 -0400 Received: by rv-out-0910.google.com with SMTP id l15so378088rvb for ; Sat, 06 Oct 2007 13:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=SbGRT/P9ltw5pML1KZaF6DuSIe9tUsNfYJze+AHABBo=; b=gbNW6sOORjCfHWYR5/+/eM+oygYKlvMuVqdv0mW4OFmCLxD+iRkjE3r3g8L4LCBICy4EIdJjl/SjP7eImoFouz/s711pgnM9j+3jelR9qA70pMf/Y/cO4aEBUsDj1AJaPBuHCxGP4FBiKmFLsdrYcqcIBynWQ6K7rdCVg7snl4E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=g8WS/EU75bBeZtNr+KUCB5Twnitz2h2hB3Awz5rzw3Gt+LB2zsjvtbykoeoQf3IofKf2KjrD6/yQV4EBBwEA5clf4HpkIxu9qfuFHQKfQ3LvWcgryf8dytvHeqGDpP3mKNK3BG1NsanK6DmsbQtItpQnG7YW5lcWgDoy4MbBR10= Received: by 10.141.51.15 with SMTP id d15mr199987rvk.1191701053718; Sat, 06 Oct 2007 13:04:13 -0700 (PDT) Received: from ?10.1.1.7? ( [222.153.1.229]) by mx.google.com with ESMTPS id g6sm7583849rvb.2007.10.06.13.04.12 (version=SSLv3 cipher=RC4-MD5); Sat, 06 Oct 2007 13:04:13 -0700 (PDT) Message-ID: <4707EA34.7000709@gmail.com> Date: Sun, 07 Oct 2007 09:04:04 +1300 From: Brian E Carpenter User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ietf References: <2788466ED3E31C418E9ACC5C316615570462C0@mou1wnexmb09.vcorp.ad.vrsn.com> <09f601c8076c$a2211a80$0601a8c0@pc6> <8D190DB2-C53A-4D5E-BC19-F450997425B5@mit.edu> In-Reply-To: <8D190DB2-C53A-4D5E-BC19-F450997425B5@mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-06 12:02, Ken Raeburn wrote: > On Oct 5, 2007, at 17:00, Douglas Otis wrote: >>> But what is it? >> >> A step beyond grey listing. > > "Beyond" implies "in vaguely the same direction". From skimming the > TMDA description, I don't see that at all. In any case, the IETF config for TMDA is a white list only, as far as I know. All known subscribers to IETF lists are automaticaly white listed, and anyone else has to respond once to a challenge to become white listed. Mail from non-white listed senders goes into manual moderation. That's all. Not perfect, but it stops a heck of a lot of spam. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 06 16:27:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeG3O-0004eu-U4; Sat, 06 Oct 2007 16:15:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeG3N-0004Zl-9W for ietf@ietf.org; Sat, 06 Oct 2007 16:15:13 -0400 Received: from rv-out-0910.google.com ([209.85.198.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IeG3H-0005k7-3b for ietf@ietf.org; Sat, 06 Oct 2007 16:15:13 -0400 Received: by rv-out-0910.google.com with SMTP id l15so379358rvb for ; Sat, 06 Oct 2007 13:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=EDiMQFHATfQ+OOOnozrbvXwRqD8FXz6UlIcIDj/srnA=; b=qkZAG9HK0dpSe4PZlXVvPsJw8Y7woOfuJCzmUMjD+MJIjjiYXMwaBrhB25D3BSgmVINRjbTeEmLDTKisMEfmawwGSPh7XUtQrlftibm85wDXp3rh6yS/gjxma7eLnbeoXIphMnnzjGKdHhJ4ZpE5SbVLq8v0YTDorxyIgBmYUlo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=VNveb8sNjWoZM5FYeFel0JhZomv6f1FJz3w41H2vGTZwqY3rIn0Pp5OnQzn5aSgMuzGeKMFUTFMwIX8R3dTS/GvwlzSZ16iw6PemIttLW4QtXBCIzciIu2lIyZ0hmYPylsPG3Tvu6Bl7dp9gRlTWNQut8sw9eJD1TJtIjdF+ZjY= Received: by 10.141.87.13 with SMTP id p13mr2276144rvl.1191701690663; Sat, 06 Oct 2007 13:14:50 -0700 (PDT) Received: from ?10.1.1.7? ( [222.153.1.229]) by mx.google.com with ESMTPS id k41sm8885874rvb.2007.10.06.13.14.48 (version=SSLv3 cipher=RC4-MD5); Sat, 06 Oct 2007 13:14:50 -0700 (PDT) Message-ID: <4707ECB0.6020302@gmail.com> Date: Sun, 07 Oct 2007 09:14:40 +1300 From: Brian E Carpenter User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ralph Droms References: <46EAE465.8070104@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: IETF-Discussion Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-05 09:12, Ralph Droms wrote: > Typo: should read IPv6 ~= IPv4+more_bits... > > - Ralph > > On Oct 4, 2007, at Oct 4, 2007,4:52 AM, Ralph Droms wrote: > >> Regarding transition: >> >> On Sep 14, 2007, at Sep 14, 2007,3:43 PM, Dave Crocker wrote: >>> >>> >>> Unless I've missed something rather basic, in the case of IPv6, very >>> little >>> attention was paid to facilitating transition by maximizing >>> interoperability >>> with the IPv4 installed base. >> Dave, I have to agree with you in this regard. We may have achieved >> neither >> significant new capabilities because IPv6 ~= IPv6+more_bits, nor ease of >> transition because transition wasn't thoroughly evaluated early on in >> the design process... Ralph, that last assertion simply isn't true. Migration/transition/ co-existence was on the radar screen right from the start. The dual stack model was chosen explicitly to allow for co-existence, and in particular so that dual stack servers can serve both IPv4 and IPv6 clients, and that is running code. There's a fundamental difficulty in having IPvX-only clients working with IPvY-only servers except via application-level relays. It isn't a consequence of design details of v4 and v6. I'm sure we could have done better, but this was very definitely thought about. Brian _____________________________1.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeG3N-0004Zl-9W for ietf@ietf.org; Sat, 06 Oct 2007 16:15:13 -0400 Received: from rv-out-0910.google.com ([209.85.198.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IeG3H-0005k7-3b for ietf@ietf.org; Sat, 06 Oct 2007 16:15:13 -0400 Received: by rv-out-0910.google.com with SMTP id l15so379358rvb for ; Sat, 06 Oct 2007 13:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=EDiMQFHATfQ+OOOnozrbvXwRqD8FXz6UlIcIDj/srnA=; b=qkZAG9HK0dpSe4PZlXVvPsJw8Y7woOfuJCzmUMjD+MJIjjiYXMwaBrhB25D3BSgmVINRjbTeEmLDTKisMEfmawwGSPh7XUtQrlftibm85wDXp3rh6yS/gjxma7eLnbeoXIphMnnzjGKdHhJ4ZpE5SbVLq8v0YTDorxyIgBmYUlo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=VNveb8sNjWoZM5FYeFel0JhZomv6f1FJz3w41H2vGTZwqY3rIn0Pp5OnQzn5aSgMuzGeKMFUTFMwIX8R3dTS/GvwlzSZ16iw6PemIttLW4QtXBCIzciIu2lIyZ0hmYPylsPG3Tvu6Bl7dp9gRlTWNQut8sw9eJD1TJtIjdF+ZjY= Received: by 10.141.87.13 with SMTP id p13mr2276144rvl.1191701690663; Sat, 06 Oct 2007 13:14:50 -0700 (PDT) Received: from ?10.1.1.7? ( [222.153.1.229]) by mx.google.com with ESMTPS id k41sm8885874rvb.2007.10.06.13.14.48 (version=SSLv3 cipher=RC4-MD5); Sat, 06 Oct 2007 13:14:50 -0700 (PDT) Message-ID: <4707ECB0.6020302@gmail.com> Date: Sun, 07 Oct 2007 09:14:40 +1300 From: Brian E Carpenter User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ralph Droms References: <46EAE465.8070104@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: IETF-Discussion Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-05 09:12, Ralph Droms wrote: > Typo: should read IPv6 ~= IPv4+more_bits... > > - Ralph > > On Oct 4, 2007, at Oct 4, 2007,4:52 AM, Ralph Droms wrote: > >> Regarding transition: >> >> On Sep 14, 2007, at Sep 14, 2007,3:43 PM, Dave Crocker wrote: >>> >>> >>> Unless I've missed something rather basic, in the case of IPv6, very >>> little >>> attention was paid to facilitating transition by maximizing >>> interoperability >>> with the IPv4 installed base. >> Dave, I have to agree with you in this regard. We may have achieved >> neither >> significant new capabilities because IPv6 ~= IPv6+more_bits, nor ease of >> transition because transition wasn't thoroughly evaluated early on in >> the design process... Ralph, that last assertion simply isn't true. Migration/transition/ co-existence was on the radar screen right from the start. The dual stack model was chosen explicitly to allow for co-existence, and in particular so that dual stack servers can serve both IPv4 and IPv6 clients, and that is running code. There's a fundamental difficulty in having IPvX-only clients working with IPvY-only servers except via application-level relays. It isn't a consequence of design details of v4 and v6. I'm sure we could have done better, but this was very definitely thought about. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf __________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 06 22:59:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeLuY-0008Ng-4k; Sat, 06 Oct 2007 22:30:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeLuW-0008EH-Cs for ietf@ietf.org; Sat, 06 Oct 2007 22:30:28 -0400 Received: from pacdcimo02.cable.comcast.com ([24.40.8.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IeLuL-0006oq-8K for ietf@ietf.org; Sat, 06 Oct 2007 22:30:23 -0400 Received: from ([24.40.15.118]) by pacdcimo02.cable.comcast.com with ESMTP id KP-GZL85.12344839; Sat, 06 Oct 2007 22:29:41 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 6 Oct 2007 22:29:41 -0400 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" Content-Transfer-Encoding: quoted-printable Date: Sat, 6 Oct 2007 22:20:24 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602026BAD72@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <45AEC6EF95942140888406588E1A6602026BA30D@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 71: Results of Social Venue Survey Thread-Index: AcflvowBQSqL9j2LSN+0Y2GsTXaK+AQYd5Bg References: <45AEC6EF95942140888406588E1A6602026BA30D@PACDCEXCMB04.cable.comcast.com> From: "Livingood, Jason" To: X-OriginalArrivalTime: 07 Oct 2007 02:29:41.0478 (UTC) FILETIME=[EA510860:01C80889] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Subject: IETF 71: Results of Social Venue Survey X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I would like to thank all of you in the IETF community that participated in this survey. We were delighted that 245 people took the time to do so. We asked both about what people liked and disliked about IETF socials generally, as well as which of the two venues we narrowed our choices to they liked best (we of course visited/investigated many more). In terms of a venue, there was clearly more interest in the Philadelphia Museum of Art, and so we have selected this venue and are now working out all of the agreements to make this happen. PDFs of the raw survey results are available to anyone who wishes to view them. These may be particularly useful to future IETF meeting sponsors, and many of the comments are quite interesting. These can be found at http://ietf71.comcast.net/premtgsurvey/IETF71-SocialVenueSurvey.zip. Please note that we will be publishing more meeting & logistical info over time at http://ietf71.comcast.net (you can also set your RSS reader to http://ietf71.comcast.net/?feed=3Drss2 to pick up any changes automatically). Key survey findings: 1. Of the respondents, the large majority plan to attend IETF 71. a. 83%, or 204 people, plan to attend. b. 15%, or 38 people, are undecided. c. 1%, or 3 people, will not attend. 2. Of the respondents, many are undecided on whether they will attend the social and appear to decide whether to do so at each IETF meeting. a. 59%, or 143 people, sometimes attend depending on the individual event. b. 39%, or 94 people, always attend. c. 3%, or 6 people, never attend. d. 1 person would only attend if they event was certain to be IPv6-compliant. 3. The most important parts of attending a social event for attendees are: a. Meeting people / talking to people b. Good food c. Visiting an interesting venue d. Stuff to see / do e. Open bar 4. Of secondary importance for the event (less important than above): a. Music b. Affordability / value 5. The least important item for an event was music. 6. Respondents were from a range of geographic locations: a. U.S.: 55% b. Europe: 27% c. Asia: 7% d. U.K.: 4% e. Canada: 3% f. Middle East: 1% g. 2% lived "in the network," "on the moon," or in some other "secret" locale. Regards Jason Livingood > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 > Sent: Thursday, August 23, 2007 3:48 PM > To: ietf@ietf.org > Subject: IETF 71: Social Venue Survey >=20 > Hello - >=20 > I am on the planning team for the sponsoring organization of=20 > IETF 71. We are continuing to get ready for this event. =20 >=20 > We would like to solicit the community's feedback on the=20 > possible locations of the social venue and what is important=20 > to you for such events. There are 6 questions, so it should=20 > only take you a few minutes to complete. >=20 > To take the survey, go to: > http://www.surveymonkey.com/s.aspx?sm=3Dhcr9IMRQmHOe74i_2bMChaOg_3d_3d >=20 > Thank you in advance if you take the time to complete a survey. >=20 > Regards > Jason Livingood >=20 > PS - This survey will be open until September 5, 2007. >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Oct 07 03:23:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeQ4k-0001Kg-GA; Sun, 07 Oct 2007 02:57:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeQ4i-0001KU-Ch for ietf@ietf.org; Sun, 07 Oct 2007 02:57:16 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IeQ4c-00025V-0D for ietf@ietf.org; Sun, 07 Oct 2007 02:57:16 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 6 Oct 2007 23:57:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv4 to IPv6 transition Thread-Index: AcgIIi72S/deZWzyTgOs7MIJjlIbZwAhahog References: <470527DE.8010506@cs.utk.edu> <6D69802F-F58D-4149-A827-1ECD927675B3@wave-storm.com> <3D2AFBEC-CEE1-435A-AE2C-E0591BAE91FE@muada.com> From: "Michel Py" To: "Iljitsch van Beijnum" X-Spam-Score: 1.0 (+) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: IETF Discussion Subject: RE: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >> Michel Py wrote: >> The unanswered question is: are all these tricks going to be >> enough to keep operating IPv4. Nobody knows, but almost >> everyone who already has a v4 address can wait. > Iljitsch van Beijnum wrote: > Well, if in the forseeable future (3 years is a bit short, > though) 50% of all hosts has IPv6 connectivity, I would call > that a resounding success. Me too, that's why I used "even if". I am glad you have come to admitting this publicly. Given some private email I have received yesterday, it appears that some of the most active participants in the IETF (and/or this mailing list) have been shocked to hear that, as of yesterday night, less than 50% of all hosts did not have IPv6 connectivity yet. Well, M$ will eventually fix Vista and it will eventually become popular; nothing to worry about :-D > (I'll even take 25 or even 10 % or whatever is enough to make most > ISPs deploy IPv6 in their networks.) That percentage is a heck of an interesting speculation, and I would not dare no bet anything more than a beer on it. More on this below. > That the other 50/75/90% is still IPv6-only wouldn't be a problem: > presumably, IPv4 works for them so there is no need to add IPv6. I presume you meant "the other 50/75/90% is still IPv4-only" ^ That's the real deal: if 90% of hosts don't need IPv6, it never takes off. This is hardly a new notion, but there is such thing as a critical mass. > The tricky part is what happens to people that run into > limitations that exist in IPv4 but not in IPv6. (NAT, hard > to get enough addresses, that kind of stuff.) So far, deploying > IPv6 to work around these problems has rarely been a workable > option. But hopefully, it will become one in the next few years. Iljitsch, I like your eternal optimism but please face reality: despite being evil, NAT is a feature that IPv6 does not have (yet?), and for anyone who can read this today, "hard to get enough addresses" is a red herring. I just [forklift] upgraded one of my old small customers; they are 100% IPv6 capable and 90% IPv6 configured (Vista on every desktop, Server 2003 SP1 x64, Exchange 2007, IOS 12.4). They have a /28 from {major ISP, name withheld to protect the guilty and accessorily save my @55} which I did not ask for; all I use is a single IP. The next thing I foresee coming from {major ISP} is to change that /28 into a single static IP. For the next 5 years I still don't have a single reason to upgrade. While you're at it, explain me something else: I'm a fat ignorant dumb lazy American imperialist. Why should I bother if, in 5 years, someone in a country that I have not heard the name yet has to sub their Internet connectivity to an American company {which I, ahem, happen to own shares of} instead of getting their own PI? Michel. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Oct 07 11:35:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeXji-0003Go-CF; Sun, 07 Oct 2007 11:08:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeXjg-00035o-NZ for ietf@ietf.org; Sun, 07 Oct 2007 11:08:04 -0400 Received: from pacdcimo02.cable.comcast.com ([24.40.8.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IeXja-0000SR-IH for ietf@ietf.org; Sun, 07 Oct 2007 11:08:04 -0400 Received: from ([10.52.116.31]) by pacdcimo02.cable.comcast.com with ESMTP id KP-GZL85.12350252; Sun, 07 Oct 2007 11:07:40 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 7 Oct 2007 11:07:40 -0400 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" Content-Transfer-Encoding: quoted-printable Date: Sun, 7 Oct 2007 11:07:36 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602026BAD84@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <000301c808b7$0acbe0b0$0300a8c0@win.cetp.ipsl.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Geography briefiengs for IETF required Thread-Index: AcgIt208REW0QXMDRVeerNSx4sCgtwAOo+Og References: <000301c808b7$0acbe0b0$0300a8c0@win.cetp.ipsl.fr> From: "Livingood, Jason" To: "Elisabeth Porteneuve" X-OriginalArrivalTime: 07 Oct 2007 15:07:40.0275 (UTC) FILETIME=[CDCABC30:01C808F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ietf@ietf.org Subject: RE: Geography briefiengs for IETF required X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Elisabeth - Thanks you for your gracious and kind reply. I appear to be guilty of dropping the word "Continental" from the summary of results, and apologize for apparently offending you on this point. The results summary should have read "Continental Europe." =20 Those who took the survey will have noticed (and this is available in the downloadable results) that we in fact had listed a "U.K." choice as well as a "Continental Europe" choice.=20 Regards Jason > -----Original Message----- > From: Elisabeth Porteneuve [mailto:elisabeth.porteneuve@cetp.ipsl.fr]=20 > Sent: Sunday, October 07, 2007 3:53 AM > To: Livingood, Jason > Cc: Elisabeth Porteneuve (labo) > Subject: Geography briefiengs for IETF required >=20 > Re your message posted to IETF list: >=20 > > Subject: IETF 71: Results of Social Venue Survey > > From: "Livingood, Jason" > > Date: Sat, 6 Oct 2007 22:20:24 -0400 >=20 > [...] >=20 > 6. Respondents were from a range of geographic locations: > a. U.S.: 55% > b. Europe: 27% > c. Asia: 7% > d. U.K.: 4% >=20 >=20 > Last time I checked the UK was in Europe. You may wish to add=20 > geography brifiengs to the IETF attendees (from the US?), and=20 > especialy those who make surveys. >=20 > Elisabeth Porteneuve >=20 >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Oct 07 12:42:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeYxR-0003Wj-Ia; Sun, 07 Oct 2007 12:26:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeYxQ-0003WT-Ga for ietf@ietf.org; Sun, 07 Oct 2007 12:26:20 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IeYxK-0002P7-A6 for ietf@ietf.org; Sun, 07 Oct 2007 12:26:20 -0400 X-IronPort-AV: E=Sophos;i="4.21,240,1188802800"; d="scan'208";a="232177879" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 07 Oct 2007 09:25:51 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l97GPj4O003401; Sun, 7 Oct 2007 09:25:45 -0700 Received: from pita.cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l97GPZ0X028187; Sun, 7 Oct 2007 16:25:40 GMT Date: Sun, 7 Oct 2007 09:24:11 -0700 (PDT) From: Ole Jacobsen To: "Livingood, Jason" In-Reply-To: <45AEC6EF95942140888406588E1A6602026BAD84@PACDCEXCMB04.cable.comcast.com> Message-ID: References: <000301c808b7$0acbe0b0$0300a8c0@win.cetp.ipsl.fr> <45AEC6EF95942140888406588E1A6602026BAD84@PACDCEXCMB04.cable.comcast.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2656; t=1191774345; x=1192638345; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ole@cisco.com; z=From:=20Ole=20Jacobsen=20 |Subject:=20RE=3A=20Geography=20briefiengs=20for=20IETF=20required |Sender:=20; bh=KXxXoj+mcStBk8sMxP5EpDQikwkg7Ue4f8iiWw/e2UM=; b=EbXAZ9jC/dHVjI9g1xGVS6q9l0APMLhgHS6yNtSRJ+Iiq7dEB+HhTmHdWAzMaJ2NM60+LpoJ p16vWPsjaNdX61sY58Mn/BbgkNZg2BWnGBSfqrq993UMpB2M75ZFhipn; Authentication-Results: sj-dkim-4; header.From=ole@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Elisabeth Porteneuve , ietf@ietf.org Subject: RE: Geography briefiengs for IETF required X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ole Jacobsen List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Wikipedia says: "Europe is one of the seven traditional continents of the Earth. Physically and geologically, Europe is the westernmost peninsula of Eurasia, west of Asia." Certainly in BRITISH "traditional" usage, "The Continent" or sometimes just "Europe" refers to mainland Europe and excludes Britain, Ireland and other European islands. One is aware that the UK is part of the EU, but I would argue that "UK" and "Europe" in the context of a survey is neither ambiguous nor a sign of geographical confusion. Adding "Continental" as Jason suggests certainly makes it more precise. English usage is a complicated thing, witness for example the British phrase: "The Government have announced" (instead of "has announced") something you would never see in print in the US. OK, back to our regularly scheduled IPv4 depletion debate :-) Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: ole@cisco.com URL: http://www.cisco.com/ipj On Sun, 7 Oct 2007, Livingood, Jason wrote: > Elisabeth - > > Thanks you for your gracious and kind reply. I appear to be guilty of > dropping the word "Continental" from the summary of results, and > apologize for apparently offending you on this point. The results > summary should have read "Continental Europe." > > Those who took the survey will have noticed (and this is available in > the downloadable results) that we in fact had listed a "U.K." choice as > well as a "Continental Europe" choice. > > Regards > Jason > > > -----Original Message----- > > From: Elisabeth Porteneuve [mailto:elisabeth.porteneuve@cetp.ipsl.fr] > > Sent: Sunday, October 07, 2007 3:53 AM > > To: Livingood, Jason > > Cc: Elisabeth Porteneuve (labo) > > Subject: Geography briefiengs for IETF required > > > > Re your message posted to IETF list: > > > > > Subject: IETF 71: Results of Social Venue Survey > > > From: "Livingood, Jason" > > > Date: Sat, 6 Oct 2007 22:20:24 -0400 > > > > [...] > > > > 6. Respondents were from a range of geographic locations: > > a. U.S.: 55% > > b. Europe: 27% > > c. Asia: 7% > > d. U.K.: 4% > > > > > > Last time I checked the UK was in Europe. You may wish to add > > geography brifiengs to the IETF attendees (from the US?), and > > especialy those who make surveys. > > > > Elisabeth Porteneuve > > > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Oct 07 22:03:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iehfh-0002hO-UZ; Sun, 07 Oct 2007 21:44:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iehff-0002a7-SL; Sun, 07 Oct 2007 21:44:35 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IehfV-00075x-IA; Sun, 07 Oct 2007 21:44:31 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 88BB233C21; Sun, 7 Oct 2007 18:40:06 -0700 (PDT) Date: Sun, 07 Oct 2007 18:40:05 -0700 From: Eric Rescorla To: iesg@ietf.org, ietf@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071008014006.88BB233C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Subject: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org $Id: draft-aboba-sg-experiment-02-rev.txt,v 1.2 2007/10/08 01:38:07 ekr Exp $ I don't find the motivation for this work particularly compelling: In some situations, while interest on the part of IETF participants and end-users may be evident, and the relevance to the Internet community may be demonstrated, the answer to other questions (such as an understanding of existing work, achievability of goals, or overlap with existing working groups or standards bodies) may not be as clear. In the past, the likely outcome in this circumstance has been to postpone Working Group formation or even additional Birds of a Feather (BOF) sessions until satisfactory answers are forthcoming. However, in practice this may leave the status of the potential Working Group officially undetermined for months or even years. While the Area Directors should provide potential Working Group participants timely updates on the status of the potential Working Group and insight into IESG or IAB concerns, currently there is no mechanism to track progress toward working group creation, and as a result, participants may not have a clear understanding of the status or the next steps. Also, the lack of formal recognition may negatively affect the motivation of the participants, and may leave those who have no followed the effort closely with an impression that no work is going on. I think there's a more meta-issue here: do we think it would be good for the IETF to have more WGs? If the answer is "yes, then it makes sense to foster new work in various ways. If the answer is "no" then it makes sense to treat getting an effort ready for WG formation as a proxy for the level of readiness of that effort. My general feeling is that the answer is "no." In some areas, such as RAI, every slot is filled and there are sometimes double bookings. Even in other areas, conflicts are a serious problem and documents that everyone agrees are important languish for lack of attention. So, I'm not sure why a change that's designed to make WG formation easier is a good thing--nor that experimenting with such a change is. A related issue is that this puts pressure on ADs to approve SGs for efforts that they would ordinarily simply refuse WGs for. I.e., "OK, so you won't give us a WG, how about a SG". Currently this document simply has it at the IESG's discretion: If at any point during the Working Group formation process, including after a first or second BoF session, interest within the IETF and end-user community has been demonstrated, but one or more Working Group formation criteria outlined in [RFC2418] Section 2.1 has not yet been met, the IESG MAY propose that a Study Group be formed. This seems ripe for abuse of the kind I outlined above. IMO this document would benefit from a clearer statement of the conditions under which it was appropriate to form an SG, thus reducing pressure on ADs. Arguably, SG formation should be subject to an IETF LC in the same way that WG formation is. Finally, it's unclear the extent to which SGs are intended to transition directly to WGs without going through another BOF phase. I have two concerns here: 1. It will be hard for the IESG to deny "successful" SGs the right to form a WG. 2. BOFs are a defined in-person event at which everyone knows that WG formation is being considered. This provides an opportunity for public high bandwidth discussion of that topic. I don't think an LC on the IETF list is an adequate substitute. Both of these issues are exacerbated by the tendency of running WGs (and I would expect SGs) to become insular. Since the point of a BOF is to encourage widespread input and more or less by definition an SG has failed at this stage, it seems unwise to allow SGs to become WGs without a real public vetting stage. In response to these objections, one might argue that this is only experiment, intended to evaluate the workability of a proposed change. That is of course true, but because we can only run a relatively small number of such experiments, it seems to me that one ought to ensure that: 1. The experiment is in service of a goal which we all pretty much agree is good (since it's much harder to evaluate that than whether the goal was achieved.) 2. The experiment be designed to test the best available variant of an idea. 3. The experiment be structured to do the minimal amount of harm if it fails. It's not clear to me that this proposed experiment meets these desiderata. -Ekr _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 03:28:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IemeS-0007XD-9Y; Mon, 08 Oct 2007 03:03:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IemeP-0007Wq-OU; Mon, 08 Oct 2007 03:03:37 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IemeO-00040A-Vp; Mon, 08 Oct 2007 03:03:37 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CC3A31986C0; Mon, 8 Oct 2007 10:03:35 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 39F5C19866A; Mon, 8 Oct 2007 10:03:35 +0300 (EEST) Message-ID: <4709D647.7070004@piuha.net> Date: Mon, 08 Oct 2007 10:03:35 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Eric Rescorla References: <20071008014006.88BB233C21@delta.rtfm.com> In-Reply-To: <20071008014006.88BB233C21@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: iesg@ietf.org, ietf@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Eric, Thanks for your comments. A couple of responses inline: > I think there's a more meta-issue here: do we think it would be good > for the IETF to have more WGs? If the answer is "yes, then it makes > sense to foster new work in various ways. If the answer is "no" then > it makes sense to treat getting an effort ready for WG formation as a > proxy for the level of readiness of that effort. My general feeling is > that the answer is "no." In some areas, such as RAI, every slot is > filled and there are sometimes double bookings. Even in other areas, > conflicts are a serious problem and documents that everyone agrees are > important languish for lack of attention. So, I'm not sure why a > change that's designed to make WG formation easier is a good > thing--nor that experimenting with such a change is. > > A related issue is that this puts pressure on ADs to approve SGs for > efforts that they would ordinarily simply refuse WGs for. I.e., > "OK, so you won't give us a WG, how about a SG". First, this proposal does in no way change the situation that the ADs have to say NO a lot of the time, and be able to justify that answer. Just as a data point from one AD, I have given that answer to many BOF requests and WG formation requests, and I don't feel saying no to something in between is going to be a problem :-) assuming the group indeed is not ready. But the issues with scheduling, lack of attention for important topics, and low quality of new work proposals are real concerns. I have a slightly different take on this than what you had above, however. INT is probably the most troublesome area with respect to scheduling, and I generally do not have any free slots during an IETF meeting. However, I don't think this implies we shouldn't consider new work. Its not as if the Internet was ready and nothing new was ever needed. We have a number of serious issues and new demands to meet. But we need to actively manage the set of things we work on. Some of the tools we need to consider include actually stopping WGs that have completed their task, rechartering, management restructuring (e.g., merging groups), questioning whether a non-delivering WG needs to continue to exist and consume slots, and yes, even new work. > Currently this > document simply has it at the IESG's discretion: > > If at any point during the Working Group formation process, including > after a first or second BoF session, interest within the IETF and > end-user community has been demonstrated, but one or more Working > Group formation criteria outlined in [RFC2418] Section 2.1 has not > yet been met, the IESG MAY propose that a Study Group be formed. > > This seems ripe for abuse of the kind I outlined above. IMO this > document would benefit from a clearer statement of the conditions > under which it was appropriate to form an SG, thus reducing pressure > on ADs. This would be helpful. Bernard, Laksminath, any ideas? > Arguably, SG formation should be subject to an IETF LC in the > same way that WG formation is. > Hm. I believed this was already the case. SGs are subject to exactly the same process as WGs, and I was assuming that like, WG formation, SG formation would include discussion in the IESG, consultation with the IAB, and IETF Last Call. Perhaps this needs clarification. Authors? > Finally, it's unclear the extent to which SGs are intended to > transition directly to WGs without going through another BOF > phase. I have two concerns here: > > 1. It will be hard for the IESG to deny "successful" SGs the right > to form a WG. > Saying NO is still going to be needed. > 2. BOFs are a defined in-person event at which everyone knows that > WG formation is being considered. This provides an opportunity > for public high bandwidth discussion of that topic. I don't > think an LC on the IETF list is an adequate substitute. > Good point. Bernard, Laksminath -- any ideas here? > 3. The experiment be structured to do the minimal amount of harm > if it fails. > In IESG review of this proposal, one of the things we talked about was whether there is a way to limit this experiment so that we can indeed test the idea but avoid impacting everyone. One of the suggestions was to set a limit on the number of SGs during the experiment to some low value, such as three. I would be in favor of this limitation. Jari _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 05:00:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeoFO-0004kX-En; Mon, 08 Oct 2007 04:45:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeoFN-0004gf-9t for ietf@ietf.org; Mon, 08 Oct 2007 04:45:53 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IeoFH-0007Ly-45 for ietf@ietf.org; Mon, 08 Oct 2007 04:45:53 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 8C4411C0105; Mon, 8 Oct 2007 10:45:36 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 86D2B1C00FE; Mon, 8 Oct 2007 10:45:36 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 7A49358ECCE; Mon, 8 Oct 2007 10:45:36 +0200 (CEST) Date: Mon, 8 Oct 2007 10:45:36 +0200 From: Stephane Bortzmeyer To: "Livingood, Jason" Message-ID: <20071008084536.GA24110@nic.fr> References: <000301c808b7$0acbe0b0$0300a8c0@win.cetp.ipsl.fr> <45AEC6EF95942140888406588E1A6602026BAD84@PACDCEXCMB04.cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45AEC6EF95942140888406588E1A6602026BAD84@PACDCEXCMB04.cable.comcast.com> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Elisabeth Porteneuve , ietf@ietf.org Subject: Re: Geography briefiengs for IETF required X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Sun, Oct 07, 2007 at 11:07:36AM -0400, Livingood, Jason wrote a message of 48 lines which said: > Those who took the survey will have noticed (and this is available > in the downloadable results) that we in fact had listed a "U.K." > choice as well as a "Continental Europe" choice. I wonder how people from Iceland or Sicily replied to the survey... _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 08:02:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ieqy7-0001BS-Ri; Mon, 08 Oct 2007 07:40:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ieqy5-00018h-EQ for ietf@ietf.org; Mon, 08 Oct 2007 07:40:13 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ieqy1-0003iQ-6j for ietf@ietf.org; Mon, 08 Oct 2007 07:40:13 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ieqxp-0000GW-RP for ietf@ietf.org; Mon, 08 Oct 2007 11:39:57 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Oct 2007 11:39:57 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Oct 2007 11:39:57 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: "Frank Ellermann" Date: Mon, 8 Oct 2007 13:37:34 +0200 Lines: 18 Message-ID: References: <2788466ED3E31C418E9ACC5C316615570534E4@mou1wnexmb09.vcorp.ad.vrsn.com> <6.2.5.6.2.20071004111028.031d08e0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org SM wrote: > Spam can pass SPF, Sender-ID and are even DK and DKIM signed=20 > nowadays. One can't blame spammers for not being early adopters. :-) > TMDA may cause backscatter. After an SPF PASS the "backscatter" by definition can't hit an innocent bystander. By the same definition any "backscatter" after an SPF FAIL hits an innocent bystander, and therefore is net abuse. > http://www.ietf.org/internet-drafts/draft-ietf-sipping-spam-05.txt )=20 > provides an interesting insight. It certainly explains why [18]...[21] are unnecessary for SIP ;-) Frank _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 09:18:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IesN0-0003Hl-69; Mon, 08 Oct 2007 09:10:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IesMx-0003AV-G8; Mon, 08 Oct 2007 09:09:59 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IesMx-0005zY-4E; Mon, 08 Oct 2007 09:09:59 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 470F533C57; Mon, 8 Oct 2007 06:05:59 -0700 (PDT) Date: Mon, 08 Oct 2007 06:05:59 -0700 From: Eric Rescorla To: ietf@ietf.org, iesg@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071008130559.470F533C57@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Andreas.Pashalidis@netlab.nec.de, Hannes.Tschofenig@nsn.com, Dirk.Kroeselberg@nsn.com, bersani_florent@yahoo.fr Subject: Comment on draft-tschofenig-eap-ikev2-15 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org As I was reading this document, I realized that I didn't understand what it was for. As I understand it, this document embeds IKEv2 into EAP. Why is this a good idea? As I understand the situation, EAP already supports a TLS-based authentication mechanism, which allows it to do both public-key based and asymmetric-key based authentication. So, what is IKEv2 bringing to the party here? Obviously, there are things IKEv2 is good for that TLS is not, but it's not clear to me that EAP is using any of that functionality. It seems to me that this document would be improved by a discussion up front of why it is desirable. -Ekr _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 09:18:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IesEh-0003w6-Nq; Mon, 08 Oct 2007 09:01:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IesEf-0003so-KO; Mon, 08 Oct 2007 09:01:25 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IesEf-0005j3-3r; Mon, 08 Oct 2007 09:01:25 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 3B71233C57; Mon, 8 Oct 2007 05:57:25 -0700 (PDT) Date: Mon, 08 Oct 2007 05:57:24 -0700 From: Eric Rescorla To: Jari Arkko In-Reply-To: <4709D647.7070004@piuha.net> References: <20071008014006.88BB233C21@delta.rtfm.com> <4709D647.7070004@piuha.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071008125725.3B71233C57@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ietf@ietf.org, iesg@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At Mon, 08 Oct 2007 10:03:35 +0300, Jari Arkko wrote: > But the issues with scheduling, lack of attention for important > topics, and low quality of new work proposals are real concerns. > I have a slightly different take on this than what you had above, > however. > > INT is probably the most troublesome area with respect > to scheduling, and I generally do not have any free slots > during an IETF meeting. However, I don't think this > implies we shouldn't consider new work. Its not as if > the Internet was ready and nothing new was ever > needed. We have a number of serious issues and > new demands to meet. But we need to actively manage > the set of things we work on. Some of the tools > we need to consider include actually stopping WGs > that have completed their task, rechartering, management > restructuring (e.g., merging groups), questioning > whether a non-delivering WG needs to continue > to exist and consume slots, and yes, even new work. I'm not saying that we shouldn't consider new work either, and we do consider new work under the current system. However, since the amount of work we can do is to a great degree constant, that means that any new work should be more important than whatever we're doing now. Making it easier to start new work (which is pretty much an explicit goal of this proposal) is likely to create a situation in which more new work gets done at the expense of current work. That might or might not be good depending on what one thinks of the current work. > > Finally, it's unclear the extent to which SGs are intended to > > transition directly to WGs without going through another BOF > > phase. I have two concerns here: > > > > 1. It will be hard for the IESG to deny "successful" SGs the right > > to form a WG. > > > > Saying NO is still going to be needed. Absolutely. But I think this is going to create a structural near-imperative to saying yes, in the same way that the IESG feels strong pressure to advance documents from chartered WGs, even if it's clear in retrospect that the output isn't of much value and probably shouldn't have been chartered in the first place. -Ekr _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 09:19:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IesSa-0006ya-1a; Mon, 08 Oct 2007 09:15:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IesSY-0006uw-1l for ietf@ietf.org; Mon, 08 Oct 2007 09:15:46 -0400 Received: from smtp.testbed.se ([80.86.78.228] helo=fw.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IesSR-0006G3-M5 for ietf@ietf.org; Mon, 08 Oct 2007 09:15:46 -0400 Received: from MailerDaemon by fw.testbed.se with local-bsmtp (Exim 4.63) (envelope-from ) id 1IesS9-00033m-Gw for ietf@ietf.org; Mon, 08 Oct 2007 15:15:21 +0200 Received: from h241n2fls33o874.telia.com ([213.66.47.241]:64086 helo=[192.168.0.100]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1IesS7-00033F-J6; Mon, 08 Oct 2007 15:15:19 +0200 Message-ID: <470A2D62.2090508@pi.se> Date: Mon, 08 Oct 2007 15:15:14 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eric Rescorla References: <20071008014006.88BB233C21@delta.rtfm.com> <4709D647.7070004@piuha.net> <20071008125725.3B71233C57@delta.rtfm.com> In-Reply-To: <20071008125725.3B71233C57@delta.rtfm.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-CTCH-RefID: str=0001.0A0B0202.470A2D68.00AF,ss=1,fgs=0 X-cff-SpamScore: 0(/) X-cff-SpamReport: ----- ----- Message is unknown to the spam scanner. X-cff-LastScanner: footer X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Jari Arkko , ietf@ietf.org, iesg@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Inline please, Eric Rescorla wrote: > At Mon, 08 Oct 2007 10:03:35 +0300, > Jari Arkko wrote: >> But the issues with scheduling, lack of attention for important >> topics, and low quality of new work proposals are real concerns. >> I have a slightly different take on this than what you had above, >> however. >> >> INT is probably the most troublesome area with respect >> to scheduling, and I generally do not have any free slots >> during an IETF meeting. However, I don't think this >> implies we shouldn't consider new work. Its not as if >> the Internet was ready and nothing new was ever >> needed. We have a number of serious issues and >> new demands to meet. But we need to actively manage >> the set of things we work on. Some of the tools >> we need to consider include actually stopping WGs >> that have completed their task, rechartering, management >> restructuring (e.g., merging groups), questioning >> whether a non-delivering WG needs to continue >> to exist and consume slots, and yes, even new work. > > I'm not saying that we shouldn't consider new work either, > and we do consider new work under the current system. However, > since the amount of work we can do is to a great degree constant, > that means that any new work should be more important than > whatever we're doing now. Making it easier to start new > work (which is pretty much an explicit goal of this proposal) > is likely to create a situation in which more new work gets > done at the expense of current work. That might or might > not be good depending on what one thinks of the current work. > > >>> Finally, it's unclear the extent to which SGs are intended to >>> transition directly to WGs without going through another BOF >>> phase. I have two concerns here: >>> >>> 1. It will be hard for the IESG to deny "successful" SGs the right >>> to form a WG. >>> >> Saying NO is still going to be needed. > > Absolutely. But I think this is going to create a structural > near-imperative to saying yes, in the same way that the IESG > feels strong pressure to advance documents from chartered > WGs, even if it's clear in retrospect that the output isn't > of much value and probably shouldn't have been chartered in > the first place. don't no if I and Ekr is saying the same thing, what I'm wary about is expectations created, an AD accepting a BoF creates expectations, creating a Study Group would do so to a larger extent /Loa > > -Ekr > > > > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 09:36:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iesh9-0008Qm-TW; Mon, 08 Oct 2007 09:30:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iesh7-0008LN-Cp; Mon, 08 Oct 2007 09:30:49 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iesh0-0007HA-JK; Mon, 08 Oct 2007 09:30:48 -0400 X-IronPort-AV: E=Sophos;i="4.21,242,1188792000"; d="scan'208";a="134246398" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 08 Oct 2007 09:30:27 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l98DURBM029005; Mon, 8 Oct 2007 09:30:27 -0400 Received: from elear-mac.local (rtp-vpn2-162.cisco.com [10.82.240.162]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l98DUQ2S024242; Mon, 8 Oct 2007 13:30:26 GMT Message-ID: <470A30CC.2030603@cisco.com> Date: Mon, 08 Oct 2007 15:29:48 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Eric Rescorla References: <20071008014006.88BB233C21@delta.rtfm.com> <4709D647.7070004@piuha.net> <20071008125725.3B71233C57@delta.rtfm.com> In-Reply-To: <20071008125725.3B71233C57@delta.rtfm.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=704; t=1191850227; x=1192714227; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Comments=20on=20draft-aboba-sg-experiment-02 |Sender:=20 |To:=20Eric=20Rescorla=20; bh=WJ17vxcNkdGoQMt+0Q/BlJNSxeejDdKk++Ow35cE4N4=; b=SP1/xh5PSeuIb0HXQZFanwaxr51u3yZmHSSW5i3SAnwVWSGIwTm79ZDlkOMkbydiOhtAadyR fcmupNoKpc7yRdxOjib8dCMwaTrhq8d23/EmfkT9OrrGEF8TXgX7MA8L; Authentication-Results: rtp-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Jari Arkko , ietf@ietf.org, iesg@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org If I understand the purpose of this experiment it would be to provide ADs some indication of level of interest and ability to succeed. I see no reason why we need to formalize this within the IETF. Furthemore, the terminology is problematic. We are overlapping a term that is commonly used by the ITU the way working group is used by the IETF. Let's not make the process any more confusing than it already is. Finally, milestones for such "study groups" seem to me inappropriate. It may be that a topic is uninteresting for quite a while and then picks up. ANY way to demonstrate that interest and ability to succeed should be sufficient, regardless of how much time has passed. Eliot _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 09:37:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeslV-0005Iw-Vg; Mon, 08 Oct 2007 09:35:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iem7R-0002o4-TG; Mon, 08 Oct 2007 02:29:33 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iem7F-00036P-GV; Mon, 08 Oct 2007 02:29:21 -0400 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l986THBh016291; Mon, 8 Oct 2007 02:29:17 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l986TEws026923; Mon, 8 Oct 2007 02:29:15 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Oct 2007 02:29:14 -0400 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" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Oct 2007 02:29:01 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-nfsv4-nfs-rdma-problem-statement-07.txt thread-index: AcgJdIMym3jWPGXVRtGTPcLor397aQ== To: , , , , X-OriginalArrivalTime: 08 Oct 2007 06:29:14.0299 (UTC) FILETIME=[8B9938B0:01C80974] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-Mailman-Approved-At: Mon, 08 Oct 2007 09:35:18 -0400 Cc: magnus.westerlund@ericsson.com, beepy@netapp.com, Black_David@emc.com Subject: Gen-ART review of draft-ietf-nfsv4-nfs-rdma-problem-statement-07.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-nfsv4-nfs-rdma-problem-statement-07.txt Reviewer: David L. Black Review Date: 7 October 2007 IETF LC End Date: 12 October 2007 IESG Telechat date: 18 October 2007 Summary: This draft is ready for publication as an Informational RFC. Comments: I am the chair of the RDDP working group. Since this draft proposes to apply the RDDP protocols to NFS, I have followed this draft and the related NFS RDMA protocol drafts in the nfsv4 WG and made comments on them in that forum. I have no further comments on this draft. idnits 2.04.16 runs clean (no issues found). Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 09:54:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ieswf-0003U9-KX; Mon, 08 Oct 2007 09:46:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ieswd-0003NO-6p; Mon, 08 Oct 2007 09:46:51 -0400 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IeswT-00085q-1W; Mon, 08 Oct 2007 09:46:51 -0400 X-IronPort-AV: E=Sophos;i="4.21,242,1188792000"; d="scan'208";a="64230625" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by de307622-de-outbound.net.avaya.com with ESMTP; 08 Oct 2007 09:46:26 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 8 Oct 2007 15:45:44 +0200 Message-ID: In-Reply-To: <470A30CC.2030603@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-aboba-sg-experiment-02 Thread-Index: AcgJr6PBIhHQE0zDRee5M+ZMT61uvgAAIxsw References: <20071008014006.88BB233C21@delta.rtfm.com> <4709D647.7070004@piuha.net><20071008125725.3B71233C57@delta.rtfm.com> <470A30CC.2030603@cisco.com> From: "Romascanu, Dan (Dan)" To: "Eliot Lear" , "Eric Rescorla" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Jari Arkko , ietf@ietf.org, iesg@ietf.org Subject: RE: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org The way I see it the problem that this proposal tries to solve is about helping the IESG and the community to make a better decision when the forming of the working group us discussed. It is not about bringing more work to the IETF, it is about making sure to a better extent that the right work is being brought into the IETF. In the absence of such a process what we see in many cases is the formation of ad-hoc groups, which is not necessarily bad - but why not charter them with a set of clear questions which may help the IESG and the whole community reach a more educated decision?=20 Regarding terminology, the term 'study group' is used in this proposal in a way similar to how the IEEE is using it.=20 Dan =20 =20 > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com]=20 > Sent: Monday, October 08, 2007 3:30 PM > To: Eric Rescorla > Cc: Jari Arkko; ietf@ietf.org; iesg@ietf.org > Subject: Re: Comments on draft-aboba-sg-experiment-02 >=20 > If I understand the purpose of this experiment it would be to=20 > provide ADs some indication of level of interest and ability=20 > to succeed. I see no reason why we need to formalize this=20 > within the IETF. Furthemore, the terminology is problematic.=20 > We are overlapping a term that is commonly used by the ITU=20 > the way working group is used by the IETF.=20 > Let's not make the process any more confusing than it already is. > Finally, milestones for such "study groups" seem to me inappropriate.=20 > It may be that a topic is uninteresting for quite a while and=20 > then picks up. ANY way to demonstrate that interest and=20 > ability to succeed should be sufficient, regardless of how=20 > much time has passed. >=20 > Eliot >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 12:35:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IevL7-0001mc-26; Mon, 08 Oct 2007 12:20:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IevL4-0001jo-9p; Mon, 08 Oct 2007 12:20:14 -0400 Received: from bay0-omc3-s1.bay0.hotmail.com ([65.54.246.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IevKx-0003qL-Um; Mon, 08 Oct 2007 12:20:14 -0400 Received: from BAY124-W9 ([207.46.11.172]) by bay0-omc3-s1.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Oct 2007 09:19:52 -0700 Message-ID: X-Originating-IP: [131.107.0.105] From: Gabriel Montenegro To: "Romascanu, Dan (Dan)" , Eliot Lear , Eric Rescorla Date: Mon, 8 Oct 2007 09:19:52 -0700 Importance: Normal In-Reply-To: References: <20071008014006.88BB233C21@delta.rtfm.com> <4709D647.7070004@piuha.net><20071008125725.3B71233C57@delta.rtfm.com> <470A30CC.2030603@cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 08 Oct 2007 16:19:52.0112 (UTC) FILETIME=[0E2E5B00:01C809C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: Jari Arkko , ietf@ietf.org, iesg@ietf.org Subject: RE: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0013411213==" Errors-To: ietf-bounces@ietf.org --===============0013411213== Content-Type: multipart/alternative; boundary="_a96d1000-81ca-467e-bd49-84673a87aed7_" --_a96d1000-81ca-467e-bd49-84673a87aed7_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have seen the functioning of SGs at the IEEE and agree that they can be u= seful, but I'm not sure about how it is being "translated" into the IETF> =20 It occurs to me that we don't need to invent a new process here. The IRTF h= ouses different types of "research" groups: some are meant to be long-lived, some are meant to meet during IETF, some never meet, etc.= There also are some RGs that have operated in a manner=20 similar to the study groups being proposed: NSRG (name spaces research grou= p), for example. And some that have been started as an alternative to petitions to form a WG, and which would seriously benefit fr= om having a tighter charter with specific milestones and expectations (e.g., p= 2prg RG).=20 =20 RGs are created with all sorts of different goals in mind. All that the IES= G needs here, I think, is to start an RG to probe further into a given issue, and keep it on a short leash along the lines stipulated for = the SG: e.g., milestones, meetings during IETF, explicit IESG liaison, etc. But the point is that these conditions need not be the same for each such R= G/SG. =20 I also think this is something useful the IRTF could do, as most often than= not, it actually doesn't do any research. The IESG wins, the IRTF wins, the IETF wins. =20 -gabriel > Date: Mon, 8 Oct 2007 15:45:44 +0200> From: dromasca@avaya.com> To: lear@= cisco.com; ekr@networkresonance.com> CC: jari.arkko@piuha.net; ietf@ietf.or= g; iesg@ietf.org> Subject: RE: Comments on draft-aboba-sg-experiment-02> > = The way I see it the problem that this proposal tries to solve is about> he= lping the IESG and the community to make a better decision when the> formin= g of the working group us discussed. It is not about bringing more> work to= the IETF, it is about making sure to a better extent that the> right work = is being brought into the IETF. In the absence of such a> process what we s= ee in many cases is the formation of ad-hoc groups,> which is not necessari= ly bad - but why not charter them with a set of> clear questions which may = help the IESG and the whole community reach a> more educated decision? > > = Regarding terminology, the term 'study group' is used in this proposal> in = a way similar to how the IEEE is using it. > > Dan> > > > > > -----Original= Message-----> > From: Eliot Lear [mailto:lear@cisco.com] > > Sent: Monday,= October 08, 2007 3:30 PM> > To: Eric Rescorla> > Cc: Jari Arkko; ietf@ietf= .org; iesg@ietf.org> > Subject: Re: Comments on draft-aboba-sg-experiment-0= 2> > > > If I understand the purpose of this experiment it would be to > > = provide ADs some indication of level of interest and ability > > to succeed= . I see no reason why we need to formalize this > > within the IETF. Furthe= more, the terminology is problematic. > > We are overlapping a term that is= commonly used by the ITU > > the way working group is used by the IETF. > = > Let's not make the process any more confusing than it already is.> > Fina= lly, milestones for such "study groups" seem to me inappropriate. > > It ma= y be that a topic is uninteresting for quite a while and > > then picks up.= ANY way to demonstrate that interest and > > ability to succeed should be = sufficient, regardless of how > > much time has passed.> > > > Eliot> > > >= _______________________________________________> Ietf mailing list> Ietf@i= etf.org> https://www1.ietf.org/mailman/listinfo/ietf _________________________________________________________________ Help yourself to FREE treats served up daily at the Messenger Caf=E9. Stop = by today. http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=3DTXT_TAGLM_Oc= tWLtagline= --_a96d1000-81ca-467e-bd49-84673a87aed7_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have seen the functioning of SGs at the IEE= E and agree that they can be useful, but I'm not sure about how it is being= "translated" into the IETF>
 
It occurs to me that we don't need to invent a new process here. The IRTF h= ouses different types of "research" groups: some are meant
to be long-lived, some are meant to meet during IETF, some never meet, etc.= There also are some RGs that have operated in a manner
similar to the study groups being proposed: NSRG (name spaces research grou= p), for example. And some that have been started as an
alternative to petitions to form a WG, and which would seriously benef= it from
having a tighter charter with specific milestones and expectations (e.g., p= 2prg RG).
 
RGs are created with all sorts of different goals in mind. All that the IES= G needs here, I think, is to start an RG to probe further into
a given issue, and keep it on a short leash along the lines stipulated for = the SG: e.g., milestones, meetings during IETF, explicit IESG liaison, etc.=
But the point is that these conditions need not be the same for each such R= G/SG.
 
I also think this is something useful the IRTF could do, as most often than= not, it actually doesn't do any research. The IESG wins, the IRTF wins, the IETF wins.
 
-gabriel




> Date: Mon, 8 Oct 2007 15:45:44 +0200
> From: dromasca@avaya.com<= BR>> To: lear@cisco.com; ekr@networkresonance.com
> CC: jari.arkko= @piuha.net; ietf@ietf.org; iesg@ietf.org
> Subject: RE: Comments on d= raft-aboba-sg-experiment-02
>
> The way I see it the problem t= hat this proposal tries to solve is about
> helping the IESG and the = community to make a better decision when the
> forming of the working= group us discussed. It is not about bringing more
> work to the IETF= , it is about making sure to a better extent that the
> right work is= being brought into the IETF. In the absence of such a
> process what= we see in many cases is the formation of ad-hoc groups,
> which is n= ot necessarily bad - but why not charter them with a set of
> clear q= uestions which may help the IESG and the whole community reach a
> mo= re educated decision?
>
> Regarding terminology, the term 'st= udy group' is used in this proposal
> in a way similar to how the IEE= E is using it.
>
> Dan
>
>
>
> > > -----Original Message-----
> > From: Eliot Lear [mailto= :lear@cisco.com]
> > Sent: Monday, October 08, 2007 3:30 PM
&g= t; > To: Eric Rescorla
> > Cc: Jari Arkko; ietf@ietf.org; iesg@= ietf.org
> > Subject: Re: Comments on draft-aboba-sg-experiment-02=
> >
> > If I understand the purpose of this experiment = it would be to
> > provide ADs some indication of level of intere= st and ability
> > to succeed. I see no reason why we need to for= malize this
> > within the IETF. Furthemore, the terminology is p= roblematic.
> > We are overlapping a term that is commonly used b= y the ITU
> > the way working group is used by the IETF.
>= > Let's not make the process any more confusing than it already is.
= > > Finally, milestones for such "study groups" seem to me inappropri= ate.
> > It may be that a topic is uninteresting for quite a whil= e and
> > then picks up. ANY way to demonstrate that interest and=
> > ability to succeed should be sufficient, regardless of how <= BR>> > much time has passed.
> >
> > Eliot
>= >
>
> _______________________________________________
= > Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/= mailman/listinfo/ietf



Help yourself to FREE treats serve= d up daily at the Messenger Caf=E9. = Stop by today! = --_a96d1000-81ca-467e-bd49-84673a87aed7_-- --===============0013411213== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0013411213==-- From ietf-bounces@ietf.org Mon Oct 08 13:40:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IewPh-0004wU-6R; Mon, 08 Oct 2007 13:29:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IewPf-0004ky-NR; Mon, 08 Oct 2007 13:29:03 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IewPd-0000fy-4N; Mon, 08 Oct 2007 13:29:01 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1AA931986B9; Mon, 8 Oct 2007 20:29:00 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9CE1019866A; Mon, 8 Oct 2007 20:28:59 +0300 (EEST) Message-ID: <470A68DB.6010702@piuha.net> Date: Mon, 08 Oct 2007 20:28:59 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Gabriel Montenegro References: <20071008014006.88BB233C21@delta.rtfm.com> <4709D647.7070004@piuha.net><20071008125725.3B71233C57@delta.rtfm.com> <470A30CC.2030603@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: iesg@ietf.org, "Romascanu, Dan \(Dan\)" , Eliot Lear , ietf@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Gabriel, > It occurs to me that we don't need to invent a new process here. The > IRTF houses different types of "research" groups: We don't _have_ to invent new process -- in addition to IRTF RGs, there's obviously the default option of keeping post-BOF / pre-WG efforts outside the formal IETF process until they have reached the bar for full WG approval. However, the question is what makes sense and what is the best tool for the task. We certainly could use RGs too -- and we do. RRG, HIP RG, etc. However, I think this approach is suitable for groups that have a significant research component. It seems less suitable for groups that are merely looking for a standard in the engineering space. (And I know I'm spending a lot of time with the new work proposals; I'm not sure Aaron & co would be so happy to receive new groups unless they really were about research.) Jari _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 13:40:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IewX7-0003m8-Pl; Mon, 08 Oct 2007 13:36:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IewX6-0003k9-0f; Mon, 08 Oct 2007 13:36:44 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IewWw-0000sF-EB; Mon, 08 Oct 2007 13:36:35 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JPL0072HSWX2L@usaga01-in.huawei.com>; Mon, 08 Oct 2007 10:36:33 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JPL003OMSWS0F@usaga01-in.huawei.com>; Mon, 08 Oct 2007 10:36:33 -0700 (PDT) Date: Mon, 08 Oct 2007 12:36:12 -0500 From: Spencer Dawkins To: ietf@ietf.org Message-id: <01b501c809d1$b8a38c40$6a01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <20071008014006.88BB233C21@delta.rtfm.com> <4709D647.7070004@piuha.net> <20071008125725.3B71233C57@delta.rtfm.com> <470A30CC.2030603@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 919b3965bd46f7460d234f848680b238 Cc: iesg@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0536943316==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============0536943316== Content-type: multipart/alternative; boundary="Boundary_(ID_l1xQ+NNj/VxZigO7TjxSUQ)" This is a multi-part message in MIME format. --Boundary_(ID_l1xQ+NNj/VxZigO7TjxSUQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable I have been somewhat troubled at the discussion about the SG draft and = proposed experiment, and I think part of the reason is that there's a = range of leashes being envisioned, with everything from "study groups = are where the villagers riot" to "the process for forming a study group = is indistinguishable from forming a working group". If the SG process gets sufficiently close to the WG process, I don't see = the point. If you have to be able to convince a reluctant AD, why would = you not request a BOF? At least within RAI, the running code is "meet as = a SIPPING ad hoc, either at lunch or at 10:30 PM", and there doesn't = seem to be much process wrapped around that. There are enough positive things about Gab's suggestion (to use the IRTF = as a home for WG explorations, in addition to research) that I'd like to = see a proposal for this alternative. Dan (and Gab) have been around the IEEE a lot more than I have, but one = of the translation issues I'm wondering about is that the go/no-go = decision in IEEE seems a lot more straighforward in IEEE than in IETF - = if you have a plausible PAR and reasonable answers to the Five Criteria, = doesn't the decision tend toward "go"?=20 At least in RAI, we've been approving new working groups fairly = frequently, but there have been times, especially in specific areas, = where there was a lot of resistance to chartering new working groups, = based solely on the number of existing working groups and the load that = places on ADs = (http://www.watersprings.org/pub/id/draft-klensin-overload-00.txt might = have been outside the mainstream, but I don't think John and Marshall = were WAY outside the mainstream in their 2002 draft). I am intrigued by the idea that we can't charter new work because we = have too many working groups now, because a quick examination of my own = area shows about five-or-so working groups that are amazingly close to = closing down, but they do not seem to close down, IETF after IETF. Is = this different in other areas? I would ask people to spend a little time thinking about the idea that = the number of slots in an IETF week should determine the number of = chartered working groups. That seems like the tail wagging the dog. Spencer ----- Original Message -----=20 From: Gabriel Montenegro=20 To: Romascanu, Dan (Dan) ; Eliot Lear ; Eric Rescorla=20 Cc: Jari Arkko ; ietf@ietf.org ; iesg@ietf.org=20 Sent: Monday, October 08, 2007 11:19 AM Subject: RE: Comments on draft-aboba-sg-experiment-02 I have seen the functioning of SGs at the IEEE and agree that they can = be useful, but I'm not sure about how it is being "translated" into the = IETF> =20 It occurs to me that we don't need to invent a new process here. The = IRTF houses different types of "research" groups: some are meant to be long-lived, some are meant to meet during IETF, some never meet, = etc. There also are some RGs that have operated in a manner=20 similar to the study groups being proposed: NSRG (name spaces research = group), for example. And some that have been started as an alternative to petitions to form a WG, and which would seriously = benefit from having a tighter charter with specific milestones and expectations = (e.g., p2prg RG).=20 =20 RGs are created with all sorts of different goals in mind. All that = the IESG needs here, I think, is to start an RG to probe further into a given issue, and keep it on a short leash along the lines stipulated = for the SG: e.g., milestones, meetings during IETF, explicit IESG = liaison, etc. But the point is that these conditions need not be the same for each = such RG/SG. =20 I also think this is something useful the IRTF could do, as most often = than not, it actually doesn't do any research. The IESG wins, the IRTF = wins, the IETF wins. =20 -gabriel -------------------------------------------------------------------------= ----- > Date: Mon, 8 Oct 2007 15:45:44 +0200 > From: dromasca@avaya.com > To: lear@cisco.com; ekr@networkresonance.com > CC: jari.arkko@piuha.net; ietf@ietf.org; iesg@ietf.org > Subject: RE: Comments on draft-aboba-sg-experiment-02 >=20 > The way I see it the problem that this proposal tries to solve is = about > helping the IESG and the community to make a better decision when = the > forming of the working group us discussed. It is not about bringing = more > work to the IETF, it is about making sure to a better extent that = the > right work is being brought into the IETF. In the absence of such a > process what we see in many cases is the formation of ad-hoc groups, > which is not necessarily bad - but why not charter them with a set = of > clear questions which may help the IESG and the whole community = reach a > more educated decision?=20 >=20 > Regarding terminology, the term 'study group' is used in this = proposal > in a way similar to how the IEEE is using it.=20 >=20 > Dan >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Eliot Lear [mailto:lear@cisco.com]=20 > > Sent: Monday, October 08, 2007 3:30 PM > > To: Eric Rescorla > > Cc: Jari Arkko; ietf@ietf.org; iesg@ietf.org > > Subject: Re: Comments on draft-aboba-sg-experiment-02 > >=20 > > If I understand the purpose of this experiment it would be to=20 > > provide ADs some indication of level of interest and ability=20 > > to succeed. I see no reason why we need to formalize this=20 > > within the IETF. Furthemore, the terminology is problematic.=20 > > We are overlapping a term that is commonly used by the ITU=20 > > the way working group is used by the IETF.=20 > > Let's not make the process any more confusing than it already is. > > Finally, milestones for such "study groups" seem to me = inappropriate.=20 > > It may be that a topic is uninteresting for quite a while and=20 > > then picks up. ANY way to demonstrate that interest and=20 > > ability to succeed should be sufficient, regardless of how=20 > > much time has passed. > >=20 > > Eliot > >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf -------------------------------------------------------------------------= ----- Help yourself to FREE treats served up daily at the Messenger Caf=E9. = Stop by today!=20 -------------------------------------------------------------------------= ----- _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --Boundary_(ID_l1xQ+NNj/VxZigO7TjxSUQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
I have been somewhat troubled at the discussion = about the=20 SG draft and proposed experiment, and I think part of the reason is that = there's=20 a range of leashes being envisioned, with everything from "study groups = are=20 where the villagers riot" to "the process for forming a study = group is=20 indistinguishable from forming a working group".
 
If the SG process gets sufficiently close = to the WG=20 process, I don't see the point. If you have to be able to convince a = reluctant=20 AD, why would you not request a BOF? At least within RAI, the running = code is=20 "meet as a SIPPING ad hoc, either at lunch or at 10:30 PM", and there = doesn't=20 seem to be much process wrapped around that.
 
There are enough positive things about Gab's = suggestion=20 (to use the IRTF as a home for WG explorations, in addition to research) = that=20 I'd like to see a proposal for this alternative.
 
Dan (and Gab) have been around the IEEE a lot = more than I=20 have, but one of the translation issues I'm wondering about is that the = go/no-go=20 decision in IEEE seems a lot more straighforward in IEEE than in IETF - = if you=20 have a plausible PAR and reasonable answers to the Five Criteria,=20 doesn't the decision tend toward "go"?
 
At least in RAI, we've been approving new = working groups=20 fairly frequently, but there have been times, especially in specific = areas,=20 where there was a lot of resistance to chartering new working groups, = based=20 solely on the number of existing working groups and the load that places = on ADs=20 (http://www.watersprings.org/pub/id/draft-klensin-overload-00.txt&nbs= p;might=20 have been outside the mainstream, but I don't think John and Marshall = were WAY=20 outside the mainstream in their 2002 draft).
 
I am intrigued by the idea that we can't charter = new work=20 because we have too many working groups now, because a quick examination = of my=20 own area shows about five-or-so working groups that are amazingly close = to=20 closing down, but they do not seem to close down, IETF after IETF. Is = this=20 different in other areas?
 
I would ask people to spend a little time = thinking about=20 the idea that the number of slots in an IETF week should determine the = number of=20 chartered working groups. That seems like the tail wagging the = dog.
 
Spencer
----- Original Message -----
From:=20 Gabriel Montenegro =
To: Romascanu, Dan (Dan) ; Eliot Lear ; = Eric=20 Rescorla
Sent: Monday, October 08, 2007 = 11:19=20 AM
Subject: RE: Comments on=20 draft-aboba-sg-experiment-02


I have seen the functioning of SGs at the IEEE and = agree=20 that they can be useful, but I'm not sure about how it is being = "translated"=20 into the IETF>
 
It occurs to me that we don't need to = invent a=20 new process here. The IRTF houses different types of "research" = groups: some=20 are meant
to be long-lived, some are meant to meet during IETF, = some never=20 meet, etc. There also are some RGs that have operated in a manner =
similar=20 to the study groups being proposed: NSRG (name spaces research group), = for=20 example. And some that have been started as an
alternative=20 to petitions to form a WG, and which would seriously benefit=20 from
having a tighter charter with specific milestones and = expectations=20 (e.g., p2prg RG).
 
RGs are created with all sorts of = different=20 goals in mind. All that the IESG needs here, I think, is to start an = RG to=20 probe further into
a given issue, and keep it on a short leash = along the=20 lines stipulated for the SG: e.g., milestones, meetings during IETF, = explicit=20 IESG liaison, etc.
But the point is that these conditions need not = be the=20 same for each such RG/SG.
 
I also think this is something = useful=20 the IRTF could do, as most often than not, it actually doesn't do any=20 research. The IESG wins, the IRTF wins,
the IETF=20 wins.
 
-gabriel




> Date: Mon, 8 Oct 2007 15:45:44 +0200
> From:=20 dromasca@avaya.com
> To: lear@cisco.com;=20 ekr@networkresonance.com
> CC: jari.arkko@piuha.net; = ietf@ietf.org;=20 iesg@ietf.org
> Subject: RE: Comments on=20 draft-aboba-sg-experiment-02
>
> The way I see it the = problem=20 that this proposal tries to solve is about
> helping the IESG = and the=20 community to make a better decision when the
> forming of the = working=20 group us discussed. It is not about bringing more
> work to the = IETF, it=20 is about making sure to a better extent that the
> right work is = being=20 brought into the IETF. In the absence of such a
> process what = we see in=20 many cases is the formation of ad-hoc groups,
> which is not = necessarily=20 bad - but why not charter them with a set of
> clear questions = which may=20 help the IESG and the whole community reach a
> more educated = decision?=20
>
> Regarding terminology, the term 'study group' is = used in=20 this proposal
> in a way similar to how the IEEE is using it. =
>=20
> Dan
>
>
>
>
> > = -----Original=20 Message-----
> > From: Eliot Lear [mailto:lear@cisco.com] =
>=20 > Sent: Monday, October 08, 2007 3:30 PM
> > To: Eric=20 Rescorla
> > Cc: Jari Arkko; ietf@ietf.org; = iesg@ietf.org
>=20 > Subject: Re: Comments on draft-aboba-sg-experiment-02
> = >=20
> > If I understand the purpose of this experiment it would = be to=20
> > provide ADs some indication of level of interest and = ability=20
> > to succeed. I see no reason why we need to formalize = this=20
> > within the IETF. Furthemore, the terminology is = problematic.=20
> > We are overlapping a term that is commonly used by the = ITU=20
> > the way working group is used by the IETF.
> > = Let's=20 not make the process any more confusing than it already is.
> = >=20 Finally, milestones for such "study groups" seem to me inappropriate. =
>=20 > It may be that a topic is uninteresting for quite a while and =
>=20 > then picks up. ANY way to demonstrate that interest and
> = >=20 ability to succeed should be sufficient, regardless of how
> = > much=20 time has passed.
> >
> > Eliot
> > =
>=20
> _______________________________________________
> Ietf = mailing=20 list
> Ietf@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/ietf



Help yourself to FREE treats served up daily at the Messenger Caf=E9. = Stop by today!=20


_______________________________________________
Ietf mailing = = list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
<= /BLOCKQUOTE> --Boundary_(ID_l1xQ+NNj/VxZigO7TjxSUQ)-- --===============0536943316== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0536943316==-- From ietf-bounces@ietf.org Mon Oct 08 13:49:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IewfA-0000qU-Ri; Mon, 08 Oct 2007 13:45:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iewf9-0000g3-12; Mon, 08 Oct 2007 13:45:03 -0400 Received: from open.nlnetlabs.nl ([2001:7b8:206:1::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iewf2-0007BO-Qj; Mon, 08 Oct 2007 13:45:03 -0400 Received: from [127.0.0.1] (open.nlnetlabs.nl [213.154.224.1]) by open.nlnetlabs.nl (8.14.1/8.13.8) with ESMTP id l98HigX0068451; Mon, 8 Oct 2007 19:44:42 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: "Olaf M. Kolkman" Date: Mon, 8 Oct 2007 13:44:41 -0400 To: ietf@ietf.org X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, score=-105.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on open.nlnetlabs.nl X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: IAB IAB Subject: Re: Last Call: draft-aboba-sg-experiment (Experiment in Study Group Formation within the Internet Engineering Task Force (IETF)) to Experimental RFC X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2066900302==" Errors-To: ietf-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2066900302== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-5-957400418" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-5-957400418 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear Colleagues, The IAB has discussed the study group experiment proposed in draft- aboba-sg-experiment-02.txt. The IAB does not oppose a scoped experiment. However, As the IAB reviews BOFs and WG charters (see RFC 2850 section 2.1) as part of its architectural oversight function, we believe that the IAB should also review SG charters. We therefore recommend that such a statement be added to the document if there were consensus for the proposed experiment. We also recommend that the evaluation criteria for success are made clear before the start of the experiment. On behalf of the IAB, --Olaf Kolkman --Apple-Mail-5-957400418 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: This message is locally signed. iD8DBQFHCmyJtN/ca3YJIocRAqjeAJ41zX0Ex8SCtyKyoZXege3UQZj7cgCg1I4f e5/uQq360Ylvn7xm2ad1DI4= =6FHY -----END PGP SIGNATURE----- --Apple-Mail-5-957400418-- --===============2066900302== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============2066900302==-- From ietf-bounces@ietf.org Mon Oct 08 14:22:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iex6z-0000VW-MU; Mon, 08 Oct 2007 14:13:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iex6x-0000Ui-JG; Mon, 08 Oct 2007 14:13:47 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iex6w-0002Ei-Sm; Mon, 08 Oct 2007 14:13:47 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l98IDj4O014461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 Oct 2007 11:13:45 -0700 Received: from [10.50.64.199] (qconnect-10-50-64-199.qualcomm.com [10.50.64.199]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l98IDixZ024464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Oct 2007 11:13:44 -0700 (PDT) Message-ID: <470A735E.9050807@qualcomm.com> Date: Mon, 08 Oct 2007 11:13:50 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jari Arkko References: <20071008014006.88BB233C21@delta.rtfm.com> <4709D647.7070004@piuha.net> In-Reply-To: <4709D647.7070004@piuha.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: ietf@ietf.org, iesg@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Thanks Jari, Eric. Some notes inline ... On 10/8/2007 12:03 AM, Jari Arkko wrote: > >> Currently this >> document simply has it at the IESG's discretion: >> >> If at any point during the Working Group formation process, including >> after a first or second BoF session, interest within the IETF and >> end-user community has been demonstrated, but one or more Working >> Group formation criteria outlined in [RFC2418] Section 2.1 has not >> yet been met, the IESG MAY propose that a Study Group be formed. >> >> This seems ripe for abuse of the kind I outlined above. IMO this >> document would benefit from a clearer statement of the conditions >> under which it was appropriate to form an SG, thus reducing pressure >> on ADs. I am not sure what kind of "abuse" you are worried about Eric. Please clarify. > > This would be helpful. Bernard, Laksminath, any ideas? I don't think we should make it algorithmic and instead should leave the steering, direction and judgment aspects of an IESG job intact. That said, my expectation is that the sponsoring AD is responsible for considering the general guidance the draft offers and making a decision on whether to form an SG, suggest a(nother) BoF session, form a WG, or say that the work is not appropriate at the IETF at the time, etc. The motivating text is: "In some situations, while interest on the part of IETF participants and end-users may be evident, and the relevance to the Internet community may be demonstrated, the answer to other questions (such as an understanding of existing work, achievability of goals, or overlap with existing working groups or standards bodies) may not be as clear. " The guiding text is: "Study Groups MAY be formed by the IESG when there is evidence of clear interest in a topic on the part of IETF participants and end-users, but other criteria relating to Working Group formation (including creation of a satisfactory Charter) have not yet been met." We could make the guiding text more precise (perhaps include some specific criteria), if that is what the community wants. > >> Arguably, SG formation should be subject to an IETF LC in the >> same way that WG formation is. >> > > Hm. I believed this was already the case. SGs are subject to exactly > the same process as WGs, and I was assuming that like, WG formation, > SG formation would include discussion in the IESG, consultation > with the IAB, and IETF Last Call. > > Perhaps this needs clarification. Authors? We could clarify, but the intent is to follow the WG process for formation. > >> Finally, it's unclear the extent to which SGs are intended to >> transition directly to WGs without going through another BOF >> phase. I have two concerns here: >> >> 1. It will be hard for the IESG to deny "successful" SGs the right >> to form a WG. >> > > Saying NO is still going to be needed. > >> 2. BOFs are a defined in-person event at which everyone knows that >> WG formation is being considered. This provides an opportunity >> for public high bandwidth discussion of that topic. I don't >> think an LC on the IETF list is an adequate substitute. >> > > Good point. Bernard, Laksminath -- any ideas here? I disagree with Eric here. I believe that we are not a meeting based organization and should be making more of these important decisions via email where we have more time to consider the proposals carefully. My observation based on some of the BoFs I have been involved with recently is that far too much time is wasted between two BoF sessions. With little or no discussion between sessions, a good portion of the meeting time is used to get on the same page (again). That aside, if the sponsoring AD believes that the in-person events are important, they may suggest a BoF as a first step to bringing new work to the IETF. An SG may come after that. regards, Lakshminath > >> 3. The experiment be structured to do the minimal amount of harm >> if it fails. >> > > In IESG review of this proposal, one of the things we talked about was > whether there is a way to limit this experiment so that we can indeed > test the idea but avoid impacting everyone. One of the suggestions > was to set a limit on the number of SGs during the experiment to > some low value, such as three. I would be in favor of this limitation. > > Jari > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 14:42:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IexMT-0007sE-KD; Mon, 08 Oct 2007 14:29:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IexMR-0007rr-UJ; Mon, 08 Oct 2007 14:29:47 -0400 Received: from [198.152.13.100] (helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IexML-000052-6k; Mon, 08 Oct 2007 14:29:47 -0400 X-IronPort-AV: E=Sophos;i="4.21,244,1188792000"; d="scan'208,217";a="72850818" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-outbound.avaya.com with ESMTP; 08 Oct 2007 14:28:48 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 8 Oct 2007 20:28:06 +0200 Message-ID: In-Reply-To: <01b501c809d1$b8a38c40$6a01a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-aboba-sg-experiment-02 Thread-Index: AcgJ0h4jVAzinam5TiOxf+fQxHWBTwABgAdA References: <20071008014006.88BB233C21@delta.rtfm.com><4709D647.7070004@piuha.net> <20071008125725.3B71233C57@delta.rtfm.com><470A30CC.2030603@cisco.com> <01b501c809d1$b8a38c40$6a01a8c0@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "Spencer Dawkins" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: iesg@ietf.org Subject: RE: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1071284066==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============1071284066== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C809D8.F90D8083" This is a multi-part message in MIME format. ------_=_NextPart_001_01C809D8.F90D8083 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, and this translates in IETF speech into having a viable technical concept which is caught in a sound charter, proved resources and community interest plus early code and individual I-Ds as very desirable additions.=20 =20 A SG process would not replace those, but could help achieve them in a more structured manner, or alternatively help the community and the IESG realize that it's not the case or the time for this work to happen.=20 =20 Dan =20 =20 =20 =20 ________________________________ From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 =09 =20 Dan (and Gab) have been around the IEEE a lot more than I have, but one of the translation issues I'm wondering about is that the go/no-go decision in IEEE seems a lot more straighforward in IEEE than in IETF - if you have a plausible PAR and reasonable answers to the Five Criteria, doesn't the decision tend toward "go"?=20 =20 =20 ------_=_NextPart_001_01C809D8.F90D8083 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yes, and this translates in IETF speech into = having a=20 viable technical concept which is caught in a sound charter, proved = resources=20 and community interest plus early code and individual = I-Ds as=20 very desirable additions.
 
A=20 SG process would not replace those, but could help achieve them in a = more=20 structured manner, or alternatively help the community and the IESG = realize that=20 it's not the case or the time for this work to happen.=20
 
Dan
 
 
 
 


From: Spencer Dawkins = [mailto:spencer@mcsr-labs.org]=20
 
Dan (and Gab) have been around the IEEE a lot = more than=20 I have, but one of the translation issues I'm wondering about is that = the=20 go/no-go decision in IEEE seems a lot more straighforward in IEEE than = in IETF=20 - if you have a plausible PAR and reasonable answers to the Five = Criteria,=20 doesn't the decision tend toward "go"?
 
 
------_=_NextPart_001_01C809D8.F90D8083-- --===============1071284066== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============1071284066==-- From ietf-bounces@ietf.org Mon Oct 08 14:42:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IexQn-0006x1-Gd; Mon, 08 Oct 2007 14:34:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IexQl-0006wS-Qv; Mon, 08 Oct 2007 14:34:15 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IexQl-0002iK-1p; Mon, 08 Oct 2007 14:34:15 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 6D04B33C21; Mon, 8 Oct 2007 11:30:14 -0700 (PDT) Date: Mon, 08 Oct 2007 11:30:13 -0700 From: Eric Rescorla To: Lakshminath Dondeti In-Reply-To: <470A735E.9050807@qualcomm.com> References: <20071008014006.88BB233C21@delta.rtfm.com> <4709D647.7070004@piuha.net> <470A735E.9050807@qualcomm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071008183014.6D04B33C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: ietf@ietf.org, Jari Arkko , iesg@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenTh
Yes, and this translates in IETF speech into = having a=20 viable technical concept which is caught in a sound charter, proved = resources=20 and community interest plus early code and individual = I-Ds as=20 very desirable additions.
 
A=20 SG process would not replace those, but could help achieve them in a = more=20 structured manner, or alternatively help the community and the IESG = realize that=20 it's not the case or the time for this work to happen.=20
 
Dan
 
 
 
 


From: Spencer Dawkins = [mailto:spencer@mcsr-labs.org]=20
 
Dan (and Gab) have been around the IEEE a lot = more than=20 I have, but one of the translation issues I'm wondering about is that = the=20 go/no-go decision in IEEE seems a lot more straighforward in IEEE than = in IETF=20 - if you have a plausible PAR and reasonable answers to the Five = Criteria,=20 doesn't the decision tend toward "go"?
 
 
------_=_NextPart_001_01C809D8.F90D8083-- --===============1071284066== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============1071284066==-- From ietf-bounces@ietf.org Mon Oct 08 14:42:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IexQn-0006x1-Gd; Mon, 08 Oct 2007 14:34:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IexQl-0006wS-Qv; Mon, 08 Oct 2007 14:34:15 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IexQl-0002iK-1p; Mon, 08 Oct 2007 14:34:15 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 6D04B33C21; Mon, 8 Oct 2007 11:30:14 -0700 (PDT) Date: Mon, 08 Oct 2007 11:30:13 -0700 From: Eric Rescorla To: Lakshminath Dondeti In-Reply-To: <470A735E.9050807@qualcomm.com> References: <20071008014006.88BB233C21@delta.rtfm.com> <4709D647.7070004@piuha.net> <470A735E.9050807@qualcomm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071008183014.6D04B33C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: ietf@ietf.org, Jari Arkko , iesg@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At Mon, 08 Oct 2007 11:13:50 -0700, Lakshminath Dondeti wrote: > > Thanks Jari, Eric. Some notes inline ... > > On 10/8/2007 12:03 AM, Jari Arkko wrote: > > > > >> Currently this > >> document simply has it at the IESG's discretion: > >> > >> If at any point during the Working Group formation process, including > >> after a first or second BoF session, interest within the IETF and > >> end-user community has been demonstrated, but one or more Working > >> Group formation criteria outlined in [RFC2418] Section 2.1 has not > >> yet been met, the IESG MAY propose that a Study Group be formed. > >> > >> This seems ripe for abuse of the kind I outlined above. IMO this > >> document would benefit from a clearer statement of the conditions > >> under which it was appropriate to form an SG, thus reducing pressure > >> on ADs. > > I am not sure what kind of "abuse" you are worried about Eric. Please > clarify. You trimmed out the section where I explained: A related issue is that this puts pressure on ADs to approve SGs for efforts that they would ordinarily simply refuse WGs for. I.e., "OK, so you won't give us a WG, how about a SG". Currently this document simply has it at the IESG's discretion: To clarify, the reasonably high bar for WG formation plus the two BOF rule has the effect of enabling ADs to say so "No" to work that really is not ready. The concern is that efforts which are denied WGs will turn around and ask for an SG and that it will be difficult to turn them down even though they really need to go back to the drawing board. > > This would be helpful. Bernard, Laksminath, any ideas? > > I don't think we should make it algorithmic and instead should leave the > steering, direction and judgment aspects of an IESG job intact. Nor did I argue differently. However, there is a difference between exercising judgement and unguided sole discretion. My concern is that the language in the draft errs to far in the latter direction. > We could make the guiding text more precise (perhaps include some > specific criteria), if that is what the community wants. Yes, I think this would be valuable. > >> Arguably, SG formation should be subject to an IETF LC in the > >> same way that WG formation is. > >> > > > > Hm. I believed this was already the case. SGs are subject to exactly > > the same process as WGs, and I was assuming that like, WG formation, > > SG formation would include discussion in the IESG, consultation > > with the IAB, and IETF Last Call. > > > > Perhaps this needs clarification. Authors? > > We could clarify, but the intent is to follow the WG process for formation. In that case, I think it needs clarification. > >> Finally, it's unclear the extent to which SGs are intended to > >> transition directly to WGs without going through another BOF > >> phase. I have two concerns here: > >> > >> 1. It will be hard for the IESG to deny "successful" SGs the right > >> to form a WG. > >> > > > > Saying NO is still going to be needed. > > > >> 2. BOFs are a defined in-person event at which everyone knows that > >> WG formation is being considered. This provides an opportunity > >> for public high bandwidth discussion of that topic. I don't > >> think an LC on the IETF list is an adequate substitute. > >> > > > > Good point. Bernard, Laksminath -- any ideas here? > > I disagree with Eric here. I believe that we are not a meeting based > organization and should be making more of these important decisions via > email where we have more time to consider the proposals carefully. Well, you might ere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At Mon, 08 Oct 2007 11:13:50 -0700, Lakshminath Dondeti wrote: > > Thanks Jari, Eric. Some notes inline ... > > On 10/8/2007 12:03 AM, Jari Arkko wrote: > > > > >> Currently this > >> document simply has it at the IESG's discretion: > >> > >> If at any point during the Working Group formation process, including > >> after a first or second BoF session, interest within the IETF and > >> end-user community has been demonstrated, but one or more Working > >> Group formation criteria outlined in [RFC2418] Section 2.1 has not > >> yet been met, the IESG MAY propose that a Study Group be formed. > >> > >> This seems ripe for abuse of the kind I outlined above. IMO this > >> document would benefit from a clearer statement of the conditions > >> under which it was appropriate to form an SG, thus reducing pressure > >> on ADs. > > I am not sure what kind of "abuse" you are worried about Eric. Please > clarify. You trimmed out the section where I explained: A related issue is that this puts pressure on ADs to approve SGs for efforts that they would ordinarily simply refuse WGs for. I.e., "OK, so you won't give us a WG, how about a SG". Currently this document simply has it at the IESG's discretion: To clarify, the reasonably high bar for WG formation plus the two BOF rule has the effect of enabling ADs to say so "No" to work that really is not ready. The concern is that efforts which are denied WGs will turn around and ask for an SG and that it will be difficult to turn them down even though they really need to go back to the drawing board. > > This would be helpful. Bernard, Laksminath, any ideas? > > I don't think we should make it algorithmic and instead should leave the > steering, direction and judgment aspects of an IESG job intact. Nor did I argue differently. However, there is a difference between exercising judgement and unguided sole discretion. My concern is that the language in the draft errs to far in the latter direction. > We could make the guiding text more precise (perhaps include some > specific criteria), if that is what the community wants. Yes, I think this would be valuable. > >> Arguably, SG formation should be subject to an IETF LC in the > >> same way that WG formation is. > >> > > > > Hm. I believed this was already the case. SGs are subject to exactly > > the same process as WGs, and I was assuming that like, WG formation, > > SG formation would include discussion in the IESG, consultation > > with the IAB, and IETF Last Call. > > > > Perhaps this needs clarification. Authors? > > We could clarify, but the intent is to follow the WG process for formation. In that case, I think it needs clarification. > >> Finally, it's unclear the extent to which SGs are intended to > >> transition directly to WGs without going through another BOF > >> phase. I have two concerns here: > >> > >> 1. It will be hard for the IESG to deny "successful" SGs the right > >> to form a WG. > >> > > > > Saying NO is still going to be needed. > > > >> 2. BOFs are a defined in-person event at which everyone knows that > >> WG formation is being considered. This provides an opportunity > >> for public high bandwidth discussion of that topic. I don't > >> think an LC on the IETF list is an adequate substitute. > >> > > > > Good point. Bernard, Laksminath -- any ideas here? > > I disagree with Eric here. I believe that we are not a meeting based > organization and should be making more of these important decisions via > email where we have more time to consider the proposals carefully. Well, you might prefer that the IETF functioned this way, but I think it pretty clearly does not. As a practical matter, nearly all WGs have BOFs prior to their formation, and that's the only time that there is high-bandwidth cross-area discussion. That same discussion by and large does not happen on the IETF mailing list during LC. IMO the effect of eliminating the in-person time will be to eliminate said discussion, not transfer it to the mailing list. If you wish the IETF to do more work via email, I think the first step would be to improve the quality of the email discussion. > My > observation based on some of the BoFs I have been involved with recently > is that far too much time is wasted between two BoF sessions. With > little or no discussion between sessions, a good portion of the meeting > time is used to get on the same page (again). I consider this a good indicator that the work is not ready to bring to the IETF. -Ekr _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf prefer that the IETF functioned this way, but I think it pretty clearly does not. As a practical matter, nearly all WGs have BOFs prior to their formation, and that's the only time that there is high-bandwidth cross-area discussion. That same discussion by and large does not happen on the IETF mailing list during LC. IMO the effect of eliminating the in-person time will be to eliminate said discussion, not transfer it to the mailing list. If you wish the IETF to do more work via email, I think the first step would be to improve the quality of the email discussion. > My > observation based on some of the BoFs I have been involved with recently > is that far too much time is wasted between two BoF sessions. With > little or no discussion between sessions, a good portion of the meeting > time is used to get on the same page (again). I consider this a good indicator that the work is not ready to bring to the IETF. -Ekr _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 14:42:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IexNQ-0000JM-TT; Mon, 08 Oct 2007 14:30:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IexNP-0000D9-Dv; Mon, 08 Oct 2007 14:30:47 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IexNO-0002bw-Oi; Mon, 08 Oct 2007 14:30:47 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D7BD91986B9; Mon, 8 Oct 2007 21:30:45 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 563D919866A; Mon, 8 Oct 2007 21:30:45 +0300 (EEST) Message-ID: <470A7755.7080400@piuha.net> Date: Mon, 08 Oct 2007 21:30:45 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Eric Rescorla References: <20071008130559.470F533C57@delta.rtfm.com> In-Reply-To: <20071008130559.470F533C57@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ietf@ietf.org, Andreas.Pashalidis@netlab.nec.de, Hannes.Tschofenig@nsn.com, iesg@ietf.org, Dirk.Kroeselberg@nsn.com, bersani_florent@yahoo.fr Subject: Re: Comment on draft-tschofenig-eap-ikev2-15 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Ekr, Thanks for your review. > As I was reading this document, I realized that I didn't understand > what it was for. > > As I understand it, this document embeds IKEv2 into EAP. Why is this a > good idea? As I understand the situation, EAP already supports a > TLS-based authentication mechanism, which allows it to do both > public-key based and asymmetric-key based authentication. So, what is > IKEv2 bringing to the party here? Obviously, there are things > IKEv2 is good for that TLS is not, but it's not clear to me that > EAP is using any of that functionality. > > It seems to me that this document would be improved by a discussion > up front of why it is desirable. > Hannes could probably add an applicability discussion that talks about when the use of this method is appropriate and how it compares to other methods. However, I should probably explain the background and rationale for taking on this document. RFC 3748 specifies the IANA rules for EAP method type code allocation. These rules call for Expert Review of methods before a type code can be allocated, basically to ensure that the specification is complete, correctly characterizes the security properties, doesn't break EAP, etc. Hannes applied for type code allocation, and after review on the EAP list and significant revision :-) his method has passed the expert review. My own review of the specification indicates that it is sufficiently well specified that those who run into this method can understand it and would likely be able to build interoperable implementations. But I do not expect this method to be a big success in the market place; its implemented and used only by the researchers in Hannes' group AFAIK. The methods that the IETF recommends to use will come out from the EMU WG, including an updated EAP-TLS spec. Nevertheless, I am in favor of documentation of EAP methods that actually exist. Some years ago we had a situation where IETF did not want to take on any methods work. At the time the IANA policy was also FCFS. This created a situation that we still suffer from: many if not most EAP methods have not been published as RFCs but exists only as drafts, typically not even matching what has been implemented. Often no documentation of a method exists at all. This is obviously bad for interoperability. In the last two or three year we've tried to improve the situation in a number of ways. Including starting up EMU, offering to publish widely used methods as RFCs via the RFC Editor or AD sponsoring, etc. Hannes' method isn't widely used, but given that he's going to get a type number I think it would be desirable to document what this type code means in an RFC. The status of his method would normally lead me to ask him to turn to the RFC Editor. However, in this case I felt that an IETF review of the method had the potential to improve the specification. There is IKEv2 expertise in the IETF, after all. This is also what happened. In addition, his document had been discussed in the EAP WG during Expert Review, so I felt that in this particular case AD sponsored submission for Experimental was the right choice. Hope this helps, Jari _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 15:15:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IexyA-0006kB-Bd; Mon, 08 Oct 2007 15:08:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iexy7-0006h6-S0; Mon, 08 Oct 2007 15:08:43 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iexy1-0001GM-Lk; Mon, 08 Oct 2007 15:08:43 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A1DC3198683; Mon, 8 Oct 2007 22:08:26 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 37E4A19866A; Mon, 8 Oct 2007 22:08:26 +0300 (EEST) Message-ID: <470A802A.6090106@piuha.net> Date: Mon, 08 Oct 2007 22:08:26 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: "Olaf M. Kolkman" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Bernard Aboba , IAB IAB , ietf@ietf.org Subject: Re: Last Call: draft-aboba-sg-experiment (Experiment in Study Group Formation within the Internet Engineering Task Force (IETF)) to Experimental RFC X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Thanks to IAB for the review. Inline: > The IAB does not oppose a scoped experiment. Great! > However, As the IAB reviews BOFs and WG charters (see RFC 2850 section > 2.1) as part of its architectural oversight function, we believe that > the IAB should also review SG charters. Of course. I think this has been the assumption, but it does deserve to be clarified in the document. Authors, take notice... > We also recommend that the evaluation criteria for success are made > clear before the start of the experiment. Ok. I assume you mean evaluation criteria for the success of the experiment, not the success of an SG? Jari _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 16:01:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeyYZ-0005oa-T4; Mon, 08 Oct 2007 15:46:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeyYW-0005nx-VY; Mon, 08 Oct 2007 15:46:20 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IeyYW-0004h7-NQ; Mon, 08 Oct 2007 15:46:20 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id 562A3175B3; Mon, 8 Oct 2007 19:46:10 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IeyYL-00065l-SZ; Mon, 08 Oct 2007 15:46:09 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: IETF Announcement list From: IETF Chair Message-Id: Date: Mon, 08 Oct 2007 15:46:09 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: fenner@research.att.com, fluffy@cisco.com, henrik@levkowetz.com, ietf@ietf.org Subject: Re: Vancouver IETF Code Sprint X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Please see http://www3.tools.ietf.org/tools/ietfdb/wiki/VancouverSprint for more details about the upcoming Code Sprint. Further discussion of the Vancouver IETF Code Sprint will take place on the tools-discuss mail list. If you are planing to come, please join that list and let Bill, Henrick, and Cullen know. Thanks, Russ At 09:42 AM Eastern on 28-Aug-2007, IETF Chair wrote: Vancouver IETF Code Sprint When: December 1, 2007, begining at 9:30 AM Where: IETF Hotel in Vancouver What: A bunch of hackers get together to work on code for the IETF web site. Some people may be porting of existing functionality to the new framework; some people may be adding exciting new functionality. All code will become part of the open source IETF tools. Who: Hopefully you can help Henrik Levkowetz and Bill Fenner will be coordinating the event. You will hear more from them shortly, beginning with brainstorming about which things to work on during this event. Please support the tools development effort, Russ _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 16:57:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IezSX-0004zE-E1; Mon, 08 Oct 2007 16:44:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IezSO-0004z8-SM for ietf@ietf.org; Mon, 08 Oct 2007 16:44:04 -0400 Received: from rv-out-0910.google.com ([209.85.198.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IezSH-0004AX-2W for ietf@ietf.org; Mon, 08 Oct 2007 16:44:04 -0400 Received: by rv-out-0910.google.com with SMTP id l15so799043rvb for ; Mon, 08 Oct 2007 13:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=oNyqAIHvaTJHteFXaIVPT0amRAyVx7LaDxUZxUoCaGQ=; b=jJrzXfRdm09QwzMPMpl+5HShZDcrs8Ma4bxIgQR6uqf9SuJtLgqBf2junBJy5lqtuTvEsFXkFR1hZ5NIf6wtzXnLXymmO8HLO2P+52MTjnNDacGCSkpFHwEvIIkFipwh43ke+GEkUNFSAtzbONAQx8KQnRQT1NnlN9WaPQR1JZY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=gRyXaCV6FiI9bPm51oKF2df55PLWDpECNoL1ah7Y+1P6Nc87LsLFdnGZ8KCxYNDpVwh8ek2vlHUj6RjPFbmwvXKnoB3iyhmm6SZ+3YvCTC8K70WhtWz9x2xi0E8LAfQ6yyQAWjmNi7NPuiTG3UhWDeLuMJ7RldtTNlB/AZlsrgQ= Received: by 10.141.196.13 with SMTP id y13mr2698728rvp.1191876221117; Mon, 08 Oct 2007 13:43:41 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id b24sm13007573rvf.2007.10.08.13.43.38 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Oct 2007 13:43:40 -0700 (PDT) Message-ID: <470A9673.5070500@gmail.com> Date: Tue, 09 Oct 2007 09:43:31 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eric Rescorla References: <20071008014006.88BB233C21@delta.rtfm.com> <4709D647.7070004@piuha.net> <470A735E.9050807@qualcomm.com> <20071008183014.6D04B33C21@delta.rtfm.com> In-Reply-To: <20071008183014.6D04B33C21@delta.rtfm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Jari Arkko , ietf@ietf.org, iesg@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-09 07:30, Eric Rescorla wrote: > At Mon, 08 Oct 2007 11:13:50 -0700, > Lakshminath Dondeti wrote: >> My >> observation based on some of the BoFs I have been involved with recently >> is that far too much time is wasted between two BoF sessions. With >> little or no discussion between sessions, a good portion of the meeting >> time is used to get on the same page (again). > > I consider this a good indicator that the work is not ready to bring > to the IETF. Eric, you're probably assuming that discussion groups will automatically form around viable BOF proposals, and proceed in a reasonably organized way. That's certainly necessary for success. My feeling is that as the IETF expands its reach to more and more countries and time zones, it's become progressively harder for such self-organization to happen. I see Study Groups as a way to use IETF resources to support those discussion groups, instead of leaving them to self-organize. It seems reasonable to test out the idea, but it should certainly be made clear that SGs may flunk out. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 19:09:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1If1WL-00043x-KN; Mon, 08 Oct 2007 18:56:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If1WJ-0003xq-HD for ietf@ietf.org; Mon, 08 Oct 2007 18:56:15 -0400 Received: from ppsw-2.csi.cam.ac.uk ([131.111.8.132]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1If1WE-0001pn-5t for ietf@ietf.org; Mon, 08 Oct 2007 18:56:10 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:46607) by ppsw-2.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.152]:25) with esmtpa (EXTERNAL:fanf2) id 1If1WA-0004eh-9M (Exim 4.63) (return-path ); Mon, 08 Oct 2007 23:56:06 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1If1WA-0008GU-SI (Exim 4.67) (return-path ); Mon, 08 Oct 2007 23:56:06 +0100 Date: Mon, 8 Oct 2007 23:56:06 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Keith Moore In-Reply-To: <4705414B.5000109@cs.utk.edu> Message-ID: References: <2788466ED3E31C418E9ACC5C31661557053529@mou1wnexmb09.vcorp.ad.vrsn.com> <4705414B.5000109@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Fred Baker , ietf@ietf.org Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Thu, 4 Oct 2007, Keith Moore wrote: > > the vast majority of domains won't be able to use DKIM without seriously > impairing their users' ability to send mail. You seem to be assuming that the vast majority of domains have really shitty message submission servers or connectivity. Maybe true, but if so they're already losing so much that lack of DKIM probably doesn't matter to them. Tony. -- f.a.n.finch http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 20:06:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1If2R1-0000zO-0B; Mon, 08 Oct 2007 19:54:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If2Qz-0000xm-NK for ietf@ietf.org; Mon, 08 Oct 2007 19:54:49 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1If2Qt-0000SW-JM for ietf@ietf.org; Mon, 08 Oct 2007 19:54:49 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id BC4081EE218; Mon, 8 Oct 2007 19:54:27 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tl82+wIxyq4y; Mon, 8 Oct 2007 19:54:23 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id B4F5F1EE20D; Mon, 8 Oct 2007 19:54:22 -0400 (EDT) Message-ID: <470AC324.70604@cs.utk.edu> Date: Mon, 08 Oct 2007 19:54:12 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Tony Finch References: <2788466ED3E31C418E9ACC5C31661557053529@mou1wnexmb09.vcorp.ad.vrsn.com> <4705414B.5000109@cs.utk.edu> In-Reply-To: X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Fred Baker , ietf@ietf.org Subject: Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Tony Finch wrote: > On Thu, 4 Oct 2007, Keith Moore wrote: > >> the vast majority of domains won't be able to use DKIM without seriously >> impairing their users' ability to send mail. >> > > You seem to be assuming that the vast majority of domains have really > shitty message submission servers or connectivity. It's a combination of several things - one, requiring that a domain operate its own mail submission servers which sign their mail (and all that that implies, like maintaining the private keys). Two, many domains will be too small to develop enough of a reputation to be whitelisted, and any spammer can create a temporary domain which will have about as good a reputation as the vast majority of those domains. Three, as long as people use Windows boxes, spammers will be able to compromise them and hijack them to use them to originate mail on behalf of their domains, thus degrading those domains' reputation. So basically if you're a small domain, you're SOL. If you're a large domain, people can't afford to blacklist you unless you originate a lot of spam anyway. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 21:19:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1If3d1-0004DG-6U; Mon, 08 Oct 2007 21:11:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If3cy-0004BY-UU; Mon, 08 Oct 2007 21:11:16 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1If3cs-0002h9-Lw; Mon, 08 Oct 2007 21:11:16 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l991ArdA028677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 Oct 2007 18:10:54 -0700 Received: from [129.46.78.94] (ldondeti.na.qualcomm.com [129.46.78.94]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l991ApY9032169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Oct 2007 18:10:52 -0700 Message-ID: <470AD521.60907@qualcomm.com> Date: Mon, 08 Oct 2007 18:10:57 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jari Arkko References: <20071008130559.470F533C57@delta.rtfm.com> <470A7755.7080400@piuha.net> In-Reply-To: <470A7755.7080400@piuha.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Andreas.Pashalidis@netlab.nec.de, bersani_florent@yahoo.fr, Hannes.Tschofenig@nsn.com, iesg@ietf.org, Dirk.Kroeselberg@nsn.com, ietf@ietf.org Subject: Re: Comment on draft-tschofenig-eap-ikev2-15 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org If a type code is going to be allocated anyway, it makes perfect sense to have the protocol documented in an RFC. Procedurally, I am curious about the experimental status however, given that the general mode of operation on EAP methods was to document the method in an informational track RFC. I will also ask the obligatory :) question: After the experiment, are we entertaining the possibility of advancing this work to standards track? thanks, Lakshminath On 10/8/2007 11:30 AM, Jari Arkko wrote: > Ekr, > > Thanks for your review. > >> As I was reading this document, I realized that I didn't understand >> what it was for. >> >> As I understand it, this document embeds IKEv2 into EAP. Why is this a >> good idea? As I understand the situation, EAP already supports a >> TLS-based authentication mechanism, which allows it to do both >> public-key based and asymmetric-key based authentication. So, what is >> IKEv2 bringing to the party here? Obviously, there are things >> IKEv2 is good for that TLS is not, but it's not clear to me that >> EAP is using any of that functionality. >> >> It seems to me that this document would be improved by a discussion >> up front of why it is desirable. >> > > Hannes could probably add an applicability discussion that > talks about when the use of this method is appropriate and > how it compares to other methods. > > However, I should probably explain the background and rationale > for taking on this document. > > RFC 3748 specifies the IANA rules for EAP method type code > allocation. These rules call for Expert Review of methods > before a type code can be allocated, basically to ensure that > the specification is complete, correctly characterizes the > security properties, doesn't break EAP, etc. Hannes applied > for type code allocation, and after review on the EAP list > and significant revision :-) his method has passed the expert > review. My own review of the specification indicates > that it is sufficiently well specified that those > who run into this method can understand it and would > likely be able to build interoperable implementations. > > But I do not expect this method to be a big success in the > market place; its implemented and used only by the researchers > in Hannes' group AFAIK. The methods that the IETF recommends > to use will come out from the EMU WG, including an updated > EAP-TLS spec. > > Nevertheless, I am in favor of documentation of EAP > methods that actually exist. Some years ago we had a > situation where IETF did not want to take on any methods > work. At the time the IANA policy was also FCFS. This created > a situation that we still suffer from: many if not most EAP > methods have not been published as RFCs but exists only > as drafts, typically not even matching what has been > implemented. Often no documentation of a method exists > at all. This is obviously bad for interoperability. > > In the last two or three year we've tried to improve the situation > in a number of ways. Including starting up EMU, offering to > publish widely used methods as RFCs via the RFC Editor or > AD sponsoring, etc. > > Hannes' method isn't widely used, but given that he's going > to get a type number I think it would be desirable to document > what this type code means in an RFC. The status of his method > would normally lead me to ask him to turn to the RFC Editor. > However, in this case I felt that an IETF review of the method > had the potential to improve the specification. There is IKEv2 > expertise in the IETF, after all. This is also what happened. In > addition, his document had been discussed in the EAP WG during > Expert Review, so I felt that in this particular case AD > sponsored submission for Experimental was the right > choice. > > Hope this helps, > > Jari > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 21:19:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1If3RP-0008UK-P0; Mon, 08 Oct 2007 20:59:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If3RO-0008Mp-2N for ietf@ietf.org; Mon, 08 Oct 2007 20:59:18 -0400 Received: from harry.mail-abuse.org ([168.61.5.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1If3RL-0004eZ-Jo for ietf@ietf.org; Mon, 08 Oct 2007 20:59:15 -0400 Received: from [10.2.164.130] (SJC-Office-NAT-212.Mail-Abuse.ORG [168.61.10.212]) by harry.mail-abuse.org (Postfix) with ESMTP id E643A4143A; Mon, 8 Oct 2007 17:59:12 -0700 (PDT) In-Reply-To: <470AC324.70604@cs.utk.edu> References: <2788466ED3E31C418E9ACC5C31661557053529@mou1wnexmb09.vcorp.ad.vrsn.com> <4705414B.5000109@cs.utk.edu> <470AC324.70604@cs.utk.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Date: Mon, 8 Oct 2007 17:59:13 -0700 To: Keith Moore X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Tony Finch , ietf list , DKIM WG Subject: DKIM reputation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 8, 2007, at 4:54 PM, Keith Moore wrote: > Tony Finch wrote: >> On Thu, 4 Oct 2007, Keith Moore wrote: >> >>> the vast majority of domains won't be able to use DKIM without >>> seriously impairing their users' ability to send mail. >> >> You seem to be assuming that the vast majority of domains have >> really shitty message submission servers or connectivity. > > It's a combination of several things - one, requiring that a domain > operate its own mail submission servers which sign their mail (and > all that that implies, like maintaining the private keys). Two, > many domains will be too small to develop enough of a reputation to > be whitelisted, and any spammer can create a temporary domain which > will have about as good a reputation as the vast majority of those > domains. > Three, as long as people use Windows boxes, spammers will be able > to compromise them and hijack them to use them to originate mail on > behalf of their domains, thus degrading those domains' reputation. > > So basically if you're a small domain, you're SOL. If you're a > large domain, people can't afford to blacklist you unless you > originate a lot of spam anyway. Keith, The DKIM component that establishes reputation is being discussed within the DKIM WG. The DKIM signature offers an alternative to the IP address which serves as perhaps the only other assured basis for reputation. Of course the IP address also shares all of these problems. A DKIM signature can help avoid some of the reputation problems associated with shared use of an IP address (which is a larger problem for smaller domains). For larger domains, there might be some concern related to replay abuse, where again, smaller domains also enjoy an advantage in being able to squelch compromised systems. Don't be too quick to condemn DKIM. There should be a simple mechanism which allows email-domains to autonomously authorize DKIM- domains. This feature should defray some of your concerns. Delegating a zone of one's domain would be expensive to manage but is currently the only means now permitted. -Doug _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 21:29:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1If3pi-0004mS-5n; Mon, 08 Oct 2007 21:24:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If3pg-0004kP-Oy for ietf@ietf.org; Mon, 08 Oct 2007 21:24:24 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1If3pa-0003Bj-Kw for ietf@ietf.org; Mon, 08 Oct 2007 21:24:24 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 3BDE21EE261; Mon, 8 Oct 2007 21:24:11 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHoxUaW3nVXy; Mon, 8 Oct 2007 21:24:07 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id CFA051EE25A; Mon, 8 Oct 2007 21:24:01 -0400 (EDT) Message-ID: <470AD829.1000602@cs.utk.edu> Date: Mon, 08 Oct 2007 21:23:53 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Douglas Otis References: <2788466ED3E31C418E9ACC5C31661557053529@mou1wnexmb09.vcorp.ad.vrsn.com> <4705414B.5000109@cs.utk.edu> <470AC324.70604@cs.utk.edu> In-Reply-To: X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Tony Finch , ietf list , DKIM WG Subject: Re: DKIM reputation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > Keith, > > The DKIM component that establishes reputation is being discussed > within the DKIM WG. The DKIM signature offers an alternative to the > IP address which serves as perhaps the only other assured basis for > reputation. Of course the IP address also shares all of these > problems. A DKIM signature can help avoid some of the reputation > problems associated with shared use of an IP address (which is a > larger problem for smaller domains). For larger domains, there might > be some concern related to replay abuse, where again, smaller domains > also enjoy an advantage in being able to squelch compromised systems. > > Don't be too quick to condemn DKIM. There should be a simple > mechanism which allows email-domains to autonomously authorize > DKIM-domains. that feature should have been there from day one. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 21:34:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1If3vy-0002lq-Km; Mon, 08 Oct 2007 21:30:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If3vw-0002e8-1P; Mon, 08 Oct 2007 21:30:52 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1If3vv-0006rI-J6; Mon, 08 Oct 2007 21:30:51 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l991UnxI031008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 Oct 2007 18:30:49 -0700 Received: from [129.46.78.94] (ldondeti.na.qualcomm.com [129.46.78.94]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l991Um6o026839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Oct 2007 18:30:48 -0700 (PDT) Message-ID: <470AD9CE.20401@qualcomm.com> Date: Mon, 08 Oct 2007 18:30:54 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian E Carpenter References: <20071008014006.88BB233C21@delta.rtfm.com> <4709D647.7070004@piuha.net> <470A735E.9050807@qualcomm.com> <20071008183014.6D04B33C21@delta.rtfm.com> <470A9673.5070500@gmail.com> In-Reply-To: <470A9673.5070500@gmail.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: iesg@ietf.org, Jari Arkko , ietf@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 10/8/2007 1:43 PM, Brian E Carpenter wrote: > On 2007-10-09 07:30, Eric Rescorla wrote: >> At Mon, 08 Oct 2007 11:13:50 -0700, >> Lakshminath Dondeti wrote: > > > >>> My observation based on some of the BoFs I have been involved with >>> recently is that far too much time is wasted between two BoF >>> sessions. With little or no discussion between sessions, a good >>> portion of the meeting time is used to get on the same page (again). >> >> I consider this a good indicator that the work is not ready to bring >> to the IETF. > > Eric, you're probably assuming that discussion groups will > automatically form around viable BOF proposals, and proceed in > a reasonably organized way. That's certainly necessary for > success. My feeling is that as the IETF expands its reach > to more and more countries and time zones, it's become > progressively harder for such self-organization to happen. > > I see Study Groups as a way to use IETF resources to > support those discussion groups, instead of leaving them to > self-organize. It seems reasonable to test out the idea, > but it should certainly be made clear that SGs may flunk > out. Yes, one of the possible outcomes of an SG may be documentation of the discussion and the conclusions in non-standards track documents and closure of the SG. regards, Lakshminath > > Brian > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 08 22:24:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1If4UX-0003M5-3Q; Mon, 08 Oct 2007 22:06:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If4UV-0003Gd-Kt for ietf@ietf.org; Mon, 08 Oct 2007 22:06:35 -0400 Received: from harry.mail-abuse.org ([168.61.5.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1If4UR-0008JB-97 for ietf@ietf.org; Mon, 08 Oct 2007 22:06:31 -0400 Received: from [10.2.164.130] (SJC-Office-NAT-212.Mail-Abuse.ORG [168.61.10.212]) by harry.mail-abuse.org (Postfix) with ESMTP id 531784143A; Mon, 8 Oct 2007 19:06:30 -0700 (PDT) In-Reply-To: References: <2788466ED3E31C418E9ACC5C316615570534E4@mou1wnexmb09.vcorp.ad.vrsn.com> <6.2.5.6.2.20071004111028.031d08e0@resistor.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D19D707-31B1-4753-8B33-2F9761A5451A@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Date: Mon, 8 Oct 2007 19:06:31 -0700 To: Frank Ellermann X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -4.0 (----) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ietf@ietf.org Subject: TMDA backscatter X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 8, 2007, at 4:37 AM, Frank Ellermann wrote: > SM wrote: > >> TMDA may cause backscatter. > > After an SPF PASS, the "backscatter" by definition can't hit an > innocent bystander. By the same definition any "backscatter" after > an SPF FAIL hits an innocent bystander, and therefore is net abuse. There is a real risk SPF might be used as basis for acceptance, rather than just for qualifying DSNs. As a basis for acceptance, this can cause email to fail. The macro expansion of SPF records permits the _same_ DNS record within a spam campaign to generate a large number of subsequent and different DNS transactions to be sent by recipients to "innocent bystanders". Much of the danger of auto responses has to do with DDoS concerns. Unfortunately, SPF represents a far graver concern than that caused by auto-responses. A safer approach would be to format all DSNs per RFC3464 and remove original message content. This reduces incentives for abusing the automated responses. Mailman made a mistake where an error caused a DSN that returned original content without first verifying the validity of the return path. Had TMDA been a requisite for initial acceptance, just those white-listed would have been prone to this error. -Doug _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 04:32:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfALc-0003cO-E8; Tue, 09 Oct 2007 04:21:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfALa-0003bf-Gu; Tue, 09 Oct 2007 04:21:46 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfALU-0005ut-6F; Tue, 09 Oct 2007 04:21:46 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5DFF8198683; Tue, 9 Oct 2007 11:21:34 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 049D319866A; Tue, 9 Oct 2007 11:21:34 +0300 (EEST) Message-ID: <470B3A0E.1030004@piuha.net> Date: Tue, 09 Oct 2007 11:21:34 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Lakshminath Dondeti References: <20071008130559.470F533C57@delta.rtfm.com> <470A7755.7080400@piuha.net> <470AD521.60907@qualcomm.com> In-Reply-To: <470AD521.60907@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ietf@ietf.org, Andreas.Pashalidis@netlab.nec.de, Hannes.Tschofenig@nsn.com, iesg@ietf.org, Dirk.Kroeselberg@nsn.com, bersani_florent@yahoo.fr Subject: Re: Comment on draft-tschofenig-eap-ikev2-15 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Lakshminath, > If a type code is going to be allocated anyway, it makes perfect sense > to have the protocol documented in an RFC. OK. > Procedurally, I am curious about the experimental status however, > given that the general mode of operation on EAP methods was to > document the method in an informational track RFC. I admit that this looks somewhat arbitrary choice, and Inf would have worked too. But here's my rationale: some of the other EAP methods that are Inf were truly non-research efforts with a very clear target in the market place and in vendor's products. There's less clarity on EAP IKEv2's role, it came out of what to me appeared as a researcher's interest to see if a method can be defined this way. This is why Exp felt more appropriate, with the experiment being whether this method finds use in the world. > I will also ask the obligatory :) question: > > After the experiment, are we entertaining the possibility of advancing > this work to standards track? We would consider that for any document. I think its somewhat unlikely in this case, though. Again, the recommended methods to use will come out of EMU. Jari _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 04:32:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfA4S-0006jH-Az; Tue, 09 Oct 2007 04:04:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfA4R-0006fq-1y; Tue, 09 Oct 2007 04:04:03 -0400 Received: from open.nlnetlabs.nl ([2001:7b8:206:1::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfA4M-0005RV-Qj; Tue, 09 Oct 2007 04:04:03 -0400 Received: from [127.0.0.1] (open.nlnetlabs.nl [213.154.224.1]) by open.nlnetlabs.nl (8.14.1/8.13.8) with ESMTP id l9983anq002135; Tue, 9 Oct 2007 10:03:36 +0200 (CEST) (envelope-from olaf@nlnetlabs.nl) In-Reply-To: <470A802A.6090106@piuha.net> References: <470A802A.6090106@piuha.net> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: "Olaf M. Kolkman" Date: Tue, 9 Oct 2007 04:03:34 -0400 To: Jari Arkko X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, score=-104.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on open.nlnetlabs.nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Bernard Aboba , IAB IAB , ietf@ietf.org Subject: Re: Last Call: draft-aboba-sg-experiment (Experiment in Study Group Formation within the Internet Engineering Task Force (IETF)) to Experimental RFC X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2081990243==" Errors-To: ietf-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2081990243== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-8-1008933426" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-8-1008933426 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > >> We also recommend that the evaluation criteria for success are made >> clear before the start of the experiment. > > Ok. I assume you mean evaluation criteria for the success of the > experiment, > not the success of an SG? > Yes, the criteria for the success of the experiment. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-8-1008933426 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: This message is locally signed. iD8DBQFHCzXWtN/ca3YJIocRAm19AJ9nKYfCknOb6WsMgfxaq/OUTHeaDwCfXNjC WEgvYY6JIg9luNstcIphaWs= =cuIZ -----END PGP SIGNATURE----- --Apple-Mail-8-1008933426-- --===============2081990243== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============2081990243==-- From ietf-bounces@ietf.org Tue Oct 09 06:33:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfC84-0001iN-CD; Tue, 09 Oct 2007 06:15:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfC81-0001hu-S0; Tue, 09 Oct 2007 06:15:53 -0400 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfC80-0003zO-Pg; Tue, 09 Oct 2007 06:15:53 -0400 X-IronPort-AV: E=Sophos;i="4.21,248,1188792000"; d="scan'208,217";a="68893821" Received: from 14.140.8.135.in-addr.arpa (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-outbound.avaya.com with ESMTP; 09 Oct 2007 06:15:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Oct 2007 12:15:51 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-aboba-sg-experiment-02 Thread-Index: AcgKSOBpfdUyxbyERS6wvNcP3q5lHQAFAYiw References: <20071008014006.88BB233C21@delta.rtfm.com><4709D647.7070004@piuha.net><20071008125725.3B71233C57@delta.rtfm.com><470A30CC.2030603@cisco.com> From: "Romascanu, Dan (Dan)" To: "Gabriel Montenegro" , "Eliot Lear" , "Eric Rescorla" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb Cc: Jari Arkko , ietf@ietf.org, iesg@ietf.org Subject: RE: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1488281265==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============1488281265== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80A5D.5E9CC597" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80A5D.5E9CC597 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, but RGs are not initiated by the IESG but by the IRTF and they are = focused on research oriented charters. Many of the issues faced by folks = that discuss the possible formation of new WGs are engineering rather = than research issues.=20 =20 Dan =20 =20 =20 =20 ________________________________ From: Gabriel Montenegro [mailto:g.e.montenegro@hotmail.com]=20 Sent: Monday, October 08, 2007 6:20 PM To: Romascanu, Dan (Dan); Eliot Lear; Eric Rescorla Cc: Jari Arkko; ietf@ietf.org; iesg@ietf.org Subject: RE: Comments on draft-aboba-sg-experiment-02 =09 =09 I have seen the functioning of SGs at the IEEE and agree that they can = be useful, but I'm not sure about how it is being "translated" into the = IETF> =20 It occurs to me that we don't need to invent a new process here. The = IRTF houses different types of "research" groups: some are meant to be long-lived, some are meant to meet during IETF, some never meet, = etc. There also are some RGs that have operated in a manner=20 similar to the study groups being proposed: NSRG (name spaces research = group), for example. And some that have been started as an alternative to petitions to form a WG, and which would seriously = benefit from having a tighter charter with specific milestones and expectations = (e.g., p2prg RG).=20 =20 RGs are created with all sorts of different goals in mind. All that the = IESG needs here, I think, is to start an RG to probe further into a given issue, and keep it on a short leash along the lines stipulated = for the SG: e.g., milestones, meetings during IETF, explicit IESG = liaison, etc. But the point is that these conditions need not be the same for each = such RG/SG. =20 I also think this is something useful the IRTF could do, as most often = than not, it actually doesn't do any research. The IESG wins, the IRTF = wins, the IETF wins. =20 -gabriel =09 =09 =09 ________________________________ > Date: Mon, 8 Oct 2007 15:45:44 +0200 > From: dromasca@avaya.com > To: lear@cisco.com; ekr@networkresonance.com > CC: jari.arkko@piuha.net; ietf@ietf.org; iesg@ietf.org > Subject: RE: Comments on draft-aboba-sg-experiment-02 >=20 > The way I see it the problem that this proposal tries to solve is = about > helping the IESG and the community to make a better decision when the > forming of the working group us discussed. It is not about bringing = more > work to the IETF, it is about making sure to a better extent that the > right work is being brought into the IETF. In the absence of such a > process what we see in many cases is the formation of ad-hoc groups, > which is not necessarily bad - but why not charter them with a set of > clear questions which may help the IESG and the whole community reach = a > more educated decision?=20 >=20 > Regarding terminology, the term 'study group' is used in this = proposal > in a way similar to how the IEEE is using it.=20 >=20 > Dan >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Eliot Lear [mailto:lear@cisco.com]=20 > > Sent: Monday, October 08, 2007 3:30 PM > > To: Eric Rescorla > > Cc: Jari Arkko; ietf@ietf.org; iesg@ietf.org > > Subject: Re: Comments on draft-aboba-sg-experiment-02 > >=20 > > If I understand the purpose of this experiment it would be to=20 > > provide ADs some indication of level of interest and ability=20 > > to succeed. I see no reason why we need to formalize this=20 > > within the IETF. Furthemore, the terminology is problematic.=20 > > We are overlapping a term that is commonly used by the ITU=20 > > the way working group is used by the IETF.=20 > > Let's not make the process any more confusing than it already is. > > Finally, milestones for such "study groups" seem to me = inappropriate.=20 > > It may be that a topic is uninteresting for quite a while and=20 > > then picks up. ANY way to demonstrate that interest and=20 > > ability to succeed should be sufficient, regardless of how=20 > > much time has passed. > >=20 > > Eliot > >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf =09 =09 =09 ________________________________ Help yourself to FREE treats served up daily at the Messenger Caf=E9. = Stop by today! = =20 ------_=_NextPart_001_01C80A5D.5E9CC597 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yes, but RGs are not initiated by the = IESG but by=20 the IRTF and they are focused on research oriented charters. Many of the = issues=20 faced by folks that discuss the possible formation of new WGs are = engineering=20 rather than research issues.
 
Dan
 
 
 
 


From: Gabriel Montenegro=20 [mailto:g.e.montenegro@hotmail.com]
Sent: Monday, October = 08, 2007=20 6:20 PM
To: Romascanu, Dan (Dan); Eliot Lear; Eric=20 Rescorla
Cc: Jari Arkko; ietf@ietf.org;=20 iesg@ietf.org
Subject: RE: Comments on=20 draft-aboba-sg-experiment-02


I have seen the functioning of SGs at the IEEE and = agree that=20 they can be useful, but I'm not sure about how it is being = "translated" into=20 the IETF>
 
It occurs to me that we don't need to invent = a new=20 process here. The IRTF houses different types of "research" groups: = some are=20 meant
to be long-lived, some are meant to meet during IETF, some = never=20 meet, etc. There also are some RGs that have operated in a manner =
similar=20 to the study groups being proposed: NSRG (name spaces research group), = for=20 example. And some that have been started as an
alternative=20 to petitions to form a WG, and which would seriously benefit=20 from
having a tighter charter with specific milestones and = expectations=20 (e.g., p2prg RG).
 
RGs are created with all sorts of = different=20 goals in mind. All that the IESG needs here, I think, is to start an = RG to=20 probe further into
a given issue, and keep it on a short leash = along the=20 lines stipulated for the SG: e.g., milestones, meetings during IETF, = explicit=20 IESG liaison, etc.
But the point is that these conditions need not = be the=20 same for each such RG/SG.
 
I also think this is something = useful=20 the IRTF could do, as most often than not, it actually doesn't do any=20 research. The IESG wins, the IRTF wins,
the IETF=20 wins.
 
-gabriel




> Date: Mon, 8 Oct 2007 15:45:44 +0200
> From:=20 dromasca@avaya.com
> To: lear@cisco.com;=20 ekr@networkresonance.com
> CC: jari.arkko@piuha.net; = ietf@ietf.org;=20 iesg@ietf.org
> Subject: RE: Comments on=20 draft-aboba-sg-experiment-02
>
> The way I see it the = problem=20 that this proposal tries to solve is about
> helping the IESG = and the=20 community to make a better decision when the
> forming of the = working=20 group us discussed. It is not about bringing more
> work to the = IETF, it=20 is about making sure to a better extent that the
> right work is = being=20 brought into the IETF. In the absence of such a
> process what = we see in=20 many cases is the formation of ad-hoc groups,
> which is not = necessarily=20 bad - but why not charter them with a set of
> clear questions = which may=20 help the IESG and the whole community reach a
> more educated = decision?=20
>
> Regarding terminology, the term 'study group' is = used in=20 this proposal
> in a way similar to how the IEEE is using it. =
>=20
> Dan
>
>
>
>
> > = -----Original=20 Message-----
> > From: Eliot Lear [mailto:lear@cisco.com] =
>=20 > Sent: Monday, October 08, 2007 3:30 PM
> > To: Eric=20 Rescorla
> > Cc: Jari Arkko; ietf@ietf.org; = iesg@ietf.org
>=20 > Subject: Re: Comments on draft-aboba-sg-experiment-02
> = >=20
> > If I understand the purpose of this experiment it would = be to=20
> > provide ADs some indication of level of interest and = ability=20
> > to succeed. I see no reason why we need to formalize = this=20
> > within the IETF. Furthemore, the terminology is = problematic.=20
> > We are overlapping a term that is commonly used by the = ITU=20
> > the way working group is used by the IETF.
> > = Let's=20 not make the process any more confusing than it already is.
> = >=20 Finally, milestones for such "study groups" seem to me inappropriate. =
>=20 > It may be that a topic is uninteresting for quite a while and =
>=20 > then picks up. ANY way to demonstrate that interest and
> = >=20 ability to succeed should be sufficient, regardless of how
> = > much=20 time has passed.
> >
> > Eliot
> > =
>=20
> _______________________________________________
> Ietf = mailing=20 list
> Ietf@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/ietf



Help yourself to FREE treats served up daily at the Messenger Caf=E9. = Stop by today! ------_=_NextPart_001_01C80A5D.5E9CC597-- --===============1488281265== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============1488281265==-- From ietf-bounces@ietf.org Tue Oct 09 06:37:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfCOc-00004q-Vj; Tue, 09 Oct 2007 06:33:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfCOb-0008WQ-9H for ietf@ietf.org; Tue, 09 Oct 2007 06:33:01 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfCOa-0004RU-MW for ietf@ietf.org; Tue, 09 Oct 2007 06:33:01 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l99AWRJY029780; Tue, 9 Oct 2007 13:32:44 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 13:32:27 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 13:32:27 +0300 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" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Oct 2007 13:32:27 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last call comments for draft-lepinski-dh-groups-01 Thread-Index: AcgKX7Axn+dHrGDJTk6vVKK6mKQRUw== From: To: X-OriginalArrivalTime: 09 Oct 2007 10:32:27.0770 (UTC) FILETIME=[B065EDA0:01C80A5F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: kent@bbn.com, mlepinski@bbn.com Subject: Last call comments for draft-lepinski-dh-groups-01 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Two comments about the IPsec-related parts: 1) Section 1 says: "Sixteen additional groups subsequently have been defined and assigned values by IANA for use with IKE (v1 and v2). All of these additional groups are optional in the IKE context. Of the twenty-one groups defined so far, eight are MODP groups (exponentiation groups modulo a prime), ten are EC2N groups (elliptic curve groups over GF[2^N]) and three are ECP groups (elliptic curve groups over GF[P]). This is not totally correct. As of this writing, no EC2N groups have been assigned values for use with IKEv2. Also, eight of the ten EC2N groups for IKEv1 are not documented in any RFC. (And yes, I'm aware of draft-ietf-ipsec-ike-ecc-groups -- but that hasn't been approved yet, and requires changes before approval.) 2) For IKEv1/IKEv2, the document should explicitly specify how=20 ECC points are converted to octet strings (for KE payloads=20 and resulting shared secret value). Currently, there are at=20 least three incompatible options (RFC 4753, RFC 2409, and=20 draft-ietf-ipsec-ike-ecc-groups-10 drafts). I'd suggest just saying "the same way as in RFC 4753". Best regards, Pasi _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 07:11:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfCrb-0004Yz-K7; Tue, 09 Oct 2007 07:02:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfCrZ-0004Yo-IU for ietf@ietf.org; Tue, 09 Oct 2007 07:02:57 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfCrP-00029M-6u for ietf@ietf.org; Tue, 09 Oct 2007 07:02:53 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IfCqt-0000uA-Nn for ietf@ietf.org; Tue, 09 Oct 2007 11:02:15 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Oct 2007 11:02:15 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Oct 2007 11:02:15 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: "Frank Ellermann" Date: Tue, 9 Oct 2007 12:59:36 +0200 Lines: 41 Message-ID: References: <2788466ED3E31C418E9ACC5C316615570534E4@mou1wnexmb09.vcorp.ad.vrsn.com><6.2.5.6.2.20071004111028.031d08e0@resistor.net> <3D19D707-31B1-4753-8B33-2F9761A5451A@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: Re: TMDA backscatter X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Douglas Otis wrote: > There is a real risk SPF might be used as basis for acceptance You can combine white lists with SPF PASS as with DKIM "PASS", the risk is very similar. =20 > Much of the danger of auto responses has to do with DDoS=20 > concerns. It depends on the definition of "DDoS". From my POV as POP3 user over a V.90 connection 10,000 unsolicited mails are just bad, no matter what it is (spam, worm, DSN, or auto-response). It's not really a "DDoS". SPF at least helped me to get rid of the bogus DSNs and other auto-responses since three years, smart spammers are not interested to forge SPF FAIL protected addresses. BTW, I think the definition of "Joe job" in the sieve EREJECT draft is obsolete, the mere abuse of "plausible" addresses is no "Joe job" and IMO also not a real DDoS. But it's certainly bad for the victims, it can be bad enough to make a mailbox unusable for some victims. =20 > A safer approach would be to format all DSNs per RFC3464 and=20 > remove original message content. I'd hope that a majority of receivers already does this, that's state of the art for some years now. Or rather "truncate" is state of the art, not complete removal of the body. > Mailman made a mistake where an error caused a DSN that returned > original content without first verifying the validity of the > return path. Auto responders aren't in a good position to verify the validity of the return path. Good positions to do this are the MSA based on RFC 4409 and later the MX based on RFC 4408. Frank _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 07:33:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfD9V-000555-3U; Tue, 09 Oct 2007 07:21:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfD9T-00054h-Tw for ietf@ietf.org; Tue, 09 Oct 2007 07:21:28 -0400 Received: from ppsw-4.csi.cam.ac.uk ([131.111.8.134]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfD9T-0005oE-8n for ietf@ietf.org; Tue, 09 Oct 2007 07:21:27 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:57894) by ppsw-4.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.154]:25) with esmtpa (EXTERNAL:fanf2) id 1IfD9Q-0003WH-DB (Exim 4.63) (return-path ); Tue, 09 Oct 2007 12:21:24 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1IfD9Q-0004yT-1z (Exim 4.67) (return-path ); Tue, 09 Oct 2007 12:21:24 +0100 Date: Tue, 9 Oct 2007 12:21:24 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Keith Moore In-Reply-To: <470AC324.70604@cs.utk.edu> Message-ID: References: <2788466ED3E31C418E9ACC5C31661557053529@mou1wnexmb09.vcorp.ad.vrsn.com> <4705414B.5000109@cs.utk.edu> <470AC324.70604@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Fred Baker , ietf@ietf.org Subject: DKIM reputation, was Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Mon, 8 Oct 2007, Keith Moore wrote: > > It's a combination of several things - one, requiring that a domain > operate its own mail submission servers which sign their mail (and all > that that implies, like maintaining the private keys). That's just part of running a mail system. > Two, many domains will be too small to develop enough of a reputation to > be whitelisted, and any spammer can create a temporary domain which will > have about as good a reputation as the vast majority of those domains. Free domain tasting is a problem that affects lots of reputation system, not just ones based on DKIM. If ICANN were to eliminate it lots of things would become easier. Also, at the moment negative reputation is more useful (or at least easier to use) than positive reputation so I don't see neutral reputation as a bad thing (er, by definition it isn't). > Three, as long as people use Windows boxes, spammers will be able to > compromise them and hijack them to use them to originate mail on behalf > of their domains, thus degrading those domains' reputation. The criminals can steal infected users' online banking credentials too, which is far more worrying. Everyone has to keep their networks clean for many reasons, not just spam. Tony. -- f.a.n.finch http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 08:50:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfEP5-0005zG-19; Tue, 09 Oct 2007 08:41:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfEP2-0005Cu-QB; Tue, 09 Oct 2007 08:41:36 -0400 Received: from [202.28.99.196] (helo=jade.coe.psu.ac.th) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfEOp-00012w-Vi; Tue, 09 Oct 2007 08:41:25 -0400 Received: from delta.noi.kre.to (delta-194 [172.30.3.194]) by jade.coe.psu.ac.th with ESMTP id l99Cf9BV028531; Tue, 9 Oct 2007 19:41:09 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.11/8.11.6) with ESMTP id l99CeliD012491; Tue, 9 Oct 2007 19:40:47 +0700 (ICT) From: Robert Elz To: Eliot Lear In-Reply-To: <470A30CC.2030603@cisco.com> References: <470A30CC.2030603@cisco.com> <20071008014006.88BB233C21@delta.rtfm.com> <4709D647.7070004@piuha.net> <20071008125725.3B71233C57@delta.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Oct 2007 19:40:47 +0700 Message-ID: <18636.1191933647@munnari.OZ.AU> X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: iesg@ietf.org, Jari Arkko , ietf@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Date: Mon, 08 Oct 2007 15:29:48 +0200 From: Eliot Lear Message-ID: <470A30CC.2030603@cisco.com> | We are overlapping a term that is | commonly used by the ITU the way working group is used by the IETF. | Let's not make the process any more confusing than it already is. Yes, avoiding that kind of confusion, when it is so easy to accomplish by careful choices at the start is definitely the right thing to do. "Study" is just the acquisition of knowledge right, so instead of study, let's say knowledge aquisition instead (it's only ever going to be used as its acronym anyway, right?) Now, KAG or AKG aren't quite right., and GAK probably isn't what anyone really wants, so instead call it worthless acquisition of needless knowledge. kre _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 08:50:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfEEZ-0002Pf-W5; Tue, 09 Oct 2007 08:30:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfEEX-0002PD-Oq; Tue, 09 Oct 2007 08:30:45 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfEER-0005jZ-FD; Tue, 09 Oct 2007 08:30:45 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2D50D198683; Tue, 9 Oct 2007 15:30:23 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id DAC01198658; Tue, 9 Oct 2007 15:30:22 +0300 (EEST) Message-ID: <470B745F.4010402@piuha.net> Date: Tue, 09 Oct 2007 15:30:23 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Eric Rescorla References: <20071008014006.88BB233C21@delta.rtfm.com> <4709D647.7070004@piuha.net> <20071008125725.3B71233C57@delta.rtfm.com> In-Reply-To: <20071008125725.3B71233C57@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: iesg@ietf.org, ietf@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Eric, > I'm not saying that we shouldn't consider new work either, > and we do consider new work under the current system. OK > However, > since the amount of work we can do is to a great degree constant, > that means that any new work should be more important than > whatever we're doing now. Making it easier to start new > work (which is pretty much an explicit goal of this proposal) > is likely to create a situation in which more new work gets > done at the expense of current work. That might or might > not be good depending on what one thinks of the current work. > I think the goal should be to make the process itself smooth, and concentrate on the question of relevance, feasibility, community support, and available resources as the deciding factors for taking up new work. > Absolutely. But I think this is going to create a structural > near-imperative to saying yes, in the same way that the IESG > feels strong pressure to advance documents from chartered > WGs, even if it's clear in retrospect that the output isn't > of much value and probably shouldn't have been chartered in > the first place. > The structural near-imperative is somewhat self-inflicted, IMHO. I would not want to have such a policy for SG to WG transition, and I think this could be made clear in the proposal if it isn't already. Jari _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 08:54:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfEVb-0008Mn-8G; Tue, 09 Oct 2007 08:48:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IetVE-0005dW-O8 for ietf@ietf.org; Mon, 08 Oct 2007 10:22:36 -0400 Received: from smtp1.wanadoo.co.uk ([193.252.22.158] helo=smtp1.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IetV4-0000l8-Tc for ietf@ietf.org; Mon, 08 Oct 2007 10:22:36 -0400 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3001.me.freeserve.com (SMTP Server) with ESMTP id 0C3301C000E7; Mon, 8 Oct 2007 16:22:21 +0200 (CEST) Received: from Codalogic (user-5af19a7a.tcl111.dsl.pol.co.uk [90.241.154.122]) by mwinf3001.me.freeserve.com (SMTP Server) with SMTP id 70B6E1C000E2; Mon, 8 Oct 2007 16:22:20 +0200 (CEST) X-ME-UUID: 20071008142220461.70B6E1C000E2@mwinf3001.me.freeserve.com Message-ID: <001501c809b6$a1f9a710$5d00a8c0@Codalogic> From: "Pete Cordell" To: References: Date: Mon, 8 Oct 2007 15:22:10 +0100 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-Mailman-Approved-At: Tue, 09 Oct 2007 08:48:18 -0400 Cc: pierre@radvision.com, oritl@microsoft.com, roni.even@polycom.co.il Subject: Re: Last Call: draft-levin-mmusic-xml-media-control (XML Schema for Media Control) to Informational RFC X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I quickly looked at this and noticed that the XML instance examples don't match the schema because the instance does not make reference to the namespace. i.e., to match the schema, the example should be: My expectation is that the instance is actually more authorative in terms of what the authors are looking for. If that is the case, the schema should be modified along the lines of: ... i.e. remove the targetNamespace declarations. You may have your reasons not to, but if not, you may want to consider using schema's documentation features instead of the XML comments; e.g.: Video control primitive. ... HTH, Pete. -- ============================================= Pete Cordell Codalogic for XML Schema to C++ data binding visit http://www.codalogic.com/lmx/ ============================================= ----- Original Message ----- From: "The IESG" To: "IETF-Announce" Sent: Monday, October 08, 2007 2:29 PM Subject: Last Call: draft-levin-mmusic-xml-media-control (XML Schema for Media Control) to Informational RFC > The IESG has received a request from an individual submitter to consider > the following document: > > - 'XML Schema for Media Control ' > as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2007-11-05. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-levin-mmusic-xml-media-control-11.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=9391&rfc_flag=0 > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 08:54:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfEVb-0008UX-W4; Tue, 09 Oct 2007 08:48:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If1QB-00064s-MY for ietf@ietf.org; Mon, 08 Oct 2007 18:49:55 -0400 Received: from bay0-omc3-s30.bay0.hotmail.com ([65.54.246.230]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1If1QB-0001cs-7F for ietf@ietf.org; Mon, 08 Oct 2007 18:49:55 -0400 Received: from hotmail.com ([207.46.8.112]) by bay0-omc3-s30.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Oct 2007 15:49:54 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 Oct 2007 15:49:54 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Mon, 08 Oct 2007 22:49:51 GMT X-Originating-IP: [131.107.0.72] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: ietf@ietf.org Bcc: Date: Mon, 08 Oct 2007 15:49:51 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 08 Oct 2007 22:49:54.0064 (UTC) FILETIME=[8AD4D900:01C809FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-Mailman-Approved-At: Tue, 09 Oct 2007 08:48:18 -0400 Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Eric Rescorla said: "Arguably, SG formation should be subject to an IETF LC in the same way that WG formation is." I would agree -- and it would appear that this is already included in Section 3: Other than the abbreviated charter, the process for formation of a Study Group is identical to that of a Working Group, including announcement of the potential Study Group and a request for feedback from the IETF community. "1. It will be hard for the IESG to deny "successful" SGs the right to form a WG." Since successful is in quotes, are we really talking about "failed" SGs? A SG can fail by not completing its milestones in time, and having the AD refuse to grant an extension, or it can fail by producing a Charter that fails to garner approval from the IESG/IAB, just as a proposed WG might. Perhaps we need a statement that the bar for transition from a SG to a WG is the same as one from a BOF to a WG? "Since the point of a BOF is to encourage widespread input and more or less by definition an SG has failed at this stage, it seems unwise to allow SGs to become WGs without a real public vetting stage." Such a public vetting stage is built in because the SG chaFrom ietf-bounces@ietf.org Tue Oct 09 08:54:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfEVb-0008Mn-8G; Tue, 09 Oct 2007 08:48:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IetVE-0005dW-O8 for ietf@ietf.org; Mon, 08 Oct 2007 10:22:36 -0400 Received: from smtp1.wanadoo.co.uk ([193.252.22.158] helo=smtp1.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IetV4-0000l8-Tc for ietf@ietf.org; Mon, 08 Oct 2007 10:22:36 -0400 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3001.me.freeserve.com (SMTP Server) with ESMTP id 0C3301C000E7; Mon, 8 Oct 2007 16:22:21 +0200 (CEST) Received: from Codalogic (user-5af19a7a.tcl111.dsl.pol.co.uk [90.241.154.122]) by mwinf3001.me.freeserve.com (SMTP Server) with SMTP id 70B6E1C000E2; Mon, 8 Oct 2007 16:22:20 +0200 (CEST) X-ME-UUID: 20071008142220461.70B6E1C000E2@mwinf3001.me.freeserve.com Message-ID: <001501c809b6$a1f9a710$5d00a8c0@Codalogic> From: "Pete Cordell" To: References: Date: Mon, 8 Oct 2007 15:22:10 +0100 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-Mailman-Approved-At: Tue, 09 Oct 2007 08:48:18 -0400 Cc: pierre@radvision.com, oritl@microsoft.com, roni.even@polycom.co.il Subject: Re: Last Call: draft-levin-mmusic-xml-media-control (XML Schema for Media Control) to Informational RFC X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I quickly looked at this and noticed that the XML instance examples don't match the schema because the instance does not make reference to the namespace. i.e., to match the schema, the example should be: My expectation is that the instance is actually more authorative in terms of what the authors are looking for. If that is the case, the schema should be modified along the lines of: ... i.e. remove the targetNamespace declarations. You may have your reasons not to, but if not, you may want to consider using schema's documentation features instead of the XML comments; e.g.: Video control primitive. ... HTH, Pete. -- ============================================= Pete Cordell Codalogic for XML Schema to C++ data binding visit http://www.codalogic.com/lmx/ ============================================= ----- Original Message ----- From: "The IESG" To: "IETF-Announce" Sent: Monday, October 08, 2007 2:29 PM Subject: Last Call: draft-levin-mmusic-xml-media-control (XML Schema for Media Control) to Informational RFC > The IESG has received a request from an individual submitter to consider > the following document: > > - 'XML Schema for Media Control ' > as an Informational RFC > > The IESG plans to make a decisiorter and other documents will be reviewed by the IETF community. Dan Romascanu said: "The way I see it the problem that this proposal tries to solve is about helping the IESG and the community to make a better decision when the forming of the working group us discussed. It is not about bringing more work to the IETF, it is about making sure to a better extent that the right work is being brought into the IETF. " I agree. Presumably the SG will enable a more rigorous and complete examination of the WG formation criteria already set down in RFC 2418. That should enable an AD to get a better idea of how well a SG would function if it were to be chartered as a WG. Spencer Dawkins said: "to use the IRTF as a home for WG explorations, in addition to research" Unfortunately, there are very few examples of the IRTF being used successfully for this purpose. Rather than being a step toward WG formation, the IRTF has often be used as a "consolation prize" for work that was far from the level of maturity required for WG formation. Those RGs often dragged on for years often with little impact on the IETF. The goal of SGs is more immediate -- for situations where interest already exists, but where 6-12 months of prepatory work would be likely to produce a solid foundation for a WG. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf n in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2007-11-05. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-levin-mmusic-xml-media-control-11.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=9391&rfc_flag=0 > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 08:54:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfEVb-0008UX-W4; Tue, 09 Oct 2007 08:48:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If1QB-00064s-MY for ietf@ietf.org; Mon, 08 Oct 2007 18:49:55 -0400 Received: from bay0-omc3-s30.bay0.hotmail.com ([65.54.246.230]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1If1QB-0001cs-7F for ietf@ietf.org; Mon, 08 Oct 2007 18:49:55 -0400 Received: from hotmail.com ([207.46.8.112]) by bay0-omc3-s30.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Oct 2007 15:49:54 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 Oct 2007 15:49:54 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Mon, 08 Oct 2007 22:49:51 GMT X-Originating-IP: [131.107.0.72] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: ietf@ietf.org Bcc: Date: Mon, 08 Oct 2007 15:49:51 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 08 Oct 2007 22:49:54.0064 (UTC) FILETIME=[8AD4D900:01C809FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-Mailman-Approved-At: Tue, 09 Oct 2007 08:48:18 -0400 Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Eric Rescorla said: "Arguably, SG formation should be subject to an IETF LC in the same way that WG formation is." I would agree -- and it would appear that this is already included in Section 3: Other than the abbreviated charter, the process for formation of a Study Group is identical to that of a Working Group, including announcement of the potential Study Group and a request for feedback from the IETF community. "1. It will be hard for the IESG to deny "successful" SGs the right to form a WG." Since successful is in quotes, are we really talking about "failed" SGs? A SG can fail by not completing its milestones in time, and having the AD refuse to grant an extension, or it can fail by producing a Charter that fails to garner approval from the IESG/IAB, just as a proposed WG might. Perhaps we need a statement that the bar for transition from a SG to a WG is the same as one from a BOF to a WG? "Since the point of a BOF is to encourage widespread input and more or less by definition an SG has failed at this stage, it seems unwise to allow SGs to become WGs without a real public vetting stage." Such a public vetting stage is built in because the SG charter and other documents will be reviewed by the IETF community. Dan Romascanu said: "The way I see it the problem that this proposal tries to solve is about helping the IESG and the community to make a better decision when the forming of the working group us discussed. It is not about bringing more work to the IETF, it is about making sure to a better extent that the right work is being brought into the IETF. " I agree. Presumably the SG will enable a more rigorous and complete examination of the WG formation criteria already set down in RFC 2418. That should enable an AD to get a better idea of how well a SG would function if it were to be chartered as a WG. Spencer Dawkins said: "to use the IRTF as a home for WG explorations, in addition to research" Unfortunately, there are very few examples of the IRTF being used successfully for this purpose. Rather than being a step toward WG formation, the IRTF has often be used as a "consolation prize" for work that was far from the level of maturity required for WG formation. Those RGs often dragged on for years often with little impact on the IETF. The goal of SGs is more immediate -- for situations where interest already exists, but where 6-12 months of prepatory work would be likely to produce a solid foundation for a WG. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 09:21:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfEsw-0004g4-Fp; Tue, 09 Oct 2007 09:12:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfEsv-0004fE-9j for ietf@ietf.org; Tue, 09 Oct 2007 09:12:29 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfEsp-00073h-4M for ietf@ietf.org; Tue, 09 Oct 2007 09:12:29 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 8B4821EE318; Tue, 9 Oct 2007 09:12:07 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9ORu160dyZk; Tue, 9 Oct 2007 09:12:02 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 4F7551EE27A; Tue, 9 Oct 2007 09:11:53 -0400 (EDT) Message-ID: <470B7E11.7030901@cs.utk.edu> Date: Tue, 09 Oct 2007 09:11:45 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Tony Finch References: <2788466ED3E31C418E9ACC5C31661557053529@mou1wnexmb09.vcorp.ad.vrsn.com> <4705414B.5000109@cs.utk.edu> <470AC324.70604@cs.utk.edu> In-Reply-To: X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Fred Baker , ietf@ietf.org Subject: Re: DKIM reputation, was Re: Spammers answering TMDA Queries X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Tony Finch wrote: > On Mon, 8 Oct 2007, Keith Moore wrote: > >> It's a combination of several things - one, requiring that a domain >> operate its own mail submission servers which sign their mail (and all >> that that implies, like maintaining the private keys). >> > > That's just part of running a mail system. > yes, but it's not inherently part of running a mail domain. it's unreasonable to require everyone to use mail submission servers that are entrusted with their domain's DKIM private keys. >> Two, many domains will be too small to develop enough of a reputation to >> be whitelisted, and any spammer can create a temporary domain which will >> have about as good a reputation as the vast majority of those domains. >> > > Free domain tasting is a problem that affects lots of reputation system, > not just ones based on DKIM. If ICANN were to eliminate it lots of things > would become easier. > it's a problem even without "free domain tasting". > Also, at the moment negative reputation is more useful (or at least easier > to use) than positive reputation so I don't see neutral reputation as a > bad thing (er, by definition it isn't). > negative reputation of a domain is of minimal value, because spammers will just get a new domain (or several) every time they wish to spam, and the new domains will have neutral reputation. >> Three, as long as people use Windows boxes, spammers will be able to >> compromise them and hijack them to use them to originate mail on behalf >> of their domains, thus degrading those domains' reputation. >> > > The criminals can steal infected users' online banking credentials too, > which is far more worrying. Everyone has to keep their networks clean for > many reasons, not just spam. > nuclear war is more worrying too. but that doesn't mean that the ease in compromising PCs isn't a big contributor to the spam problem. as for "keeping...networks clean", well, of course people should try to do that. but as far as I can tell, so far it's more of a laudable goal than a practical reality. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 10:27:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfFre-000092-Kk; Tue, 09 Oct 2007 10:15:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfFrb-0008Te-1P for ietf@ietf.org; Tue, 09 Oct 2007 10:15:11 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfFrK-0004IK-C9 for ietf@ietf.org; Tue, 09 Oct 2007 10:14:54 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JPN00HK8E8T59@usaga01-in.huawei.com> for ietf@ietf.org; Tue, 09 Oct 2007 07:14:53 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JPN008OHE8R6T@usaga01-in.huawei.com> for ietf@ietf.org; Tue, 09 Oct 2007 07:14:53 -0700 (PDT) Date: Tue, 09 Oct 2007 09:14:29 -0500 From: Spencer Dawkins To: ietf@ietf.org Message-id: <06c701c80a7e$b4ee43d0$6a01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=Windows-1252; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi, Bernard, > Spencer Dawkins said: > > "to use the IRTF as a home for WG explorations, in addition to research" > > Unfortunately, there are very few examples of the IRTF being used > successfully for this purpose. Rather than being a step toward WG > formation, the IRTF has often be used as a "consolation prize" for work > that was far from the level of maturity required for WG formation. Those > RGs often dragged on for years often with little impact on the IETF. The > goal of SGs is more immediate -- for situations where interest already > exists, but where 6-12 months of prepatory work would be likely to produce > a solid foundation for a WG. I agree on the history here (not sure I would have said "often", but not sure I know enough to quantify). The IRTF may have the right level of formality and process for investigations, but a lot of other attributes that aren't right, and (of course) they may not be interested in playing host to these investigations, at any rate. I'm really struggling with the conflict between relatively unrestricted investigations and relatively obscure discussions, and I'm not sure there's a really good answer. The SG proposal may be as good as a proposed answer gets, and an experiment with a limited number of SGs may be as good a way to find out if the proposal works as there is. Thanks, Spencer _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 12:02:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfHKi-00021X-Ah; Tue, 09 Oct 2007 11:49:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfHKg-00021S-T2 for ietf@ietf.org; Tue, 09 Oct 2007 11:49:19 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfHKg-0006Lb-BJ for ietf@ietf.org; Tue, 09 Oct 2007 11:49:18 -0400 X-IronPort-AV: E=Sophos;i="4.21,249,1188792000"; d="scan'208";a="73514892" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 09 Oct 2007 11:49:17 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l99FnIpI003643; Tue, 9 Oct 2007 11:49:18 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l99FnHt2001437; Tue, 9 Oct 2007 15:49:17 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 11:49:16 -0400 Received: from [161.44.65.201] ([161.44.65.201]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 11:49:15 -0400 In-Reply-To: <4707ECB0.6020302@gmail.com> References: <46EAE465.8070104@dcrocker.net> <4707ECB0.6020302@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <26E67D75-E5A0-4142-AC29-7CB0C24FFBD0@cisco.com> Content-Transfer-Encoding: 7bit From: Ralph Droms Date: Tue, 9 Oct 2007 11:49:25 -0400 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 09 Oct 2007 15:49:15.0943 (UTC) FILETIME=[F226F370:01C80A8B] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15466.000 X-TM-AS-Result: No--19.715600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1801; t=1191944958; x=1192808958; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20Call=20for=20action=20vs.=20lost=20opportunity=20(Was =3A=20Re=3A=20Renumbering) |Sender:=20 |To:=20Brian=20E=20Carpenter=20; bh=uVR6+xDfoEza96DhdaV1heQn5yoK1qzuchiUDpydaSo=; b=g8CuTGjDlwsLVqPsxYUsLE2qs6ujoPW3V9h8yXXMDDkLUvpg3ejQYFvYjlm45DPWzrqDDk92 nBWhjBaBnNi6xBhShnYLHpijfDg92UGuVs5XXIUxE9N3823b5bm4CS75; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: IETF-Discussion Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Brian - is it provable that no design for a follow-on to IPv4 would have provided that backward compatibility? Or were there architectural and engineering decisions that chose other features over backward compatibility? And, I guess I'll stop here as I'm rehashing a train that long ago left the station... - Ralph On Oct 6, 2007, at Oct 6, 2007,4:14 PM, Brian E Carpenter wrote: > On 2007-10-05 09:12, Ralph Droms wrote: >> Typo: should read IPv6 ~= IPv4+more_bits... >> - Ralph >> On Oct 4, 2007, at Oct 4, 2007,4:52 AM, Ralph Droms wrote: >>> Regarding transition: >>> >>> On Sep 14, 2007, at Sep 14, 2007,3:43 PM, Dave Crocker wrote: >>>> >>>> >>>> Unless I've missed something rather basic, in the case of IPv6, >>>> very little >>>> attention was paid to facilitating transition by maximizing >>>> interoperability >>>> with the IPv4 installed base. >>> Dave, I have to agree with you in this regard. We may have >>> achieved neither >>> significant new capabilities because IPv6 ~= IPv6+more_bits, nor >>> ease of >>> transition because transition wasn't thoroughly evaluated early >>> on in >>> the design process... > > Ralph, that last assertion simply isn't true. Migration/transition/ > co-existence was on the radar screen right from the start. The dual > stack model was chosen explicitly to allow for co-existence, and in > particular so that dual stack servers can serve both IPv4 and IPv6 > clients, and that is running code. > > There's a fundamental difficulty in having IPvX-only clients working > with IPvY-only servers except via application-level relays. It isn't > a consequence of design details of v4 and v6. I'm sure we could > have done better, but this was very definitely thought about. > > Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 12:02:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfHFY-0001Uq-Fu; Tue, 09 Oct 2007 11:44:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfHFX-0001Uc-5E for ietf@ietf.org; Tue, 09 Oct 2007 11:43:59 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfHFW-0006FS-O5 for ietf@ietf.org; Tue, 09 Oct 2007 11:43:59 -0400 X-IronPort-AV: E=Sophos;i="4.21,249,1188802800"; d="scan'208";a="22283927" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 09 Oct 2007 08:43:58 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l99Fhwi9028362; Tue, 9 Oct 2007 08:43:58 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l99FhdaA008868; Tue, 9 Oct 2007 15:43:58 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 11:43:47 -0400 Received: from [161.44.65.201] ([161.44.65.201]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 11:43:46 -0400 In-Reply-To: <4707ECB0.6020302@gmail.com> References: <46EAE465.8070104@dcrocker.net> <4707ECB0.6020302@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <27D40B9A-0906-46F1-B411-CAE4C4AC8BA2@cisco.com> Content-Transfer-Encoding: 7bit From: Ralph Droms Date: Tue, 9 Oct 2007 11:43:56 -0400 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 09 Oct 2007 15:43:46.0613 (UTC) FILETIME=[2DDB2E50:01C80A8B] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15466.000 X-TM-AS-Result: No--19.976200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1785; t=1191944638; x=1192808638; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20Call=20for=20action=20vs.=20lost=20opportunity=20(Was =3A=20Re=3A=20Renumbering) |Sender:=20; bh=51V6hefAq71ip2YGTU5iPhWE3xrHgmiKmHwVAycG3sg=; b=OFIwSo12l/7w5vskV4Yhut9PfLYaVJ/snJ2OYMHZorMSSoEhTx+88SzXdne7rVPXQqEV7o5I RclLxkF6s7zcM5r3uyB4H32FYxHz/vPl7OnuCazPcnbYCUXG75p+qV+m; Authentication-Results: sj-dkim-4; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: IETF-Discussion Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Brian - OK, I agree that a wide range of tunneling/translation mechanisms have been considered; was the transition problem considered during the basic design? In any event, in my opinion we don't have a fundamental level of backward compatibility that would solve the current deployment issues. - Ralph On Oct 6, 2007, at Oct 6, 2007,4:14 PM, Brian E Carpenter wrote: > On 2007-10-05 09:12, Ralph Droms wrote: >> Typo: should read IPv6 ~= IPv4+more_bits... >> - Ralph >> On Oct 4, 2007, at Oct 4, 2007,4:52 AM, Ralph Droms wrote: >>> Regarding transition: >>> >>> On Sep 14, 2007, at Sep 14, 2007,3:43 PM, Dave Crocker wrote: >>>> >>>> >>>> Unless I've missed something rather basic, in the case of IPv6, >>>> very little >>>> attention was paid to facilitating transition by maximizing >>>> interoperability >>>> with the IPv4 installed base. >>> Dave, I have to agree with you in this regard. We may have >>> achieved neither >>> significant new capabilities because IPv6 ~= IPv6+more_bits, nor >>> ease of >>> transition because transition wasn't thoroughly evaluated early >>> on in >>> the design process... > > Ralph, that last assertion simply isn't true. Migration/transition/ > co-existence was on the radar screen right from the start. The dual > stack model was chosen explicitly to allow for co-existence, and in > particular so that dual stack servers can serve both IPv4 and IPv6 > clients, and that is running code. > > There's a fundamental difficulty in having IPvX-only clients working > with IPvY-only servers except via application-level relays. It isn't > a consequence of design details of v4 and v6. I'm sure we could > have done better, but this was very definitely thought about. > > Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 12:59:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfIBI-0003Qi-Ug; Tue, 09 Oct 2007 12:43:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfIBH-0003Ov-B6 for ietf@ietf.org; Tue, 09 Oct 2007 12:43:39 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfIBG-0004Vz-4c for ietf@ietf.org; Tue, 09 Oct 2007 12:43:39 -0400 X-IronPort-AV: E=Sophos;i="4.21,249,1188802800"; d="scan'208";a="233433207" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 09 Oct 2007 09:43:32 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l99GhWA5004361; Tue, 9 Oct 2007 09:43:32 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l99GhNa1018369; Tue, 9 Oct 2007 16:43:32 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 09:43:29 -0700 Received: from [192.168.0.101] ([10.21.69.233]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 09:43:29 -0700 In-Reply-To: <26E67D75-E5A0-4142-AC29-7CB0C24FFBD0@cisco.com> References: <46EAE465.8070104@dcrocker.net> <4707ECB0.6020302@gmail.com> <26E67D75-E5A0-4142-AC29-7CB0C24FFBD0@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Date: Tue, 9 Oct 2007 09:43:21 -0700 To: Ralph Droms X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 09 Oct 2007 16:43:29.0314 (UTC) FILETIME=[854FF820:01C80A93] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=848; t=1191948212; x=1192812212; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20Call=20for=20action=20vs.=20lost=20opportunity=20(Was =3A=20Re=3A=20Renumbering) |Sender:=20; bh=eMvHInSN/AfDQzU9NvQ1V0eTzSPnZmdFaMTf2MAwn/Q=; b=FCX6O8AmRfMWvym28jo+LK0kHqnIPG+1kkBGQnd00huAXhxsdnlc993LYBfoMVpHmdI4c7dQ 14UK6NxoFxRal/xt1b5JKDWXQtCx2hFFHTQHZHk42A05rGjePSX4JAKr; Authentication-Results: sj-dkim-4; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: IETF-Discussion Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 9, 2007, at 8:49 AM, Ralph Droms wrote: > is it provable that no design for a follow-on to IPv4 would have > provided that backward compatibility? Hi Ralph, I don't know about 'provable', but there's a strong argument as to why that's challenging. Any new design would have necessarily required more bits to address more end systems. Making legacy systems interact with these additional addressing bits without some form of gateway, NAT or other translation would indeed be challenging. You're literally trying to expand the size of the namespace that a legacy implementation will recognize. > And, I guess I'll stop here as I'm rehashing a train that long ago > left the station... While the train has left the station, it seems like it can still be modified while in motion. Tony _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 13:11:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfIOa-0007cf-Ew; Tue, 09 Oct 2007 12:57:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfIOY-0007cJ-NI; Tue, 09 Oct 2007 12:57:22 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfIOY-0007nt-CF; Tue, 09 Oct 2007 12:57:22 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l99GvD7i000785; Tue, 9 Oct 2007 12:57:13 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l99GvBGd129948; Tue, 9 Oct 2007 12:57:13 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l99Gv6i6026210; Tue, 9 Oct 2007 12:57:06 -0400 Received: from poplar (poplar.watson.ibm.com [9.2.40.57]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l99Gv6NA025709; Tue, 9 Oct 2007 12:57:06 -0400 Received: from Uranus-009002042022.watson.ibm.com ([9.2.42.22]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1191949019.1051; Tue, 09 Oct 2007 12:56:59 -0400 Date: Tue, 09 Oct 2007 12:57:01 -0400 From: Barry Leiba To: miguel.garcia@nsn.com, jon.peterson@neustar.biz Message-ID: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: secdir@mit.edu, iesg@ietf.org, ietf@ietf.org Subject: secdir review of draft-garcia-simple-presence-dictionary-06 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I have no issues with this document's content nor with its security considerations -- it all seems fine. A couple of editorial nits, though, while I'm here: Introduction, paragraph 2: "Typically, presence documents can contain large bulks of data." That sounds awkward. Either "large chunks of data" (if you mean discrete "bulks") or "a large amount of data" (if you just mean that there's a lot there) is better. At the top of page 6, "it is typically prepended by the '<' and '>' signs, such as in ''." That should be "surrounded by". Throughout, all instances of "is comprised of" should be either "comprises" or "is composed of". The word "comprises" means "is composed of", and that's the correct usage (though it's a *very* common error, even among most native English speakers). Barry -- Barry Leiba, STSM, Internet Messaging Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 14:40:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfJqE-00015Y-3R; Tue, 09 Oct 2007 14:30:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfJqC-0000sC-Q4 for ietf@ietf.org; Tue, 09 Oct 2007 14:30:00 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfJq8-00029P-9v for ietf@ietf.org; Tue, 09 Oct 2007 14:29:56 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l99I23am014153; Tue, 9 Oct 2007 11:02:08 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Tue, 09 Oct 2007 11:29:36 -0700 X-PGP-Universal: processed; by terminus.local on Tue, 09 Oct 2007 11:29:36 -0700 In-Reply-To: References: <46EAE465.8070104@dcrocker.net> <4707ECB0.6020302@gmail.com> <26E67D75-E5A0-4142-AC29-7CB0C24FFBD0@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <6804D47B-9765-496C-BF0A-F4B4C7BCC441@virtualized.org> From: David Conrad Date: Tue, 9 Oct 2007 11:29:30 -0700 To: Tony Li X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: IETF-Discussion Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 9, 2007, at 9:43 AM, Tony Li wrote: > Any new design would have necessarily required more bits to address > more end systems. Making legacy systems interact with these > additional addressing bits without some form of gateway, NAT or > other translation would indeed be challenging. You're literally > trying to expand the size of the namespace that a legacy > implementation will recognize. 32 bit AS numbers. Regards, -drc _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 15:00:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfKAx-0007cA-R3; Tue, 09 Oct 2007 14:51:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfKAw-0007Tl-Ch for ietf@ietf.org; Tue, 09 Oct 2007 14:51:26 -0400 Received: from harry.mail-abuse.org ([168.61.5.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfKAt-0002uH-FT for ietf@ietf.org; Tue, 09 Oct 2007 14:51:24 -0400 Received: from [10.2.164.130] (SJC-Office-NAT-212.Mail-Abuse.ORG [168.61.10.212]) by harry.mail-abuse.org (Postfix) with ESMTP id C5EA24143D; Tue, 9 Oct 2007 11:51:22 -0700 (PDT) In-Reply-To: References: <2788466ED3E31C418E9ACC5C316615570534E4@mou1wnexmb09.vcorp.ad.vrsn.com><6.2.5.6.2.20071004111028.031d08e0@resistor.net> <3D19D707-31B1-4753-8B33-2F9761A5451A@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <41DFA083-E582-4A09-9C6D-A73EB5E93BA0@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Date: Tue, 9 Oct 2007 11:51:25 -0700 To: Frank Ellermann X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: ietf@ietf.org Subject: Re: TMDA backscatter X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 9, 2007, at 3:59 AM, Frank Ellermann wrote: > Douglas Otis wrote: > >> There is a real risk SPF might be used as basis for acceptance > > You can combine white lists with SPF PASS as with DKIM "PASS", the > risk is very similar. Due to the macro nature of SPF, full processing is required for each name evaluated. With SPF, the recipient might be interested in the PRA, or MAIL FROM. Of course DKIM now adds d= or i= identities. Since DKIM is prone to replay abuse, when an SPF hammer is the only tool, more names are likely to be added to the evaluation. These additional evaluations are intended to reduce the number of messages lost since neither the PRA and MAIL FROM are limited to the path registered by an SPF address list. Now imagine an iterative process of developing comprehensive lists of all addresses used on behalf of a domain which attempts to embrace IPv6. : ( >> Much of the danger of auto responses has to do with DDoS concerns. > > It depends on the definition of "DDoS". From my POV as POP3 user > over a V.90 connection 10,000 unsolicited mails are just bad, no > matter what it is (spam, worm, DSN, or auto-response). Perhaps IANA should allow ISPs to register their dynamic address space. Greater protection is afforded when excluding dynamic address space. Nevertheless, more protection would be afforded by a convention that excludes message content within a DSN. For each directly addressed spam source, there are 3 DSN sources that include spam message content. Cleaning up how DSNs are constructed would be _far_ more effective than asking that all DSNs be dropped when SPF does not produce a PASS. Perhaps that is why Bell Canada ensures all addresses achieve a PASS. : ( > It's not really a "DDoS". SPF at least helped me to get rid of the > bogus DSNs and other auto-responses since three years, smart > spammers are not interested to forge SPF FAIL protected addresses. Spammers are equally uninterested in abusing MTAs that produce DSNs compliant to RFC3464 where message content has been removed. This strategy also avoids the SPF overhead and related risks. : ) > BTW, I think the definition of "Joe job" in the sieve EREJECT draft > is obsolete, the mere abuse of "plausible" addresses is no "Joe > job" and IMO also not a real DDoS. But it's certainly bad for the > victims, it can be bad enough to make a mailbox unusable for some > victims. Yes, DSNs that include content are a problem. Dropping NDN or DSN that indicate a failure of some sort also makes email less reliable. Email has become far less reliable as a result. The TPA-SSP scheme for DKIM allows a return path to authorize the DKIM signature only to encourage the issue of DSNs. Again, those DSNs should still exclude original message content. >> A safer approach would be to format all DSNs per RFC3464 and >> remove original message content. > > I'd hope that a majority of receivers already does this, that's > state of the art for some years now. Or rather "truncate" is state > of the art, not complete removal of the body. It would be rather tempting to make this mode of DSN operation a requirement. At any point of time, we see some 20 million different MTAs which do not remove message content are currently being exploited. Perhaps we should add a new list that indicates which MTAs do not remove content on DSNs? We could then let our customers decide whether they want traffic from these MTAs as well. Not all that different from open-proxies and aimed at restoring DSN integrity. >> Mailman made a mistake where an error caused a DSN that returned >> original content without first verifying the validity of the >> return path. > > Auto responders aren't in a good position to verify the validity of > the return path. Good positions to do this are the MSA based on > RFC 4409 and later the MX based on RFC 4408. RFC4408 did not mitigate a potential DDoS exploit. This exploit exists when recipients attempt to process SPF as specified. There are several SPF parsing libraries that lack even suggested limits on subsequent address resolutions for MX records, for example. There are some libraries that restrict the number of MX targets and cause some domains to not be fully resolved at times. Even this reduction in possible MX targets will not make these libraries much safer. The SPF DoS draft example clearly illustrates an SPF process (current open source compliant with RFC4408) might generate more than 50 to 100 DNS transactions per name evaluated. The level of this risk depends upon the negative caching of recipients and how frequently the local-part of the spam campaign repeats. The latter only needs to be a bit longer than the former. The evaluation process may still result in an SPF PASS. Any reliance upon SPF is likely to cause a list of names being evaluated to grow. An SPF iterative process also means poisoning DNS is made far easier. Keep in mind there are now plug-ins for web-clients and MUAs. As it is now, those clever enough to manipulate SPF libraries are also able to instigate a reflected attack on par with leveraging large RRs against a phalanx of open recursive servers. SPF however makes this attack free for those that also wish to spam. SPF would also obscure the origin of the attack. The source might not be found in mail logs either. : ( -Doug _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 15:28:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfKeH-0000OP-R2; Tue, 09 Oct 2007 15:21:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfKeG-0000OK-PF for ietf@ietf.org; Tue, 09 Oct 2007 15:21:44 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfKeF-0000Zw-IO for ietf@ietf.org; Tue, 09 Oct 2007 15:21:44 -0400 X-IronPort-AV: E=Sophos;i="4.21,250,1188802800"; d="scan'208";a="533113890" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 09 Oct 2007 12:21:35 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l99JLYdJ013900; Tue, 9 Oct 2007 12:21:34 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l99JLYZp029225; Tue, 9 Oct 2007 19:21:34 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 12:21:34 -0700 Received: from [171.71.55.89] ([171.71.55.89]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 12:21:34 -0700 In-Reply-To: <6804D47B-9765-496C-BF0A-F4B4C7BCC441@virtualized.org> References: <46EAE465.8070104@dcrocker.net> <4707ECB0.6020302@gmail.com> <26E67D75-E5A0-4142-AC29-7CB0C24FFBD0@cisco.com> <6804D47B-9765-496C-BF0A-F4B4C7BCC441@virtualized.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Date: Tue, 9 Oct 2007 12:21:28 -0700 To: David Conrad X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 09 Oct 2007 19:21:34.0323 (UTC) FILETIME=[9AD17C30:01C80AA9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1084; t=1191957694; x=1192821694; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20Call=20for=20action=20vs.=20lost=20opportunity=20(Was =3A=20Re=3A=20Renumbering) |Sender:=20; bh=faikROV0kA1KucefiDz60QXxNYQ5y7A1eVXp2u9y0dc=; b=Q6Bxpli6jLEt55EKfmiDmg4fz1JAhCF5txQ+uiNClF8cvHQNbCARdVPwmmhh49XyRWFnyW1f A8ly2Hnb+2Zcpwsk7dIR9vR1IjoxRnOkT5xrLp5zenaTKUgmT5wTIDHU; Authentication-Results: sj-dkim-2; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: IETF-Discussion Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 9, 2007, at 11:29 AM, David Conrad wrote: > On Oct 9, 2007, at 9:43 AM, Tony Li wrote: >> Any new design would have necessarily required more bits to >> address more end systems. Making legacy systems interact with >> these additional addressing bits without some form of gateway, NAT >> or other translation would indeed be challenging. You're >> literally trying to expand the size of the namespace that a legacy >> implementation will recognize. > > 32 bit AS numbers. Fortunately, the legacy BGP implementations don't need to recognize the new part of the namespace. They only see the legacy space, including AS_TRANS. The new namespace is translated (with major amounts of information loss) into the old namespace for their benefit. This still doesn't provide a mechanism for legacy systems to interact directly with new systems. For example, you can't have a legacy system directly peer with a system using a 32 bit AS number. Instead, it has to be remapped to AS_TRANS. So, it's just NAT for BGP. ;-) Tony _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 17:14:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfM4R-00011r-F5; Tue, 09 Oct 2007 16:52:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfM4P-00011Y-Je for ietf@ietf.org; Tue, 09 Oct 2007 16:52:49 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfM4P-0006a4-9a for ietf@ietf.org; Tue, 09 Oct 2007 16:52:49 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id C41C51EE27C; Tue, 9 Oct 2007 16:52:48 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LmU0NUCZiIL; Tue, 9 Oct 2007 16:52:46 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 86C3E1EE26A; Tue, 9 Oct 2007 16:52:43 -0400 (EDT) Message-ID: <470BEA13.7090107@cs.utk.edu> Date: Tue, 09 Oct 2007 16:52:35 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Douglas Otis References: <2788466ED3E31C418E9ACC5C316615570534E4@mou1wnexmb09.vcorp.ad.vrsn.com><6.2.5.6.2.20071004111028.031d08e0@resistor.net> <3D19D707-31B1-4753-8B33-2F9761A5451A@mail-abuse.org> <41DFA083-E582-4A09-9C6D-A73EB5E93BA0@mail-abuse.org> In-Reply-To: <41DFA083-E582-4A09-9C6D-A73EB5E93BA0@mail-abuse.org> X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Frank Ellermann , ietf@ietf.org Subject: Re: TMDA backscatter X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Returned message content in DSNs is often essential information for debugging of mail system problems. Blindly insisting that DSNs should not return subject message content is shortsighted. We have already crippled the mail system too much as the result of naive and shortsighted spam countermeasures. Keith > > Yes, DSNs that include content are a problem. Dropping NDN or DSN > that indicate a failure of some sort also makes email less reliable. > Email has become far less reliable as a result. The TPA-SSP scheme > for DKIM allows a return path to authorize the DKIM signature only to > encourage the issue of DSNs. Again, those DSNs should still exclude > original message content. > >>> A safer approach would be to format all DSNs per RFC3464 and remove >>> original message content. >> >> I'd hope that a majority of receivers already does this, that's state >> of the art for some years now. Or rather "truncate" is state of the >> art, not complete removal of the body. > > It would be rather tempting to make this mode of DSN operation a > requirement. At any point of time, we see some 20 million different > MTAs which do not remove message content are currently being > exploited. Perhaps we should add a new list that indicates which > MTAs do not remove content on DSNs? We could then let our customers > decide whether they want traffic from these MTAs as well. Not all > that different from open-proxies and aimed at restoring DSN integrity. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 17:27:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfMWI-00025a-8E; Tue, 09 Oct 2007 17:21:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfMWG-00025U-Vz for ietf@ietf.org; Tue, 09 Oct 2007 17:21:36 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfMWF-00047X-Lu for ietf@ietf.org; Tue, 09 Oct 2007 17:21:36 -0400 Received: from [10.6.159.88] (72-255-3-179.client.stsn.net [72.255.3.179]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l99LLCDL027432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Oct 2007 14:21:14 -0700 Message-ID: <470BE18F.3070105@dcrocker.net> Date: Tue, 09 Oct 2007 16:16:15 -0400 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ralph Droms References: <46EAE465.8070104@dcrocker.net> <4707ECB0.6020302@gmail.com> <26E67D75-E5A0-4142-AC29-7CB0C24FFBD0@cisco.com> In-Reply-To: <26E67D75-E5A0-4142-AC29-7CB0C24FFBD0@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: IETF-Discussion Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Ralph Droms wrote: > Brian - is it provable that no design for a follow-on to IPv4 would have > provided that backward compatibility? Or were there architectural and > engineering decisions that chose other features over backward > compatibility? 1. Take the original, simple Deering specification. 2. Declare the initial IPv6 address space as being the current IPv4 address space, with all upper bits zero. 3. The requirement for connecting a v6 stack to a v4 stack is a very simple IP header-mapping translation, with no loss of information at the IP level. 4. The v6 stack would need to have a v4 mode, for use by v4 applications -- applications that use v4 addresses. You are now done with an initial v6 deployment. Note the absence of dual stack in any single host, the minimal incompatibility between the two versions of IP, and so on. A continuing series of incremental changes would permit incremental benefit of the larger address space in IP, routing, applications, etc. Has the added 15 years brought more functionality than this approach would have permitted? Is deployment easier? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 17:42:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfMkd-000071-4a; Tue, 09 Oct 2007 17:36:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfMkb-00006v-G9 for ietf@ietf.org; Tue, 09 Oct 2007 17:36:25 -0400 Received: from adsl-65-67-187-82.dsl.rcsntx.swbell.net ([65.67.187.82] helo=defiant.dfw.nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfMka-0007bt-VB for ietf@ietf.org; Tue, 09 Oct 2007 17:36:25 -0400 Received: from ssprunkxp (localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.13.8/8.13.8/Debian-3) with SMTP id l99LaJOH031506; Tue, 9 Oct 2007 16:36:19 -0500 Message-ID: <00ed01c80abc$64308550$423816ac@atlanta.polycom.com> From: "Stephen Sprunk" To: "Tony Li" , "David Conrad" References: <46EAE465.8070104@dcrocker.net> <4707ECB0.6020302@gmail.com><26E67D75-E5A0-4142-AC29-7CB0C24FFBD0@cisco.com><6804D47B-9765-496C-BF0A-F4B4C7BCC441@virtualized.org> Date: Tue, 9 Oct 2007 16:05:38 -0500 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Virus-Scanned: ClamAV 0.91.1/4516/Tue Oct 9 12:31:18 2007 on defiant.dfw.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: IETF-Discussion Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Thus spake "Tony Li" > On Oct 9, 2007, at 11:29 AM, David Conrad wrote: >> On Oct 9, 2007, at 9:43 AM, Tony Li wrote: >>> Any new design would have necessarily required more bits to address >>> more end systems. Making legacy systems interact >>> with these additional addressing bits without some form of >>> gateway, NAT or other translation would indeed be challenging. >>> You're literally trying to expand the size of the namespace that >>> a legacy implementation will recognize. >> >> 32 bit AS numbers. > > Fortunately, the legacy BGP implementations don't need to > recognize the new part of the namespace. They only see the > legacy space, including AS_TRANS. The new namespace is > translated (with major amounts of information loss) into the old > namespace for their benefit. This still doesn't provide a > mechanism for legacy systems to interact directly with new > systems. For example, you can't have a legacy system directly > peer with a system using a 32 bit AS number. Instead, it has > to be remapped to AS_TRANS. > > So, it's just NAT for BGP. ;-) Does that mean the IETF is going to deprecate 32-bit ASNs like was done to NAT-PT? ;-) Perhaps, if the folks hadn't been so dogmatically against NAT at the time, the v4-to-v6 transition model would have worked similarly and we'd be done with it by now... S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 20:03:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfOlq-0003Yq-5W; Tue, 09 Oct 2007 19:45:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfOlo-0003Y5-OP for ietf@ietf.org; Tue, 09 Oct 2007 19:45:48 -0400 Received: from harry.mail-abuse.org ([168.61.5.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfOlo-0003bm-Ce for ietf@ietf.org; Tue, 09 Oct 2007 19:45:48 -0400 Received: from [10.2.164.130] (SJC-Office-NAT-212.Mail-Abuse.ORG [168.61.10.212]) by harry.mail-abuse.org (Postfix) with ESMTP id C75F741470; Tue, 9 Oct 2007 16:45:47 -0700 (PDT) In-Reply-To: <470BEA13.7090107@cs.utk.edu> References: <2788466ED3E31C418E9ACC5C316615570534E4@mou1wnexmb09.vcorp.ad.vrsn.com><6.2.5.6.2.20071004111028.031d08e0@resistor.net> <3D19D707-31B1-4753-8B33-2F9761A5451A@mail-abuse.org> <41DFA083-E582-4A09-9C6D-A73EB5E93BA0@mail-abuse.org> <470BEA13.7090107@cs.utk.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Date: Tue, 9 Oct 2007 16:45:50 -0700 To: Keith Moore X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -4.0 (----) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ietf list Subject: Re: TMDA backscatter X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 9, 2007, at 1:52 PM, Keith Moore wrote: > Returned message content in DSNs is often essential information for > debugging of mail system problems. Blindly insisting that DSNs > should not return subject message content is shortsighted. We have > already crippled the mail system too much as the result of naive > and shortsighted spam countermeasures. The recommendation was to conform to requirements of RFC3464, but could have been a bit more explicit in what was meant by original content. The concern is the abuse of DSNs as an indirect content delivery mechanism. Including original content runs a much greater risk that any DSN then becomes blocked or dropped. A more difficult problem to solve occurs when no DSN is found after a message delivery fails for some reason. Less is more in terms of what should be included of original message content. Per recipient: original-recipient-field final-recipient-field action-field "failed" / "delayed" / "delivered" / "relayed" / "expanded" status-field remote-mta-field diagnostic-code-field last-attempt-date-field final-log-id-field will-retry-until-field Per message: original-envelope-id-field reporting-mta-field dsn-gateway-field received-from-mta-field arrival-date-field Is this what you would like to see in a DSN? -Doug _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 20:03:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfOkl-0002Sc-0Z; Tue, 09 Oct 2007 19:44:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfOkk-0002SP-7h for ietf@ietf.org; Tue, 09 Oct 2007 19:44:42 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfOke-0008Hn-Nv for ietf@ietf.org; Tue, 09 Oct 2007 19:44:42 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id E36C21EE2B2; Tue, 9 Oct 2007 19:44:20 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xg1I9uCe2CO5; Tue, 9 Oct 2007 19:44:18 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id BE5B21EE2A1; Tue, 9 Oct 2007 19:44:14 -0400 (EDT) Message-ID: <470C1245.8000909@cs.utk.edu> Date: Tue, 09 Oct 2007 19:44:05 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: dcrocker@bbiw.net References: <46EAE465.8070104@dcrocker.net> <4707ECB0.6020302@gmail.com> <26E67D75-E5A0-4142-AC29-7CB0C24FFBD0@cisco.com> <470BE18F.3070105@dcrocker.net> In-Reply-To: <470BE18F.3070105@dcrocker.net> X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: IETF-Discussion Subject: perfect hindsight (was Re: Call for action vs. lost opportunity (Was: Re: Renumbering)) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >> Brian - is it provable that no design for a follow-on to IPv4 would >> have provided that backward compatibility? Or were there >> architectural and engineering decisions that chose other features >> over backward compatibility? > > > 1. Take the original, simple Deering specification. > > 2. Declare the initial IPv6 address space as being the current > IPv4 address space, with all upper bits zero. > > 3. The requirement for connecting a v6 stack to a v4 stack is a > very simple IP header-mapping translation, with no loss of information > at the IP level. > > 4. The v6 stack would need to have a v4 mode, for use by v4 > applications -- applications that use v4 addresses. Close. But that still wouldn't have let hosts with extended addresses (nonzero upper bits) converse with hosts that only had v4 capability, even assuming that "very simple IP header mapping translation" in the signal path. The upgraded hosts could have sent packets to the v4-only hosts but not vice versa. Of course, if we could have all agreed on an approach like that 15 years ago, and convinced stack vendors to add the stack extensions long before they were needed, AND somehow manage to get those extensions well tested, AND updated all of the APIs and applications to be able to use extended addresses, not to mention DNS, then we might have made our transition a lot easier. That's a big IF though. My experience is that seldom-used extensions don't tend to work very well. And if we had (at least initially) embedded IPng addresses inside IPv4 packets, by any of various means (IPAE had one approach, 6to4 another, and embedding the extended bits in an IPv4 option a third) and assumed that we would start out routing IPng packets over the IPv4 Internet, we could have avoided coupling (at least) several difficult problems: (a) upgrading the network to use larger addresses, (b) renumbering the network to improve routing scalability, (c) simplifying the packet format. (but it's at least conceivable that if IPng had been designed as an extension to IPv4, to be carried at least initially over IPv4 networks, then NATs would have evolved in such a way as to facilitate use of extended addresses between participating pairs of hosts. not that this would have been obvious circa 1992. ). As it turned out, the approach chosen coupled those three problems with at least two other problems: the one of having to upgrade apps, stacks, and DNS; and the problem of forcing apps to choose between multiple source and destination addresses. And finally there's the problem of marketing/mindshare - trying to get people to understand and accept the subtle differences between IPv4 and IPv6 instead of selling them an enhanced version of IPv4. By comparison, the notion of "extended addressing" was already familiar from the PC world. It might have been much easier to sell IPv4 with extended addresses than to sell the "new" IPv6. This is, I believe, a classic case of second-system effect. Trying to solve several problems at once significantly raises the difficulty of solving any of them, particularly when adoption of the solution requires parties with vastly different interests (like carrier ISPs, enterprise networks, OS developers, and application developers) to all buy into the solution within a narrow timeframe. By contrast, decoupling the solutions might have allowed a more incremental adoption of all of the ideas, or most of them. (renumbering for routing scalability might still have been a hard sell) Of course, the devil is in the details. And the delay in adopting IPv6 further compounded the difficulties, because networks have changed a lot since 15 years ago. NATs, firewalls, intrusion detection, interception proxies, were much rarer in the early 1990s. All of these are affected by IPv6, and all of these impose further barriers to adoption of IPv6. But there's no point in kicking ourselves about this now. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 21:11:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfPsI-0004CB-Li; Tue, 09 Oct 2007 20:56:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfPsH-0004C6-VR for ietf@ietf.org; Tue, 09 Oct 2007 20:56:33 -0400 Received: from wa-out-1112.google.com ([209.85.146.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfPsB-0002iG-MV for ietf@ietf.org; Tue, 09 Oct 2007 20:56:33 -0400 Received: by wa-out-1112.google.com with SMTP id k40so69521wah for ; Tue, 09 Oct 2007 17:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=3/uH8wk+YlDYlrsN0CA//lgGHEMw++kfdUyRNJuoJw8=; b=kdO2KvtA53dl9EP1qSgsX2tEeqCiuVBeziJq9vHYLXjimi/pHz2GtyA6Qm/kpABMI7oW0xsQFSc7lU0dQ1l2wi96Qb4fLtJO8C9IWKyMSpFY03u+mS3Bqnjt4l7e66SVeUyac+mmzCi5J+5+LBmFACiXajLVcTwcOBRp4mSut5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=OLxUjv7QKK5lgNfR7cS0Q/FiwEvIPEmd9A8uLDMbD0ZfkxwRv9eFcxLV67kSny01lK0ObK1CHNfoy3yh+tHuV7DtxuhGNWSMvZAn+R0lXHemksNVe4AEGoBOM0bhqp0J27L456XSGmNNyto4THyjkIpwjizZPzL1KcR4djAGMLs= Received: by 10.114.154.1 with SMTP id b1mr106078wae.1191977754945; Tue, 09 Oct 2007 17:55:54 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id j21sm265223wah.2007.10.09.17.55.50 (version=SSLv3 cipher=RC4-MD5); Tue, 09 Oct 2007 17:55:53 -0700 (PDT) Message-ID: <470C2314.5000303@gmail.com> Date: Wed, 10 Oct 2007 13:55:48 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Keith Moore References: <46EAE465.8070104@dcrocker.net> <4707ECB0.6020302@gmail.com> <26E67D75-E5A0-4142-AC29-7CB0C24FFBD0@cisco.com> <470BE18F.3070105@dcrocker.net> <470C1245.8000909@cs.utk.edu> In-Reply-To: <470C1245.8000909@cs.utk.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: dcrocker@bbiw.net, IETF-Discussion Subject: Re: perfect hindsight (was Re: Call for action vs. lost opportunity (Was: Re: Renumbering)) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-10 12:44, Keith Moore wrote: >>> Brian - is it provable that no design for a follow-on to IPv4 would >>> have provided that backward compatibility? Or were there >>> architectural and engineering decisions that chose other features >>> over backward compatibility? >> >> 1. Take the original, simple Deering specification. >> >> 2. Declare the initial IPv6 address space as being the current >> IPv4 address space, with all upper bits zero. >> >> 3. The requirement for connecting a v6 stack to a v4 stack is a >> very simple IP header-mapping translation, with no loss of information >> at the IP level. >> >> 4. The v6 stack would need to have a v4 mode, for use by v4 >> applications -- applications that use v4 addresses. > Close. But that still wouldn't have let hosts with extended addresses > (nonzero upper bits) converse with hosts that only had v4 capability, > even assuming that "very simple IP header mapping translation" in the > signal path. The upgraded hosts could have sent packets to the v4-only > hosts but not vice versa. Indeed. And that was the problem with my own proposal (aeiou) which was in some ways even simpler - it preserved the existing 32 bit address space and added a 32 bit address extension to be used within sites. Exactly the same issue as Keith points out applied, except that it was the nonzero _lower_ extension bits that would prevent 2-way communication with legacy hosts. Around about IETF 25 through 29, this class of ideas was thoroughly discussed. Brian > > Of course, if we could have all agreed on an approach like that 15 years > ago, and convinced stack vendors to add the stack extensions long before > they were needed, AND somehow manage to get those extensions well > tested, AND updated all of the APIs and applications to be able to use > extended addresses, not to mention DNS, then we might have made our > transition a lot easier. That's a big IF though. My experience is that > seldom-used extensions don't tend to work very well. > > And if we had (at least initially) embedded IPng addresses inside IPv4 > packets, by any of various means (IPAE had one approach, 6to4 another, > and embedding the extended bits in an IPv4 option a third) and assumed > that we would start out routing IPng packets over the IPv4 Internet, we > could have avoided coupling (at least) several difficult problems: (a) > upgrading the network to use larger addresses, (b) renumbering the > network to improve routing scalability, (c) simplifying the packet format. > > (but it's at least conceivable that if IPng had been designed as an > extension to IPv4, to be carried at least initially over IPv4 networks, > then NATs would have evolved in such a way as to facilitate use of > extended addresses between participating pairs of hosts. not that this > would have been obvious circa 1992. ). > > As it turned out, the approach chosen coupled those three problems with > at least two other problems: the one of having to upgrade apps, stacks, > and DNS; and the problem of forcing apps to choose between multiple > source and destination addresses. > > And finally there's the problem of marketing/mindshare - trying to get > people to understand and accept the subtle differences between IPv4 and > IPv6 instead of selling them an enhanced version of IPv4. By > comparison, the notion of "extended addressing" was already familiar > from the PC world. It might have been much easier to sell IPv4 with > extended addresses than to sell the "new" IPv6. > > This is, I believe, a classic case of second-system effect. Trying to > solve several problems at once significantly raises the difficulty of > solving any of them, particularly when adoption of the solution requires > parties with vastly different interests (like carrier ISPs, enterprise > networks, OS developers, and application developers) to all buy into the > solution within a narrow timeframe. By contrast, decoupling the > solutions might have allowed a more incremental adoption of all of the > ideas, or most of them. (renumbering for routing scalability might > still have been a hard sell) > > Of course, the devil is in the details. > > And the delay in adopting IPv6 further compounded the difficulties, > because networks have changed a lot since 15 years ago. NATs, > firewalls, intrusion detection, interception proxies, were much rarer in > the early 1990s. All of these are affected by IPv6, and all of these > impose further barriers to adoption of IPv6. > > But there's no point in kicking ourselves about this now. > > Keith > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 21:21:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfQ8S-0007u0-Gh; Tue, 09 Oct 2007 21:13:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfQ8R-0007qf-5L for ietf@ietf.org; Tue, 09 Oct 2007 21:13:15 -0400 Received: from wa-out-1112.google.com ([209.85.146.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfQ8L-0003Cg-VD for ietf@ietf.org; Tue, 09 Oct 2007 21:13:15 -0400 Received: by wa-out-1112.google.com with SMTP id k40so74366wah for ; Tue, 09 Oct 2007 18:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=UZ2Wuv+0WRErYjhMpmdU2El/tLC4+i41si7nYKj5SaU=; b=Oq1un6EPD88AdvtfcuOKkjRMWPOYHWb1et6bwLWXpjqnnfcm/rs/WjO8yvS331UQIEmsuMSXgohykkVS5G8YJ6TPlUuS5eyQh2XjgWgcLm6dNCHlJ7u4YCpN/8j81RYwiXVY4tdzL7vLct81NOULvpRMspfTIvAuLWx3Wa2D6yU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=iDZteOW4vLKKdewWtna3GNFUOVNqakIw7SaQivmss/jcVp5pj4VqBnwr0/keSbxzX8o5Ht45/QcbZc7MtmFJhhSZxGWbgjTffOjmCQEg8FDBTHImFSp/TeyZo0NTVvTMgckLLcq61njHMmjLGYkBgwXuytqymPH3wQ5iTbyfzYM= Received: by 10.114.154.1 with SMTP id b1mr150368wae.1191978779129; Tue, 09 Oct 2007 18:12:59 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id m5sm288604wag.2007.10.09.18.12.57 (version=SSLv3 cipher=RC4-MD5); Tue, 09 Oct 2007 18:12:58 -0700 (PDT) Message-ID: <470C2718.90806@gmail.com> Date: Wed, 10 Oct 2007 14:12:56 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stephen Sprunk References: <46EAE465.8070104@dcrocker.net> <4707ECB0.6020302@gmail.com><26E67D75-E5A0-4142-AC29-7CB0C24FFBD0@cisco.com><6804D47B-9765-496C-BF0A-F4B4C7BCC441@virtualized.org> <00ed01c80abc$64308550$423816ac@atlanta.polycom.com> In-Reply-To: <00ed01c80abc$64308550$423816ac@atlanta.polycom.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Tony Li , IETF-Discussion Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Stephen, > > Perhaps, if the folks hadn't been so dogmatically against NAT at the > time, the v4-to-v6 transition model would have worked similarly and we'd > be done with it by now... I doubt it. The underlying problem with NAT doesn't go away whatever you do. IMHO, there probably isn't any true solution that doesn't involve a mechanism for distributing address-to-address mappings in some shape or form, so that all parties have the same view of whatever address mapping applies to a given e2e traffic flow. (It doesn't matter for this argument whether you're using the address mapping to perform NAT, encapsulation, or SHIM6 type address-swapping.) If you try to design a better NAT-PT, I'm pretty sure it will involve signalling back to the IPv6 side that "your correspondent believes that your address is ::FFFF:192.0.2.3", or some such. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 22:16:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfQsJ-0004A6-10; Tue, 09 Oct 2007 22:00:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfQsH-0004A0-W7 for ietf@ietf.org; Tue, 09 Oct 2007 22:00:37 -0400 Received: from email.xpasc.com ([65.85.17.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfQsB-0004m5-LC for ietf@ietf.org; Tue, 09 Oct 2007 22:00:37 -0400 Received: from bslepgate.xpasc.com (localhost.localdomain [127.0.0.1]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id 92AF8100585 for ; Tue, 9 Oct 2007 19:00:17 -0700 (PDT) X-Propel-Return-Path: Received: from email.xpasc.com ([10.1.2.88]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 2.1.7.8167-src $Rev: 8148 $) id iz6Ur7aa20h0; Tue, 09 Oct 2007 19:00:17 -0700 Received: from xpasc.com (egate.xpasc.com [10.1.2.49]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id 413F9100091 for ; Tue, 9 Oct 2007 19:00:17 -0700 (PDT) Received: from egate.xpasc.com (egate.xpasc.com [10.1.2.49]) by xpasc.com (8.11.2/8.11.2) with ESMTP id l9A20F728349 for ; Tue, 9 Oct 2007 19:00:15 -0700 Date: Tue, 9 Oct 2007 19:00:15 -0700 (PDT) From: David Morris cc: ietf list In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Propel-ID: iz6Ur7aa20h0 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: Re: TMDA backscatter X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Tue, 9 Oct 2007, Douglas Otis wrote: > > On Oct 9, 2007, at 1:52 PM, Keith Moore wrote: > > > Returned message content in DSNs is often essential information for > > debugging of mail system problems. Blindly insisting that DSNs > > should not return subject message content is shortsighted. We have > > already crippled the mail system too much as the result of naive > > and shortsighted spam countermeasures. > > The recommendation was to conform to requirements of RFC3464, but > could have been a bit more explicit in what was meant by original > content. The concern is the abuse of DSNs as an indirect content > delivery mechanism. Including original content runs a much greater > risk that any DSN then becomes blocked or dropped. A more difficult > problem to solve occurs when no DSN is found after a message delivery > fails for some reason. Less is more in terms of what should be > included of original message content. > > Per recipient: > original-recipient-field > final-recipient-field > action-field "failed" / "delayed" / "delivered" / "relayed" / > "expanded" > status-field > remote-mta-field > diagnostic-code-field > last-attempt-date-field > final-log-id-field > will-retry-until-field > > Per message: > original-envelope-id-field > reporting-mta-field > dsn-gateway-field > received-from-mta-field > arrival-date-field > > Is this what you would like to see in a DSN? As an end user, this would be about useless ... at least w/o a much smarter client than I'm used to. Some DSNs take days to arrive. Figuring out what message got lost w/o some portion of the actual user oriented content is difficult at best. As an end user, I would prefer to get back exactly what I sent, content wise. Easier to figure out what went wrong and easier to resend. Also easier to recognized I didn't orginate the email. My spam filtering system does quite well eliminating backscatter while retaining valid DSNs so my feeling is we should focus on making backscatter detectable and not on crippling the system. Dave Morris _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 22:53:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfRZX-0000Aq-08; Tue, 09 Oct 2007 22:45:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfRZV-0000Ah-Su for ietf@ietf.org; Tue, 09 Oct 2007 22:45:17 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfRZV-0001TA-Gw for ietf@ietf.org; Tue, 09 Oct 2007 22:45:17 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id D74361EE2AF; Tue, 9 Oct 2007 22:45:16 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ja13X0k+zVr; Tue, 9 Oct 2007 22:45:14 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 915281EE291; Tue, 9 Oct 2007 22:45:13 -0400 (EDT) Message-ID: <470C3CB1.70001@cs.utk.edu> Date: Tue, 09 Oct 2007 22:45:05 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Douglas Otis References: <2788466ED3E31C418E9ACC5C316615570534E4@mou1wnexmb09.vcorp.ad.vrsn.com><6.2.5.6.2.20071004111028.031d08e0@resistor.net> <3D19D707-31B1-4753-8B33-2F9761A5451A@mail-abuse.org> <41DFA083-E582-4A09-9C6D-A73EB5E93BA0@mail-abuse.org> <470BEA13.7090107@cs.utk.edu> In-Reply-To: X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ietf list Subject: Re: TMDA backscatter X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Douglas Otis wrote: > > On Oct 9, 2007, at 1:52 PM, Keith Moore wrote: > >> Returned message content in DSNs is often essential information for >> debugging of mail system problems. Blindly insisting that DSNs >> should not return subject message content is shortsighted. We have >> already crippled the mail system too much as the result of naive and >> shortsighted spam countermeasures. > > The recommendation was to conform to requirements of RFC3464, but > could have been a bit more explicit in what was meant by original > content. The concern is the abuse of DSNs as an indirect content > delivery mechanism. Including original content runs a much greater > risk that any DSN then becomes blocked or dropped. A more difficult > problem to solve occurs when no DSN is found after a message delivery > fails for some reason. Less is more in terms of what should be > included of original message content. Probably the biggest architectural problem with Internet email is that errors are not reliably reported to either the sender of the subject message or the party that is able to fix the problem. DSNs didn't change that, they just attempted to encourage a more uniform reporting format. > [details deleted] > > Is this what you would like to see in a DSN? I'd like to see as much information as possible that has a bearing on why the message delivery failed. So if the error is "recipient not found" or some such, then it might be acceptable to include only the header of the subject message. But if the error has something to do with the content (like a media conversion error), then it's useful if that content is returned so that it becomes possible to analyze why the error occurred. Of course it does little good to return a DSN to someone whose mail address was forged by a spammer. But to solve that problem without impairing the reliability of mail delivery reporting, an MTA needs a reliable way of knowing whether a particular return-path is correct. (where "reliable" includes being reasonably immune to replay attacks) Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 09 23:00:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfRjN-0007RT-6b; Tue, 09 Oct 2007 22:55:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfRjM-0007RO-El for ietf@ietf.org; Tue, 09 Oct 2007 22:55:28 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfRjM-0001iY-7R for ietf@ietf.org; Tue, 09 Oct 2007 22:55:28 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id A8F531EE2C6; Tue, 9 Oct 2007 22:55:27 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzwdfEFJ2Q7N; Tue, 9 Oct 2007 22:55:25 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id B057D1EE2B0; Tue, 9 Oct 2007 22:55:20 -0400 (EDT) Message-ID: <470C3F10.2010101@cs.utk.edu> Date: Tue, 09 Oct 2007 22:55:12 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: David Morris References: In-Reply-To: X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ietf list Subject: Re: TMDA backscatter X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > > As an end user, this would be about useless ... at least w/o a much > smarter client than I'm used to. Well, of course, part of the intention behind creating a uniform DSN format was to facilitate smarter mail user agents. Your MUA should be able to intercept DSNs (and MDNs) that it receives and use that information to report the status of each message that you've sent - or at least, the ones for which you've received nondelivery reports. I could speculate about why we don't have such capability, but it would be just speculation. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 10 00:15:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfShH-0000GL-Uv; Tue, 09 Oct 2007 23:57:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfShG-0000Fu-CJ for ietf@ietf.org; Tue, 09 Oct 2007 23:57:22 -0400 Received: from mailout00.controlledmail.com ([72.81.252.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfSh8-0008DQ-7T for ietf@ietf.org; Tue, 09 Oct 2007 23:57:20 -0400 Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id E82395CC0FA for ; Wed, 10 Oct 2007 03:56:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1191988616; bh=QdbqNr3mv8sYOvfNpAaXaFb8KTyauZeuLwVWR65 RPRg=; h=Received:From:Organization:To:Subject:Date:User-Agent: References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-Disposition:Message-Id: X-AV-Checked; b=Yac1YL8Cxo+rGRNeRSB+y/xgRx/nKnsO34QQ+g0n71lobqEaR4 GbA0mbP9epqdtYpyH0U3W5/HaWE7w3Y6Hvp0/Jl/T7XaSoZwzQ5VlBcvL0fzcwcAczz 2r/ZE8AN4Ho2CzhSQu4z/1x26pL5ieZRjdnKCBNGpXGBfy1l83Htgw= Received: from [192.168.111.102] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by mailout00.controlledmail.com (Postfix) with ESMTP id D379C5CC0E9 for ; Wed, 10 Oct 2007 03:56:55 +0000 (UTC) From: Scott Kitterman Organization: Kitterman Technical Services To: ietf@ietf.org Date: Tue, 9 Oct 2007 23:56:52 -0400 User-Agent: KMail/1.9.5 References: <2788466ED3E31C418E9ACC5C316615570534E4@mou1wnexmb09.vcorp.ad.vrsn.com> <470C3CB1.70001@cs.utk.edu> In-Reply-To: <470C3CB1.70001@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710092356.53785.scott@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: Re: TMDA backscatter X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Tuesday 09 October 2007 22:45, Keith Moore wrote: > Of course it does little good to return a DSN to someone whose mail > address was forged by a spammer. But to solve that problem without > impairing the reliability of mail delivery reporting, an MTA needs a > reliable way of knowing whether a particular return-path is correct. > (where "reliable" includes being reasonably immune to replay attacks) I'm curious how you would propose to do this? Scott K _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 10 03:39:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfVnh-0001jx-S0; Wed, 10 Oct 2007 03:16:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfVng-0001Y1-1z for ietf@ietf.org; Wed, 10 Oct 2007 03:16:12 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfVnV-0005Ub-Lu for ietf@ietf.org; Wed, 10 Oct 2007 03:16:08 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IfVmw-0006pt-US for ietf@ietf.org; Wed, 10 Oct 2007 07:15:26 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Oct 2007 07:15:26 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Oct 2007 07:15:26 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: "Frank Ellermann" Date: Wed, 10 Oct 2007 09:12:50 +0200 Lines: 64 Message-ID: References: <2788466ED3E31C418E9ACC5C316615570534E4@mou1wnexmb09.vcorp.ad.vrsn.com><6.2.5.6.2.20071004111028.031d08e0@resistor.net><3D19D707-31B1-4753-8B33-2F9761A5451A@mail-abuse.org> <41DFA083-E582-4A09-9C6D-A73EB5E93BA0@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: Re: TMDA backscatter X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Douglas Otis wrote: =20 > Due to the macro nature of SPF, full processing is required for > each name evaluated. If what you call "full processing" is the procedure to fetch the policy record of the domain in question, and match the connecting IP against this policy for a PASS / FAIL / "DUNNO" verdict, then=20 this doesn't depend on using macros or not in the policy. =20 Maybe you mean that macros can reduce the chances for a DNS cache hit, e.g. for per-user-policies based on the local part macro. > With SPF, the recipient might be interested in the PRA, or MAIL > FROM. When I talk about SPF it's generally RFC 4408, i.e. MAIL FROM and HELO, not the Sender-ID PRA. The PRA doesn't necessarily help to identify a permitted or forged MAIL FROM. In other words the PRA or FWIW DKIM are not designed to avoid backscatter. =20 > when an SPF hammer is the only tool Folks didn't like the idea to reintroduce RFC 821 return routes ;-) Of course receivers are free to use any tool to avoid backscatter, but SPF is today the only tool designed for this job. > Cleaning up how DSNs are constructed would be _far_ more effective > than asking that all DSNs be dropped when SPF does not produce a > PASS. No. When I was the victim (back in 2004 before SPF started to work) the _size_ of DSNs and other backscatter wasn't the main issue, the=20 _number_ of bogus auto replies was the real problem. =20 JFTR, "not PASS" can be FAIL or "DUNNO". FAILs should be rejected. Your idea to abuse DSNs for indirect spam or malware delivery is a valid consideration, but in practice the volume of all backscatter not limited to DSNs is the real problem. =20 Limiting the size of DSNs is okay, but it's not "far more effective" than "reject a.s.a.p.", in fact it misses the point wrt backscatter. > Perhaps that is why Bell Canada ensures all addresses achieve > a PASS. : ( Oops, bell.ca still has this ridiculous policy, that certainly won't help them to reduce backscatter. >> Auto responders aren't in a good position to verify the validity >> of the return path. Good positions to do this are the MSA based >> on RFC 4409 and later the MX based on RFC 4408. =20 > RFC4408 did not mitigate a potential DDoS exploit. This exploit =20 > exists when recipients attempt to process SPF as specified. Actually they've to ignore a SHOULD in the security considerations of RFC 4408 if they wish to participate in your convoluted attack scenario. And the SPF RFC did mitigate this potential with several MUSTs in the security considerations in comparison with pre-MARID drafts. Frank _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 10 09:48:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifbei-0001cI-Lo; Wed, 10 Oct 2007 09:31:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifbeh-0001bk-3U for ietf@ietf.org; Wed, 10 Oct 2007 09:31:19 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifbeg-0003w4-ON for ietf@ietf.org; Wed, 10 Oct 2007 09:31:19 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l9ADVIWF028469 for ; Wed, 10 Oct 2007 09:31:18 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9ADV8vw330884 for ; Wed, 10 Oct 2007 07:31:09 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l9ADV7ia027636 for ; Wed, 10 Oct 2007 07:31:08 -0600 Received: from localhost.localdomain (wecm-9-67-191-97.wecm.ibm.com [9.67.191.97]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l9ADV5Vc027280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Oct 2007 07:31:06 -0600 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.1/8.12.5) with ESMTP id l9ADV4ph013995; Wed, 10 Oct 2007 09:31:04 -0400 Message-Id: <200710101331.l9ADV4ph013995@localhost.localdomain> To: dcrocker@bbiw.net In-reply-to: <470BE18F.3070105@dcrocker.net> References: <46EAE465.8070104@dcrocker.net> <4707ECB0.6020302@gmail.com> <26E67D75-E5A0-4142-AC29-7CB0C24FFBD0@cisco.com> <470BE18F.3070105@dcrocker.net> Comments: In-reply-to Dave Crocker message dated "Tue, 09 Oct 2007 16:16:15 -0400." Date: Wed, 10 Oct 2007 09:31:04 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: IETF-Discussion Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Dave Crocker writes: > 4. The v6 stack would need to have a v4 mode, for use by v4 > applications -- applications that use v4 addresses. Um, sounds an awful lot like dual-stack to me. Hosts (that understand IPv6) also must be able to originate and receive either IPv4 packets or the bigger IPv6 ones. Sure, the details may be somewhat different, but fundamentally, we have dual stack, with IPv6 nodes needing to support IPv4 for backwards compatability. And in the network, routers have to understand both the original IPv4 format, plus the new IPv6 format. If there was a magic "trivial" transition/upgrade strategy, we would have done it years ago. Really. Thomas _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 10 10:05:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifc5V-00055k-6R; Wed, 10 Oct 2007 09:59:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifc5T-000557-9t; Wed, 10 Oct 2007 09:58:59 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifc5T-0005H4-1J; Wed, 10 Oct 2007 09:58:59 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9E45548C4; Wed, 10 Oct 2007 09:58:58 -0400 (EDT) From: Sam Hartman To: Eliot Lear References: <20071008014006.88BB233C21@delta.rtfm.com> <4709D647.7070004@piuha.net> <20071008125725.3B71233C57@delta.rtfm.com> <470A30CC.2030603@cisco.com> Date: Wed, 10 Oct 2007 09:58:58 -0400 In-Reply-To: <470A30CC.2030603@cisco.com> (Eliot Lear's message of "Mon, 08 Oct 2007 15:29:48 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: iesg@ietf.org, Jari Arkko , ietf@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>>>> "Eliot" == Eliot Lear writes: Eliot> If I understand the purpose of this experiment it would be Eliot> to provide ADs some indication of level of interest and Eliot> ability to succeed. Hmm. As I read the document, level of interest is explicitly out of scope for the experiment. That needs to be determined first. Who is confused, you or I? Does the document need to be updated to be more clear? _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 10 10:05:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifc2i-000126-I4; Wed, 10 Oct 2007 09:56:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifc2f-0000xA-VX; Wed, 10 Oct 2007 09:56:06 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifc2d-0004jv-Fd; Wed, 10 Oct 2007 09:56:03 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E1ABD48C4; Wed, 10 Oct 2007 09:56:02 -0400 (EDT) From: Sam Hartman To: Eric Rescorla References: <20071008014006.88BB233C21@delta.rtfm.com> Date: Wed, 10 Oct 2007 09:56:02 -0400 In-Reply-To: <20071008014006.88BB233C21@delta.rtfm.com> (Eric Rescorla's message of "Sun, 07 Oct 2007 18:40:05 -0700") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: iesg@ietf.org, ietf@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>>>> "Eric" == Eric Rescorla writes: Eric> I think there's a more meta-issue here: do we think it would Eric> be good for the IETF to have more WGs? If the answer is Eric> "yes, then it makes sense to foster new work in various Eric> ways. If the answer is "no" then it makes sense to treat Eric> getting an effort ready for WG formation as a proxy for the Eric> level of readiness of that effort. My general feeling is Eric> that the answer is "no." In some areas, such as RAI, every Eric> slot is filled and there are sometimes double bookings. Eric> Even in other areas, conflicts are a serious problem and Eric> documents that everyone agrees are important languish for Eric> lack of attention. So, I'm not sure why a change that's Eric> designed to make WG formation easier is a good thing--nor Eric> that experimenting with such a change is. Speaking as an individual, I think the answer to this question is a lot closer to yes than to no. The answer is definitely closer to yes if an effort is likely to bring in a number of participants who do not normally participate in the IETF. Eric> A related issue is that this puts pressure on ADs to approve Eric> SGs for efforts that they would ordinarily simply refuse WGs Eric> for. I.e., "OK, so you won't give us a WG, how about a Eric> SG". Currently this document simply has it at the IESG's Eric> discretion: I think that Ad can manage this risk. ADs tend to get reasonably good at saying no. Eric> Arguably, SG formation should Eric> be subject to an IETF LC in the same way that WG formation Eric> is. It's my understanding of the document that SG formation is subject to ietf-wide review. I'm not sure that the IETF review in RFC 2418 nor the same IETF review for SG formation is quite the same as an IETF LC, but I do think the same IETF and IAB involvement is anticipated in the SG process. The IAB is not involved in proposing SG formation initially, although they are involved in reviewing whether that is a good idea before it goes out to the wider IETF community. I have no thoughts on the rest of your comments at this time. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 10 10:25:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfcMy-0006rV-FP; Wed, 10 Oct 2007 10:17:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfcMw-0006or-TB for ietf@ietf.org; Wed, 10 Oct 2007 10:17:02 -0400 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfcMw-00067s-7T for ietf@ietf.org; Wed, 10 Oct 2007 10:17:02 -0400 Received: from [192.168.169.243] (72-255-65-82.client.stsn.net [72.255.65.82]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l9AEGcai028646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Oct 2007 07:16:41 -0700 Message-ID: <470CDEF4.5030805@bbiw.net> Date: Wed, 10 Oct 2007 10:17:24 -0400 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten References: <46EAE465.8070104@dcrocker.net> <4707ECB0.6020302@gmail.com> <26E67D75-E5A0-4142-AC29-7CB0C24FFBD0@cisco.com> <470BE18F.3070105@dcrocker.net> <200710101331.l9ADV4ph013995@localhost.localdomain> In-Reply-To: <200710101331.l9ADV4ph013995@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: IETF-Discussion Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Thomas Narten wrote: > Dave Crocker writes: > >> 4. The v6 stack would need to have a v4 mode, for use by v4 >> applications -- applications that use v4 addresses. > > Um, sounds an awful lot like dual-stack to me. Hosts (that understand It's not. No more than having your TCP use selective acks constitutes a 'dual stack', relative to having TCP not use selective acks. While what I suggested isn't that "minor" an enhancement to the stack, neither does it constitute an entirely separate stack. To repeat: Dual stack is entirely separate. That's the approach that was chosen. IPv6 is an incompatible protocol module, compared with IPv4. Independent addressing. Independent interfacing. Independent management. What I described was a compatible upgrade. Very different beast. Yes, it is not perfectly compatible. The only way to achieve that is to have purely syntactic differences. Oh. Wait a minute. hat I described -- as a first step for adoption -- would have been a purely syntactic difference, albeit one that set the basis for fixing the only problem that IPv6 was originally asked to solve: bigger address space. Exploiting that basis would have been moved to a strictly administrative step. Prior to exploiting it, interoperability between IPv4 and IPv6 could have been perfect and easy. But it would have had the feature of being adopted as no more than a software upgrade (and availability of syntax-translating routers.) > IPv6) also must be able to originate and receive either IPv4 packets > or the bigger IPv6 ones. Sure, the details may be somewhat different, > but fundamentally, we have dual stack, with IPv6 nodes needing to > support IPv4 for backwards compatability. And what I described was an approach that would have permitted a "pure" IPv6 host, where interaction with an IPv4 host required a syntax-translating relay of some sort. This approach does not prohibit having a host implement both formats, but what is fundamental is that it does not require it. This is in marked contrast with what we have now, needing a much hairier different translating relay, independent address administration and, really, independent operations and management. V6 is an independent network from V4. > And in the network, routers have to understand both the original IPv4 > format, plus the new IPv6 format. Yes, anything looking at a format must understand it. If IPv4 traffic is mixed with IPv6 traffic, then yes the routers need to understand both. The difference in what I described is that networks that do only one of the formats would nonetheless be part of a unified global service. What we instead have is that we have two separate services. Separate addressing, separate management. Very much larger barrier to adoption. (For reference, I am being so painfully redundant in making my points, here, because it seems to be necessary.) > If there was a magic "trivial" transition/upgrade strategy, we would > have done it years ago. You must have been participating in different discussions than I was. If one looks at the style of discussion now, what we see is an effort to dismiss criticisms and alternatives, rather than counter them seriously. This is what took place back then, too. Timely deadlines were dismissed. Simplicity was dismissed. Integration was dismissed. The ones that I was around suffered from a classic second-system syndrome of a) lack of pressure to delivery a timely solution, b) feature creep, c) lack of concern for interoperability. Brian's reference to a history that discussed this, and other, alternatives entirely ignores the differences between "discussing" and "taking seriously". That is, what he does not do is explain why a simpler approach was rejected. One would think that a 15-year project that was pursued to solve a fundamental Internet limitation but has achieved such poor adoption and use would motivate some worrying about having made some poor decisions. A quick response that says "we talked about that" but says no more seems a little bit facile. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 10 10:25:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfcT9-00041s-Nz; Wed, 10 Oct 2007 10:23:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfcT7-0003ws-L3; Wed, 10 Oct 2007 10:23:25 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfcT2-0003Pl-GQ; Wed, 10 Oct 2007 10:23:25 -0400 Received: from [192.168.1.3] (pool-72-76-39-171.nwrknj.fios.verizon.net [72.76.39.171]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9AEMxj9006313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Oct 2007 07:23:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 10 Oct 2007 10:22:53 -0400 To: , , IPsec WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: kent@bbn.com, mlepinski@bbn.com Subject: Re: Last call comments for draft-lepinski-dh-groups-01 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 1:32 PM +0300 10/9/07, wrote: >1) Section 1 says: > > "Sixteen additional groups subsequently have been defined and > assigned values by IANA for use with IKE (v1 and v2). All of > these additional groups are optional in the IKE context. Of > the twenty-one groups defined so far, eight are MODP groups > (exponentiation groups modulo a prime), ten are EC2N groups > (elliptic curve groups over GF[2^N]) and three are ECP groups > (elliptic curve groups over GF[P]). > >This is not totally correct. As of this writing, no EC2N groups >have been assigned values for use with IKEv2. Also, eight of the >ten EC2N groups for IKEv1 are not documented in any RFC. (And yes, >I'm aware of draft-ietf-ipsec-ike-ecc-groups -- but that hasn't >been approved yet, and requires changes before approval.) draft-lepinski-dh-groups needs to track draft-ietf-ipsec-ike-ecc-groups very carefully. If there is any mis-match, we will have interoperability problems in the future. >2) For IKEv1/IKEv2, the document should explicitly specify how >ECC points are converted to octet strings (for KE payloads >and resulting shared secret value). Currently, there are at >least three incompatible options (RFC 4753, RFC 2409, and >draft-ietf-ipsec-ike-ecc-groups-10 drafts). I'd suggest just >saying "the same way as in RFC 4753". This bodes really poorly for interoperability. draft-lepinski-dh-groups needs to be revised to specify one of the methods, and that needs to be discussed on the IPsec mailing list. I would not assume that implementers would prefer RFC 4753 over draft-ietf-ipsec-ike-ecc-groups. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 10 11:38:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfdVp-0007Ll-Pq; Wed, 10 Oct 2007 11:30:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfdVo-0007LE-0Z for ietf@ietf.org; Wed, 10 Oct 2007 11:30:16 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfdVn-0008EU-6J for ietf@ietf.org; Wed, 10 Oct 2007 11:30:15 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 6A7241EE2CC; Wed, 10 Oct 2007 11:30:14 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmqzuyrjp+Wt; Wed, 10 Oct 2007 11:30:12 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 4DC7E1EE26F; Wed, 10 Oct 2007 11:30:09 -0400 (EDT) Message-ID: <470CF000.4060504@cs.utk.edu> Date: Wed, 10 Oct 2007 11:30:08 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Dave Crocker References: <46EAE465.8070104@dcrocker.net> <4707ECB0.6020302@gmail.com> <26E67D75-E5A0-4142-AC29-7CB0C24FFBD0@cisco.com> <470BE18F.3070105@dcrocker.net> <200710101331.l9ADV4ph013995@localhost.localdomain> <470CDEF4.5030805@bbiw.net> In-Reply-To: <470CDEF4.5030805@bbiw.net> X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: Thomas Narten , IETF-Discussion Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > To repeat: Dual stack is entirely separate. > > That's the approach that was chosen. IPv6 is an incompatible protocol > module, compared with IPv4. Independent addressing. Independent > interfacing. Independent management. > > What I described was a compatible upgrade. Very different beast. > > Yes, it is not perfectly compatible. The only way to achieve that is > to have purely syntactic differences. > > Oh. Wait a minute. hat I described -- as a first step for adoption > -- would have been a purely syntactic difference, albeit one that set > the basis for fixing the only problem that IPv6 was originally asked > to solve: bigger address space. > > Exploiting that basis would have been moved to a strictly > administrative step. Prior to exploiting it, interoperability between > IPv4 and IPv6 could have been perfect and easy. > > But it would have had the feature of being adopted as no more than a > software upgrade (and availability of syntax-translating routers.) You make it sound like a trivial step, but it's not. That "no more than a software upgrade" is fairly equivalent to the effort required to upgrade IPv4 software to IPv6 today (different APIs, different DNS records, updated apps, and difficulties for p2p apps) and I'll note that after 15 years that effort is still not complete (especially for software that isn't bundled with operating systems). And "the availability of syntax-translating routers" can't necessarily be assumed either, particularly not if there would have been a need to draw firm borders between legacy IPv4 and enhanced IPv4 enclaves. (though perhaps NATs would have evolved in that direction). >> IPv6) also must be able to originate and receive either IPv4 packets >> or the bigger IPv6 ones. Sure, the details may be somewhat different, >> but fundamentally, we have dual stack, with IPv6 nodes needing to >> support IPv4 for backwards compatability. > > And what I described was an approach that would have permitted a > "pure" IPv6 host, where interaction with an IPv4 host required a > syntax-translating relay of some sort. As you probably remember, the "syntax-translating relay" approach at the boundary of different mail enclaves (ASCII-only vs. 8-bit transparent, ASCII headers vs. UTF-8 headers) has been discussed several times and generally rejected in favor of per-message negotiation, mostly because of that difficulty of drawing a clean boundary between enclaves (and also the difficulty of having flag days during which an entire enclave upgrades). Offhand I'm not sure why IP networks would find this kind of operation any easier. > This approach does not prohibit having a host implement both formats, > but what is fundamental is that it does not require it. This is in > marked contrast with what we have now, needing a much hairier > different translating relay, independent address administration and, > really, independent operations and management. V6 is an independent > network from V4. Independent address administration, and treating v6 as a separate network from v4, do impose a barrier to adoption. I understand why IPv6 didn't go this way. But I also wonder if the costs of having IPv6 be completely separate were as well-understood as the advantages. I think too many people assumed that everyone would independently adopt IPv6 in the absence of any immediate advantage to doing so, and also that the barriers to "adopting IPv6" looked far simpler in the mid-1990s than they are today. >> And in the network, routers have to understand both the original IPv4 >> format, plus the new IPv6 format. > > Yes, anything looking at a format must understand it. If IPv4 traffic > is mixed with IPv6 traffic, then yes the routers need to understand both. > > The difference in what I described is that networks that do only one > of the formats would nonetheless be part of a unified global service. not clear. for instance, would enhanced IPv4 hosts universally be able to reach one another? or would the absence of translating relays in some cases make their connectivity spotty? > (For reference, I am being so painfully redundant in making my points, > here, because it seems to be necessary.) The problem might not be that people don't understand what you are saying, but that people don't so readily accept that the alternative would have been as simple and easy as you seem to think. >> If there was a magic "trivial" transition/upgrade strategy, we would >> have done it years ago. > > You must have been participating in different discussions than I was. > If one looks at the style of discussion now, what we see is an effort > to dismiss criticisms and alternatives, rather than counter them > seriously. People may differ on what constitutes a dismissal versus a serious counterargument. > This is what took place back then, too. Timely deadlines were > dismissed. Simplicity was dismissed. Integration was dismissed. That's a bit of an over-simplification. Simplicity was highly valued - that's why the IPv6 packet format ended up being simpler than IPv4, and part of why the idea of incorporating IPv4 address space into IPv6 was rejected. Integration wasn't dismissed out-of-hand; instead, a number of proposals were considered at length. Sure the effort ran long, but so does everything else that IETF does. It was obvious that IPng was going to require changes to host stacks, apps, DNS, and routers no matter which proposal was chosen. The dual-stack alternative looked attractive because it carried with it the notion that someday the IPv4 stack could be dropped. (People don't like the idea of old cruft hanging around forever. The most frequent complaint I hear about RFC 2047 is not that it works poorly or that the things leak but that it's ugly and it's hard to get rid of.) I think that in hindsight there was too much emphasis on producing a desirable end-state and too little emphasis on producing an attractive transition path. And I think the transition model that most people assumed was, well, naive. But in the early 1990s, before Windows even had an IP stack, when the net was much smaller and had a higher clue density, when the web was just a small-scale experiment that didn't even have the IMG tag yet (and therefore much less glitz potential), it was possible to imagine that the small, generally clueful net would see the necessity of moving to IPv6 and do it fairly quickly. By the late 1990s when IPv6 was thought to be finished, the net was too big to make that kind of transition in a short time. > The ones that I was around suffered from a classic second-system > syndrome of a) lack of pressure to delivery a timely solution, b) > feature creep, c) lack of concern for interoperability. We certainly agree that IPv6 suffered from second-system effect. > One would think that a 15-year project that was pursued to solve a > fundamental Internet limitation but has achieved such poor adoption > and use would motivate some worrying about having made some poor > decisions. A quick response that says "we talked about that" but says > no more seems a little bit facile. Looking back to try to abstract lessons seems worthwhile, though it makes no more sense to dismiss the choices that were made as obviously wrong than to dismiss the alternatives you are suggesting as obviously wrong. To the extent IPv6 could have been different in such a way as to make it more successful, the differences are subtle and the effects even moreso. As for worrying, I see little value in that now. And as for quick responses, that's the nature of anything discussed on the IETF list, or pretty much any mailing list that I've seen. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 10 13:33:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iff7p-0003Hk-8Y; Wed, 10 Oct 2007 13:13:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iff7n-0003Gp-QX for ietf@ietf.org; Wed, 10 Oct 2007 13:13:35 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iff7f-0000v3-Ia for ietf@ietf.org; Wed, 10 Oct 2007 13:13:33 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BF83548C4; Wed, 10 Oct 2007 13:13:11 -0400 (EDT) From: Sam Hartman To: ietf@ietf.org Date: Wed, 10 Oct 2007 13:13:11 -0400 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: Last Call results: draft-carpenter-rescind-3683-03.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Approximately a year ago, on October 20, 2006, draft-carpenter-rescind-3683 entered its second last call. Today, I bring you the results of that last call. Before I start, I want to make it clear that I do generally get back to documents in time periods much shorter than a year. Had I believed there was consensus to publish, I would have made this a much higher priority. However as it was, there were a lot of messages to go through, I had a lot more important things to do than go through the messages in detail and the general outcome was clear both to me and the draft author. However I have taken the time to go through all the last call comments and to get the issues fresh in my mind. I hope now to close out this draft. There is not consensus to publish the draft in its current form; thanks David for bringing up your concern leading to the second last call. I think there is rough consensus against publishing a draft containing text similar to section 3 of this draft. In other words, the community wants RFC 3683 to remain an option. However there are several areas where we may be able to achieve consensus to do something. Interested participants should consider writing drafts in these areas: 1) Several people expressed support for undoing the effects of RFC 3934 that limit suspensions previously allowed by RFC 2418. Brian believes that section 2 of this draft accomplishes that. Others are less sure. It may be that we could achieve rough consensus behind section 2. It seems like there may be even more support for text that simply clarified that RFC 3934 did not limit RFC 2418 but that did not itself amend RFC 2418. 2) There was general discussion about whether the IESG had an appropriate range of tools. It may be that creating new options with severity less than RFC 3683 but greater than a 30 day suspension is useful. For example would it be appropriate for the IESG to limit a PR-action to a specific set of lists? Etc? Are there other tools that the IESG needs? Any additional work in this area would require a new draft. If that draft were to be approved it would need to start the publication process at the beginning by finding a sponsoring AD. Brian, thanks for all your work on this issue. While we did not end up approving your draft, I think the discussion was informative and useful. Sam Hartman Area Director _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 10 15:14:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfgqY-0003VD-OS; Wed, 10 Oct 2007 15:03:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfgqX-0003Mx-Cb for ietf@ietf.org; Wed, 10 Oct 2007 15:03:53 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfgqP-0007Bd-4f for ietf@ietf.org; Wed, 10 Oct 2007 15:03:45 -0400 Received: from c-71-197-208-131.hsd1.or.comcast.net ([71.197.208.131] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1IfgqO-000DdN-7I for ietf@ietf.org; Wed, 10 Oct 2007 15:03:44 -0400 Received: by internaut.com (Postfix, from userid 1000) id 7A100822F2; Wed, 10 Oct 2007 12:03:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 6F8F782272 for ; Wed, 10 Oct 2007 12:03:43 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.197.208.131 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19MzWITyXr4if6xbzt1Ktar Date: Wed, 10 Oct 2007 12:03:43 -0700 (PDT) From: Bernard Aboba To: ietf@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Subject: Re: Comments on draft-aboba-sg-experiment-03.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Sam Hartman said: "It's my understanding of the document that SG formation is subject to ietf-wide review. I'm not sure that the IETF review in RFC 2418 nor the same IETF review for SG formation is quite the same as an IETF LC, but I do think the same IETF and IAB involvement is anticipated in the SG process. The IAB is not involved in proposing SG formation initially, although they are involved in reviewing whether that is a good idea before it goes out to the wider IETF community." That is my understanding as well. To make it more clear, I would propose mentioning IAB review explicitl in Section 3, which is now proposed to read as follows: 3. The Experiment This experiment runs for a period of 18 months from IESG approval of the experiment. During the period of the experiment, the IESG MAY approve formation of as many as three Study Groups. The IESG MUST inform the community in a public statement of any decisions for Study Group formation approved under this experiment. Such a statement SHOULD include a description of specific Study Group that was formed. Given that this is an experiment, the intent is for Study Groups to be handled identically to Working Groups in terms of IETF process, tools and infrastructure; no additional burden is to be imposed on the IETF Secretariat. Other than the abbreviated charter, the process for formation of a Study Group is identical to that of a Working Group, including review by the IAB and IESG, announcement of the potential Study Group, and request for review by the IETF community. The operating rules of a Study Group (openness, meeting requirements, etc.) are identical to Working Groups. From the point of view of IETF infrastructure (tools, membership in the WGCHAIRS mailing list, process rules, Charter pages, etc.) Study Groups are treated identically to Working Groups, with the exception that Study Group names should include "SG" within the name (e.g. "EXAMPLESG"), so as to clearly differentiate them from Working Groups. Review of Study Group documents will utilize the same tracking tools and processes (including PROTO sheparding) as other IETF documents; this allows feedback to be viewed by Study Group Chairs and participants, as well as providing additional clarity on next steps. Formation of a Study Group requires the appointment of a Study Group Chair, and a well defined set of Working Group formation criteria (agreement on the Charter, review of the formation criteria, problem statement or requirements document, etc. ) Eric Rescorla said: "A related issue is that this puts pressure on ADs to approve SGs for efforts that they would ordinarily simply refuse WGs for. I.e., "OK, so you won't give us a WG, how about a SG". Currently this document simply has it at the IESG's discretion" In order to address the potential for SGs dragging on, I have added a default lifetime (6 months), as well as some guidance on SG formation to Section 2, which is proposed to read as follows: "2. Study Group Formation If at any point during the Working Group formation process, including after a first or second BoF session, relevance to the Internet community and interest within the IETF and end-user community has been demonstrated, but one or more Working Group formation criteria outlined in RFC 2418 [RFC2418] Section 2.1 has not yet been met, the IESG MAY propose that a Study Group be formed. Since the goal of a Study Group is to put in place the prerequisites for formation of a Working Group more rapidly than might otherwise be possible, Study Groups SHOULD initially be chartered for a period of six months to twelve months, with six months being the default. While the IESG MAY extend the initial Study Group milestones by an additional six months, extensions beyond this are NOT RECOMMENDED. The Charter for a Study Group SHOULD include at least the following "basic milestones": o Development of a Working Group Charter. o Development of a document demonstrating fulfillment of the Working Group formation criteria described in RFC 2418 [RFC2418] Section 2.1. The IESG MAY also include additional milestones within a Study Group charter (such as development of a problem statement or requirements document and/or completion of a review of the literature or current practices), as long as these additional milestones do not compromise the ability of the Study Group to deliver on the basic milestones in a timely way. A Study Group charter MUST NOT include milestones relating to development of standards track documents or protocol specifications. Since the Study Group experiment is not intended as a substitute for the existing Working Group formation process, Study Groups SHOULD be formed only in situations where the prerequisites for formation of a WG are likely to be met if the SG successfully completes the basic milestones." With respect to success metrics, I would propose to add the following Section 3.1: "3.1. Success Metrics Since one of the goals of this experiment is to enable the more rapid formation of Working Groups, the success of an individual Study Group, as well as the experiment, can be measured based on the progress made toward Working Group formation. Useful metrics include: Progress on Basic Milestones A Study Group that does not make progress on its basic milestones cannot be judged successful, regardless of its other achievements, such as progress on a literature review or requirements document. Progress on the basic milestones is measured by whether they are completed within the time-frame specified in the initial Study Group Charter, and whether feedback from the IESG, IAB and IETF community is positive, leading the IESG to vote to form a Working Group. Mailing List Activity Since one of the goals of the Study Group experiment is to avoid a potential loss of interest among participants, evidence of continued engagement on the part of Study Group participants based on mailing list activity is a potential success metric. Conversely, a Study Group whose mailing list shows minimal traffic would probably not be a good candidate for milestone extension." The complete text of the strawman -03 document is available here: http://www.drizzle.com/~aboba/IAB/draft-aboba-sg-experiemnt-03.txt _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 10 15:51:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfhP8-0000YE-86; Wed, 10 Oct 2007 15:39:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfhP5-0000Td-SD; Wed, 10 Oct 2007 15:39:35 -0400 Received: from open.nlnetlabs.nl ([213.154.224.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfhP5-0008CA-A5; Wed, 10 Oct 2007 15:39:35 -0400 Received: from [127.0.0.1] (open.nlnetlabs.nl [213.154.224.1]) by open.nlnetlabs.nl (8.14.1/8.14.1) with ESMTP id l9AJYCA4034247; Wed, 10 Oct 2007 21:34:12 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <5FCD348C-5927-4F18-A002-0E3BF21ED5F4@NLnetLabs.nl> From: "Olaf M. Kolkman" Date: Wed, 10 Oct 2007 21:34:10 +0200 To: The Internet Engineering Steering Group X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [213.154.224.1]); Wed, 10 Oct 2007 21:34:12 +0200 (CEST) X-Spam-Status: No, score=-104.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on open.nlnetlabs.nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: IAB IAB , IETF@ietf.org Subject: Follow-up work on NAT-PT X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1807812316==" Errors-To: ietf-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1807812316== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-54--1010714171" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-54--1010714171 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear Colleagues, The IETF has previously standardized NAT-PT as a means of intercommunication by packet translation at the Internet layer. However subsequent analysis revealed a number of issues with NAT-PT that make it a poor choice for a general purpose interconnection mechanism. The IESG recently approved RFC 4966 which states: Although the [RFC2766] form of packet translation is not generally applicable, it is likely that in some circumstances a node that can only support IPv4 will need to communicate with a node that can only support IPv6; this needs a translation mechanism of some kind. Although this may be better carried out by an application-level proxy or transport-layer translator, there may still be scenarios in which a revised, possibly restricted version of NAT-PT can be a suitable solution; accordingly, this document recommends that the IETF should reclassify RFC 2766 from Proposed Standard to Historic status to avoid it from being used in inappropriate scenarios while any replacement is developed. As noted in the approved text quoted above, there may still be scenarios in which a revised, possibly restricted version of NAT-PT may be appropriate. For example, one such scenario may be increasingly likely given the current rate of consumption of IPv4 address space. Namely, there may be legacy IPv4-only hosts in one part of the Internet that want to talk to dual-stack hosts in another part of the Internet that do not have public IPv4 addresses. The servers follow today's recommendation to be dual-stack, but the scenario still does not work, therefore the general recommendation that servers be dual-stack is clearly not sufficient. Furthermore, classic v4-v4 NAT is also not sufficient for this scenario. For example, one cannot put multiple web servers behind the same classic v4-v4 NAT since web browsing uses port 80, and the NAT has fewer public IP addresses than the number of servers behind it or else the NAT wouldn't be needed. While the IETF has reclassified RFC 2766 as Historic, up to now there has been no replacement to RFC 2766 for such scenarios. The IAB note that the IESG has now begun discussion on what work is needed for transitioning to IPv6 and where it should be done, and the IAB encourages the IESG to strongly consider the scenario outlined above when chartering IETF work. -- The IAB --Apple-Mail-54--1010714171 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: This message is locally signed. iD8DBQFHDSkytN/ca3YJIocRAtfpAJ9UUQCxZsVUlZAFfOuBZnNgAAzQcgCfdw78 Frxy/yLL/MIgTBzT9onoqG8= =X61x -----END PGP SIGNATURE----- --Apple-Mail-54--1010714171-- --===============1807812316== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============1807812316==-- From ietf-bounces@ietf.org Wed Oct 10 16:58:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfiRX-0002uo-27; Wed, 10 Oct 2007 16:46:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfiRV-0002uD-PX for ietf@ietf.org; Wed, 10 Oct 2007 16:46:09 -0400 Received: from wa-out-1112.google.com ([209.85.146.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfiRP-0008Oi-Ez for ietf@ietf.org; Wed, 10 Oct 2007 16:46:09 -0400 Received: by wa-out-1112.google.com with SMTP id k40so547648wah for ; Wed, 10 Oct 2007 13:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=rsg7UjDM7K2tkmmdrR+pFwtCAq3Yw7XAT2MrzEzcxb0=; b=LGPYTfZlB2HWuAekm5jMCIJo8/1epKxO/FLRGewageVtoovM2kSIFGq25bo/Sv/AbyZhiKAWRhMdYOBcMwISGH44gK54euPIY48JaTYg7HifQc+Rea+8FdKEZ2Bcob4G+28cbF2xr0XjctQDR5bJd6R8lHLu/dPBKixySmKLdzo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=cuUMT/pzcNQ7zAQVQz+1+q6TOI7IdZgRLCq9eMJ2rMFLf5af8cIWeMZSYUmT+GDvSN986pF/UkUUu1l/BLQmzminPWZHvva+2LakZ/SQgWn9Ipxev83jzS+pHjjvp7otF60tbSdGRmQKLWgKH5lTa7Qetg9qQgnXEEBmW+jKazo= Received: by 10.114.200.2 with SMTP id x2mr1268988waf.1192049134830; Wed, 10 Oct 2007 13:45:34 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id m10sm2273975waf.2007.10.10.13.45.33 (version=SSLv3 cipher=RC4-MD5); Wed, 10 Oct 2007 13:45:34 -0700 (PDT) Message-ID: <470D39E5.5060807@gmail.com> Date: Thu, 11 Oct 2007 09:45:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dave Crocker References: <46EAE465.8070104@dcrocker.net> <4707ECB0.6020302@gmail.com> <26E67D75-E5A0-4142-AC29-7CB0C24FFBD0@cisco.com> <470BE18F.3070105@dcrocker.net> <200710101331.l9ADV4ph013995@localhost.localdomain> <470CDEF4.5030805@bbiw.net> In-Reply-To: <470CDEF4.5030805@bbiw.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Thomas Narten , IETF-Discussion Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-11 03:17, Dave Crocker wrote: > > > Thomas Narten wrote: >> Dave Crocker writes: >> >>> 4. The v6 stack would need to have a v4 mode, for use by v4 >>> applications -- applications that use v4 addresses. >> >> Um, sounds an awful lot like dual-stack to me. Hosts (that understand > > > > It's not. > > No more than having your TCP use selective acks constitutes a 'dual > stack', relative to having TCP not use selective acks. While what I > suggested isn't that "minor" an enhancement to the stack, neither does > it constitute an entirely separate stack. > > To repeat: Dual stack is entirely separate. Not viewed from the socket programmer's point of view. Look at how an AF_INET6 socket behaves when given an address like ::FFFF:192.0.2.3 afaik the behavior is then exactly what you describe. Whether the stacks are independent code modules or alternate paths through the same code is irrelevant to the externally observed behavior. Brian > > That's the approach that was chosen. IPv6 is an incompatible protocol > module, compared with IPv4. Independent addressing. Independent > interfacing. Independent management. > > What I described was a compatible upgrade. Very different beast. > > Yes, it is not perfectly compatible. The only way to achieve that is to > have purely syntactic differences. > > Oh. Wait a minute. hat I described -- as a first step for adoption -- > would have been a purely syntactic difference, albeit one that set the > basis for fixing the only problem that IPv6 was originally asked to > solve: bigger address space. > > Exploiting that basis would have been moved to a strictly administrative > step. Prior to exploiting it, interoperability between IPv4 and IPv6 > could have been perfect and easy. > > But it would have had the feature of being adopted as no more than a > software upgrade (and availability of syntax-translating routers.) > > >> IPv6) also must be able to originate and receive either IPv4 packets >> or the bigger IPv6 ones. Sure, the details may be somewhat different, >> but fundamentally, we have dual stack, with IPv6 nodes needing to >> support IPv4 for backwards compatability. > > And what I described was an approach that would have permitted a "pure" > IPv6 host, where interaction with an IPv4 host required a > syntax-translating relay of some sort. > > This approach does not prohibit having a host implement both formats, > but what is fundamental is that it does not require it. This is in > marked contrast with what we have now, needing a much hairier different > translating relay, independent address administration and, really, > independent operations and management. V6 is an independent network > from V4. > > >> And in the network, routers have to understand both the original IPv4 >> format, plus the new IPv6 format. > > Yes, anything looking at a format must understand it. If IPv4 traffic > is mixed with IPv6 traffic, then yes the routers need to understand both. > > The difference in what I described is that networks that do only one of > the formats would nonetheless be part of a unified global service. What > we instead have is that we have two separate services. Separate > addressing, separate management. Very much larger barrier to adoption. > > (For reference, I am being so painfully redundant in making my points, > here, because it seems to be necessary.) > > >> If there was a magic "trivial" transition/upgrade strategy, we would >> have done it years ago. > > You must have been participating in different discussions than I was. > If one looks at the style of discussion now, what we see is an effort to > dismiss criticisms and alternatives, rather than counter them > seriously. This is what took place back then, too. Timely deadlines > were dismissed. Simplicity was dismissed. Integration was dismissed. > > The ones that I was around suffered from a classic second-system > syndrome of a) lack of pressure to delivery a timely solution, b) > feature creep, c) lack of concern for interoperability. > > Brian's reference to a history that discussed this, and other, > alternatives entirely ignores the differences between "discussing" and > "taking seriously". That is, what he does not do is explain why a > simpler approach was rejected. > > One would think that a 15-year project that was pursued to solve a > fundamental Internet limitation but has achieved such poor adoption and > use would motivate some worrying about having made some poor decisions. > A quick response that says "we talked about that" but says no more seems > a little bit facile. > > d/ _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 10 17:19:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifir1-0002YI-R0; Wed, 10 Oct 2007 17:12:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifiqv-0002X5-S2; Wed, 10 Oct 2007 17:12:25 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifiqu-0000tD-Lb; Wed, 10 Oct 2007 17:12:25 -0400 X-IronPort-AV: E=Sophos;i="4.21,256,1188802800"; d="scan'208";a="533575416" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 10 Oct 2007 14:12:23 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9ALCM69027425; Wed, 10 Oct 2007 14:12:22 -0700 Received: from elear-mac.local (sjc-vpn5-849.cisco.com [10.21.91.81]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9ALCLlD016349; Wed, 10 Oct 2007 21:12:21 GMT Message-ID: <470D4034.9090809@cisco.com> Date: Wed, 10 Oct 2007 17:12:20 -0400 From: Eliot Lear User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Sam Hartman References: <20071008014006.88BB233C21@delta.rtfm.com> <4709D647.7070004@piuha.net> <20071008125725.3B71233C57@delta.rtfm.com> <470A30CC.2030603@cisco.com> In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=584; t=1192050742; x=1192914742; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Comments=20on=20draft-aboba-sg-experiment-02 |Sender:=20; bh=4lDgQScXHkSpE2c7FX+VwfviaDDH+k0mnqVqlNFSZHY=; b=bmJMI5bRYQXAoIUVvA+91yshv7rwHSTUVZ9u3C3bmjb77QKcoNb6ii9jizljakWgtnJQQ2TL FwZ7bvs0izj7kuHBpjJ5VZBUqXTTj1D1fGM/fKnNUGle3TXbVttAnqER; Authentication-Results: sj-dkim-2; header.From=lear@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: iesg@ietf.org, Jari Arkko , ietf@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Sam Hartman wrote: >>>>>> "Eliot" == Eliot Lear writes: >>>>>> > > Eliot> If I understand the purpose of this experiment it would be > Eliot> to provide ADs some indication of level of interest and > Eliot> ability to succeed. > > Hmm. As I read the document, level of interest is explicitly out of > scope for the experiment. That needs to be determined first. > > Who is confused, you or I? > Does the document need to be updated to be more clear? > > What is the result of a "SG" hitting its mile stones? Eliot _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 10 18:37:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfjzZ-0007Qv-TC; Wed, 10 Oct 2007 18:25:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfjzX-0007JG-St; Wed, 10 Oct 2007 18:25:23 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfjzR-0002xT-NZ; Wed, 10 Oct 2007 18:25:18 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5DCED4A45; Wed, 10 Oct 2007 18:24:46 -0400 (EDT) From: Sam Hartman To: Eliot Lear References: <20071008014006.88BB233C21@delta.rtfm.com> <4709D647.7070004@piuha.net> <20071008125725.3B71233C57@delta.rtfm.com> <470A30CC.2030603@cisco.com> <470D4034.9090809@cisco.com> Date: Wed, 10 Oct 2007 18:24:46 -0400 In-Reply-To: <470D4034.9090809@cisco.com> (Eliot Lear's message of "Wed, 10 Oct 2007 17:12:20 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: iesg@ietf.org, Jari Arkko , ietf@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>>>> "Eliot" == Eliot Lear writes: Eliot> What is the result of a "SG" hitting its mile stones? We move on to evaluating its work. Now, there is a question of what happens when an SG misses its milestones. I could see an argument that hints at us being wrong that we had sufficient interest. Or perhaps an argument that the task we set the SG was harder than anticipated. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 10 21:06:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifm9l-00037p-Ob; Wed, 10 Oct 2007 20:44:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifm9g-0002tQ-PS for ietf@ietf.org; Wed, 10 Oct 2007 20:44:00 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifm9K-00072k-9K for ietf@ietf.org; Wed, 10 Oct 2007 20:43:48 -0400 Received: from c-71-197-208-131.hsd1.or.comcast.net ([71.197.208.131] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1Ifm94-00022o-RA for ietf@ietf.org; Wed, 10 Oct 2007 20:43:22 -0400 Received: by internaut.com (Postfix, from userid 1000) id 78BD6822FE; Wed, 10 Oct 2007 17:43:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 6C7E2822B8 for ; Wed, 10 Oct 2007 17:43:21 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.197.208.131 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1948SxCuGJfIlKIS/CV3VOl Date: Wed, 10 Oct 2007 17:43:21 -0700 (PDT) From: Bernard Aboba To: ietf@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Sam Hartman said: "We move on to evaluating its work. Now, there is a question of what happens when an SG misses its milestones. I could see an argument that hints at us being wrong that we had sufficient interest. Or perhaps an argument that the task we set the SG was harder than anticipated." Right. Since the bar for SG creation is the expectation of progress on basic milestones, if the SG doesn't deliver, the AD would need to re-evaluate the situation. For example, if there is both an absence of progress as well as lack of energy (e.g. minimal mailng list traffic), then an extension (or even a second BOF) might be hard to justify. It is possible that the SG could deliver substandard output (e.g. review of the Charter and 2418 criteria garners poor reviews from the IESG/IAB and IETF commmunity). In that situation, the AD needs to decide to give up or extend the SG. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 10 23:27:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfoQr-0005DZ-7C; Wed, 10 Oct 2007 23:09:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfoQp-0004tl-HO for ietf@ietf.org; Wed, 10 Oct 2007 23:09:51 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfoQd-0002hg-CP for ietf@ietf.org; Wed, 10 Oct 2007 23:09:45 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JPQ006Y88R237@usaga01-in.huawei.com> for ietf@ietf.org; Wed, 10 Oct 2007 20:09:03 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JPQ009M08QZJN@usaga01-in.huawei.com> for ietf@ietf.org; Wed, 10 Oct 2007 20:09:02 -0700 (PDT) Date: Wed, 10 Oct 2007 22:08:36 -0500 From: Spencer Dawkins To: ietf@ietf.org Message-id: <0b1c01c80bb4$03eb4bf0$6a01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: Re: Comments on draft-aboba-sg-experiment-03.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi, > The complete text of the strawman -03 document is available here: > http://www.drizzle.com/~aboba/IAB/draft-aboba-sg-experiemnt-03.txt Easily corrected typo, but just for ease of clicking, the correct URL is http://www.drizzle.com/~aboba/IAB/draft-aboba-sg-experiment-03.txt Now, for something completely different... Since this is an experiment - please don't hold up the experiment while you try to legalese-craft all the corner cases, but you might include a "things to clarify if the experiment succeeds" list... which might include this question... >From way down at the bottom of the 03 Introduction (which is really long, but): This document describes an RFC 3933 [RFC3933] experiment in the Working Group formation process, known as the Study Group. Study Groups MAY be formed by the IESG when there is evidence of clear interest in a topic on the part of IETF participants and end-users, and relevance to the Internet community has been demonstrated, but other RFC 2418 [RFC2418] criteria relating to Working Group formation (including creation of a satisfactory Charter) have not yet been met as the result of a first or second Birds-of-a-Feather (BOF) session. So far, so good... I'm not confused until the next paragraph: Study Group milestones are focused on completion of prerequisites for Working Group formation, and as a result they are expected to conclude within a short time frame, with limited opportunities for milestone extension. This Study Group experiment does not alter the Working Group formation guidelines described in RFC 2418 [RFC2418] Section 2.1, the processes relating to BoFs [BOF] or the Internet Standards Process described in RFC 2026 [RFC2026]. Is everyone but me totally clear on how BOFs interact with SGs and WGs? The way I'm reading this, the mainline path through this procedure is that some community of interest requests a BOF, with a request that's plausible enough for an AD to go for it, and then the IESG suggests a SG after the BOF. If the SG "succeeds", is there any opportunity to hold a second BOF (which seems reasonable, as a WG-forming BOF that would have more IETF-wide visibility), or does the SG have to go straight to WG (which is the way I read version 03)? And, for extra credit, if the answer is "yes", what if the community held two BOFs before the SG formed (which would be the 2418 limit)? The answer based on "does not alter the process" seems to be "no" - is that what we want? And a couple of nits... Nit: there are places in this draft that say "charter", but since both SGs and WGs have charters, it would be great if these occurences were qualified as "SG charter" or "WG charter". Nit: [BOF] is great advice (I've reviewed it at least once for Thomas), but it's not "the processes relating to BOFs [BOF]". The last time I saw [BOF], it was intended to be informational - the process is still normatively described in 2418. Thanks, Spencer _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 00:13:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfpEu-00069i-HU; Thu, 11 Oct 2007 00:01:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfpEt-00064Z-1D for ietf@ietf.org; Thu, 11 Oct 2007 00:01:35 -0400 Received: from harry.mail-abuse.org ([168.61.5.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfpEo-000852-VY for ietf@ietf.org; Thu, 11 Oct 2007 00:01:31 -0400 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 3BCAE414DF; Wed, 10 Oct 2007 21:01:30 -0700 (PDT) In-Reply-To: References: <2788466ED3E31C418E9ACC5C316615570534E4@mou1wnexmb09.vcorp.ad.vrsn.com><6.2.5.6.2.20071004111028.031d08e0@resistor.net><3D19D707-31B1-4753-8B33-2F9761A5451A@mail-abuse.org> <41DFA083-E582-4A09-9C6D-A73EB5E93BA0@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Douglas Otis Date: Wed, 10 Oct 2007 21:01:33 -0700 To: Frank Ellermann X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: ietf@ietf.org Subject: Re: TMDA backscatter X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 10, 2007, at 12:12 AM, Frank Ellermann wrote: > Douglas Otis wrote: > >> Due to the macro nature of SPF, full processing is required for =20 >> each name evaluated. > > If what you call "full processing" is the procedure to fetch the =20 > policy record of the domain in question, and match the connecting =20 > IP against this policy for a PASS / FAIL / "DUNNO" verdict, then =20 > this doesn't depend on using macros or not in the policy. IP address evaluations to determine a PASS / FAIL / DUNNO verdict may =20= require the expansion of macros inserted into SPF records. SPF =20 macros have the following syntax: %{symbol | rev-label-seq | # of right-most labels | chars-into =93.=94 } rev-label-seq =3D =93r=94 chars-into =93.=94 =3D =93-=94 | =93+=94 | =93,=94 | =93/=94 | =93_=94 | = =93=3D=94 # of right-most labels =3D 1 - 128 symbol =3D s =3D email-address or EHLO (initial parameter) l =3D left-hand side of email-address (initial parameter) o =3D right-hand side of email-address (initial parameter) d =3D email-address domain or EHLO (initial parameter) i =3D SMTP client IP addr decimal octet labels (initial parameter) p =3D r-PTR domain with IP addr validated (not initial parameter) v =3D "in-addr" IPv4, or "ip6" if IPv6 (auto generated) h =3D EHLO host-name (initial parameter) Macro expansion and text strings can be combined with any SPF record =20 mechanism and CIDR mask. Any email-address differing in just the =20 local-part must then be iteratively processed across the SPF record =20 set (up to 10 follow-on SPF records or mechanisms). For example, an MX record may be located using a label derived from =20 some component of the email-address local-part. The address for each =20= target name within the MX record must then be resolved and perhaps =20 masked prior to checking for a match. The macro expansion therefore =20 permits the same SPF record to cause a different set of DNS =20 transactions to occur over the duration of a spam campaign. The =20 macro expansion provides the spammer a means to fully leverage =20 recipient resources any number of times against any domain. The =20 domain being queried can be wholly unrelated to a domain within the =20 email being evaluated. In otherwords, a flood of queries generated =20 by spam recipients can target any innocent bystander. The SPF record =20= is able to conclude with "+all" and still obtain a PASS while staging =20= their completely free attack. > Maybe you mean that macros can reduce the chances for a DNS cache =20 > hit, e.g. for per-user-policies based on the local part macro. The per-user-policy feature of SPF makes a reflected amplification =20 attack entirely free for the spammer. Each new name evaluated from =20 their cached records can generate 508 KB in DNS traffic, a higher =20 amplification than that achieved in an open recursive attack. The SPF group dismissed this concern by suggesting DNS amplifications =20= could be further increased by including a series of bogus NS records. A single message can be sent to 100 different recipients. 100 x 100 =20 =3D 10,000 DNS transactions! Each message might be evaluated twice, =20 once for the PRA, and then again for the MAIL FROM. Who knows, =20 perhaps this might include the DKIM domain if the use of SPF is not =20 denounced. >> With SPF, the recipient might be interested in the PRA, or MAIL FROM. > > When I talk about SPF it's generally RFC 4408, i.e. MAIL FROM and =20 > HELO, not the Sender-ID PRA. The PRA doesn't necessarily help to =20 > identify a permitted or forged MAIL FROM. In other words the PRA =20 > or FWIW DKIM are not designed to avoid backscatter. DKIM could be extended to avoid backscatter and replay abuse. =20 Unfortunately, Sender-ID is being heavily promoted as the anti-=20 phishing solution. A problem not addressed by RFC4408. >> when an SPF hammer is the only tool > > Folks didn't like the idea to reintroduce RFC 821 return routes ;-) > Of course receivers are free to use any tool to avoid backscatter, =20 > but SPF is today the only tool designed for this job. I do not agree. Discouraging abuse by using RFC3464 is a far safer =20 tool. SPF is dangerous and breaks email. >> Cleaning up how DSNs are constructed would be _far_ more effective =20= >> than asking that all DSNs be dropped when SPF does not produce a =20 >> PASS. > > No. When I was the victim (back in 2004 before SPF started to =20 > work) the _size_ of DSNs and other backscatter wasn't the main =20 > issue, the _number_ of bogus auto replies was the real problem. SPF now gives bad actors a much more dangerous tool than auto-replies =20= ever represented. : ( > JFTR, "not PASS" can be FAIL or "DUNNO". FAILs should be rejected. > > Your idea to abuse DSNs for indirect spam or malware delivery is a =20 > valid consideration, but in practice the volume of all backscatter =20 > not limited to DSNs is the real problem. > > Limiting the size of DSNs is okay, but it's not "far more =20 > effective" than "reject a.s.a.p.", in fact it misses the point wrt =20 > backscatter. This was in terms of reducing risk. SPF is a dangerous mechanism =20 which attempts to leverage a recipient's resources. Had the =20 recipient known who sent the message, SPF would not be needed. As a =20 general rule, when the source is unknown, any scripted use of =20 resources offered MUST be extremely limited. SPF violates this rule. >> Perhaps that is why Bell Canada ensures all addresses achieve a =20 >> PASS. : ( > > Oops, bell.ca still has this ridiculous policy, that certainly =20 > won't help them to reduce backscatter. Obviously that is not why the SPF record is published. At least the =20 "+all" discourages use of dangerous SPF libraries while also reducing =20= the breakage and permitting white-listing. >>> Auto responders aren't in a good position to verify the validity =20 >>> of the return path. Good positions to do this are the MSA based =20 >>> on RFC 4409 and later the MX based on RFC 4408. > >> RFC4408 did not mitigate a potential DDoS exploit. This exploit =20 >> exists when recipients attempt to process SPF as specified. > > Actually they've to ignore a SHOULD in the security considerations =20 > of RFC 4408 if they wish to participate in your convoluted attack =20 > scenario. And the SPF RFC did mitigate this potential with several =20= > MUSTs in the security considerations in comparison with pre-MARID =20 > drafts. No! Although there are many SPF parsing libraries in distribution =20 that ignore the SHOULDs, the example attack scenario is not prevented =20= by any RFC4408 SHOULD or MUSTs! The attack was based upon a _fully_ =20 RFC4408 compliant SPF parser! -Doug _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 01:23:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfqIS-0004nF-1F; Thu, 11 Oct 2007 01:09:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfqIQ-0004mr-5N for ietf@ietf.org; Thu, 11 Oct 2007 01:09:18 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfqIF-0007me-RJ for ietf@ietf.org; Thu, 11 Oct 2007 01:09:14 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9B58kaJ005688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Oct 2007 22:08:46 -0700 Received: from [10.50.66.58] (qconnect-10-50-66-58.qualcomm.com [10.50.66.58]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9B58jca002351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Oct 2007 22:08:45 -0700 (PDT) Message-ID: <470DAFE3.6050706@qualcomm.com> Date: Wed, 10 Oct 2007 22:08:51 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Spencer Dawkins References: <0b1c01c80bb4$03eb4bf0$6a01a8c0@china.huawei.com> In-Reply-To: <0b1c01c80bb4$03eb4bf0$6a01a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: ietf@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-03.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Given the confusion around this, let me try to enumerate all paths (I will enumerate the end result as WG, but please substitute it with "Stop" for the failure cases) Idea --> WG Idea --> SG --> WG Idea --> BoF-1 --> WG Idea --> BoF-1 --> BoF-2 --> WG Idea --> BoF-1 --> SG --> WG Idea --> BoF-1 --> BoF-2 --> SG --> WG I am not too keen on SG --> BoF; but, if the sponsoring AD wants to do it, I guess it may make sense to not explicitly disallow it. We can probably look for that data during the experiment. If the SG failed to develop a consensus charter during its life, a BoF session most likely won't result in a different result (although one could argue that due to time constraints or other reasons, the community evaluation of the charter they developed can be done at a f2f meeting as opposed to at a meeting; a similar argument has been made here by folks). To not flout the 2418 rule, if two BoFs were already held and an SG was created, it's WG or nothing after the SG. So, we may also accommodate Idea --> SG --> BoF-1 --> WG Idea --> BoF-1 --> SG --> BoF-2 --> WG The following two options do not make sense: Idea --> SG --> BoF-1 --> BoF-2 Idea --> BoF-1 --> SG --> BoF-2 --> BoF (2418 disallows this) Idea --> BoF-1 --> BoF-2 --> SG --> BoF (2418 disallows this) (Hope I didn't make a mistake there ;) ) regards, Lakshminath On 10/10/2007 8:08 PM, Spencer Dawkins wrote: > Hi, > >> The complete text of the strawman -03 document is available here: >> http://www.drizzle.com/~aboba/IAB/draft-aboba-sg-experiemnt-03.txt > > Easily corrected typo, but just for ease of clicking, the correct URL is > > http://www.drizzle.com/~aboba/IAB/draft-aboba-sg-experiment-03.txt > > Now, for something completely different... > > Since this is an experiment - please don't hold up the experiment while > you try to legalese-craft all the corner cases, but you might include a > "things to clarify if the experiment succeeds" list... which might > include this question... > >> From way down at the bottom of the 03 Introduction (which is really long, > but): > > This document describes an RFC 3933 [RFC3933] experiment in the > Working Group formation process, known as the Study Group. Study > Groups MAY be formed by the IESG when there is evidence of clear > interest in a topic on the part of IETF participants and end-users, > and relevance to the Internet community has been demonstrated, but > other RFC 2418 [RFC2418] criteria relating to Working Group formation > (including creation of a satisfactory Charter) have not yet been met > as the result of a first or second Birds-of-a-Feather (BOF) session. > > So far, so good... I'm not confused until the next paragraph: > > Study Group milestones are focused on completion of prerequisites for > Working Group formation, and as a result they are expected to > conclude within a short time frame, with limited opportunities for > milestone extension. This Study Group experiment does not alter the > Working Group formation guidelines described in RFC 2418 [RFC2418] > Section 2.1, the processes relating to BoFs [BOF] or the Internet > Standards Process described in RFC 2026 [RFC2026]. > > Is everyone but me totally clear on how BOFs interact with SGs and WGs? > > The way I'm reading this, the mainline path through this procedure is > that some community of interest requests a BOF, with a request that's > plausible enough for an AD to go for it, and then the IESG suggests a SG > after the BOF. > > If the SG "succeeds", is there any opportunity to hold a second BOF > (which seems reasonable, as a WG-forming BOF that would have more > IETF-wide visibility), or does the SG have to go straight to WG (which > is the way I read version 03)? > > And, for extra credit, if the answer is "yes", what if the community > held two BOFs before the SG formed (which would be the 2418 limit)? The > answer based on "does not alter the process" seems to be "no" - is that > what we want? > > And a couple of nits... > > Nit: there are places in this draft that say "charter", but since both > SGs and WGs have charters, it would be great if these occurences were > qualified as "SG charter" or "WG charter". > > Nit: [BOF] is great advice (I've reviewed it at least once for Thomas), > but it's not "the processes relating to BOFs [BOF]". The last time I saw > [BOF], it was intended to be informational - the process is still > normatively described in 2418. > > Thanks, > > Spencer > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 03:54:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfsdX-0008Ko-GV; Thu, 11 Oct 2007 03:39:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfsdV-0008Es-8I; Thu, 11 Oct 2007 03:39:13 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfsdO-0003jH-D0; Thu, 11 Oct 2007 03:39:12 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9B7cmOk019559; Thu, 11 Oct 2007 10:38:50 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 10:38:34 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 10:38:33 +0300 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" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Oct 2007 10:38:30 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Re: Last call comments for draft-lepinski-dh-groups-01 Thread-Index: AcgLSzn1NYo0dNhlRXiUN7rjtHQcbAAjlqEg References: From: To: , , X-OriginalArrivalTime: 11 Oct 2007 07:38:33.0271 (UTC) FILETIME=[B9C73C70:01C80BD9] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: kent@bbn.com, mlepinski@bbn.com Subject: RE: [IPsec] Re: Last call comments for draft-lepinski-dh-groups-01 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Paul Hoffman wrote: > >2) For IKEv1/IKEv2, the document should explicitly specify how > >ECC points are converted to octet strings (for KE payloads > >and resulting shared secret value). Currently, there are at > >least three incompatible options (RFC 4753, RFC 2409, and > >draft-ietf-ipsec-ike-ecc-groups-10 drafts). I'd suggest just > >saying "the same way as in RFC 4753". >=20 > This bodes really poorly for interoperability.=20 > draft-lepinski-dh-groups needs to be revised to specify one of the=20 > methods, and that needs to be discussed on the IPsec mailing list.=20 > I would not assume that implementers would prefer RFC 4753 over=20 > draft-ietf-ipsec-ike-ecc-groups. I suggested "the same way as in RFC 4753" not because I particularly prefer that point-to-octet-string conversion method, but because I would prefer not having three different methods (two is bad enough). (Note that the current ecc-groups-10 draft actually tries to=20 modify the definitions of groups 19/20/21 from RFC 4753: it reuses the same numbers but with different point-to-octet-string conversion method.) Best regards, Pasi _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 04:18:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ift8O-0000IF-NR; Thu, 11 Oct 2007 04:11:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ift8M-0000FN-6b; Thu, 11 Oct 2007 04:11:06 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ift8L-0007hv-RT; Thu, 11 Oct 2007 04:11:06 -0400 X-IronPort-AV: E=Sophos;i="4.21,258,1188770400"; d="scan'208";a="155499288" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 11 Oct 2007 10:11:03 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9B8B28m028025; Thu, 11 Oct 2007 10:11:02 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp4612.cisco.com [10.61.82.3]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9B8AxSO025568; Thu, 11 Oct 2007 08:11:00 GMT Message-ID: <470DDA92.4010804@cisco.com> Date: Thu, 11 Oct 2007 04:10:58 -0400 From: Eliot Lear User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Sam Hartman References: <20071008014006.88BB233C21@delta.rtfm.com> <4709D647.7070004@piuha.net> <20071008125725.3B71233C57@delta.rtfm.com> <470A30CC.2030603@cisco.com> <470D4034.9090809@cisco.com> In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=895; t=1192090262; x=1192954262; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Comments=20on=20draft-aboba-sg-experiment-02 |Sender:=20; bh=ZVAZQ5YOU3R7ygRHxRyK/iusrYVclg7A1IoIAIVjkqg=; b=hPt+It3CHDtGB/OdOafZ2a1ZMfQqGBjIx90leCtAp5pnK31F8/bn+Xnmuyh7gOPS6MrGssX8 UUJsC7/OqTv5C/1br04+Qxwa8sHjjF+NCapJMsl6DZ96liQdOMdgj9UV; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: iesg@ietf.org, Jari Arkko , ietf@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Sam, >>>>>> "Eliot" == Eliot Lear writes: >>>>>> > > Eliot> What is the result of a "SG" hitting its mile stones? > > We move on to evaluating its work. > > Now, there is a question of what happens when an SG misses its > milestones. I could see an argument that hints at us being wrong that > we had sufficient interest. Or perhaps an argument that the task we > set the SG was harder than anticipated. > As I wrote earlier, I am not at all sure that we should even have dates associated with milestones with this kind of experiment. What is the anticipated administrative load? If we can keep it to nothingness such that an AD can simply have these things (and I still maintain that it should barely require even an AD's approval), then WHENEVER a group hits those milestones we know that it's time to pay more attention. Eliot _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 04:50:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IftZI-0003Qe-U1; Thu, 11 Oct 2007 04:38:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IftZG-0003QV-By for ietf@ietf.org; Thu, 11 Oct 2007 04:38:54 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IftZ8-0006Ft-Pg for ietf@ietf.org; Thu, 11 Oct 2007 04:38:54 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IftYy-000317-6F for ietf@ietf.org; Thu, 11 Oct 2007 04:38:36 -0400 Date: Thu, 11 Oct 2007 04:38:35 -0400 From: John C Klensin To: ietf@ietf.org Message-ID: <5C4564C6F879D2DF9E4C88DD@p3.JCK.COM> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi. I've been trying to follow this discussion from a safe distance, but, given the amount of traffic, I want to add three general observations to the mix, possibly summarizing some earlier comments including my own: (1) Drawing analogies from IEEE, or IEEE 802, procedures to the IETF and extrapolating what will work is a tricky business, if only because of different ground rules for participation and approval of projects and different assumptions about standing committees / project areas in the two groups. (2) As the discussion goes on, if appears to me that, in practice, an SG is little more than a normal WG with an unusual set of charter-time constraints. While unusual, those constraints are well within the boundaries of what the IESG is permitted to do today. Indeed, I believe that groups have been chartered under constraints and with responsibilities not appreciably different from those that would apply to an SG. From that perspective, our real problem is that, in the last few years, IESG members have not felt that they have sufficient community support (or pressure) to quickly and efficiently shut down WGs that are drifting or otherwise not performing. An SG model could provide a less painful shutdown point by permitting simply not extending the SG or not granting a WG charter, rather than having to shut down something that has a few advocates or some investment, even if it is not making progress. But, as others have pointed out, that same opportunity exists in principle when WG benchmarks are not met. Whether an SG model is effective in eliminating pre-project efforts that would go nowhere would seem to depend on precisely the same factors that make the possibility of WG shutdown effective: support by the community for identifying and shutting down disfunctional efforts and willingness by the ADs for doing so. (3) I am concerned about anything that creates new opportunities for making the process of getting work into, through, and out of the IETF even longer and more complicated. The worst risk associated with introducing SGs is that, just as we have evolved from "A BOF, or sometimes two, are optional steps to help get a WG organized and focused" to "BOFs are almost always required", we might evolve into the expectation of spending one or more IETF meetings in SGs, as well as an additional meeting or two in BOFs, before generating a typical WG charter. In the notation of Lakshminath's recent chart, we have moved from "Idea --> WG" being the normal case, to "Idea --> BoF-1 --> BoF-2 --> WG" being the normal case, to some risk of making "Idea --> BoF-1 --> BoF-2 --> SG --> WG" normal. Under some circumstances, that would be a year well spent. Under others, it is just another year wasted in exploration, extended problem description, and procedures when the goal should be to do technical work and get useful results out (and to cut unfocused ideas and ideas with insufficient support out of the system with as little wasted time and energy as possible). Nonetheless, it seems clear from the list discussions that there are a number of people in the community who think this is worth trying. Precisely because it doesn't seem to create any substantively new options or framework and because its use is optional, it seems to me that it is worth trying, if only in the hope of refocusing the energy that seems to be going into discussing its details back onto technical work. I would suggest that the "experiment" model was designed with the intention of permitting experiments to be flexible and that it would be preferable to either * give the IESG discretion to set and evolve the details or * to establish an ad hoc experiment specification, modification, and evaluation group to fix and modify details and generally guide the experiment and advise the IESG and the community about successes and failures on an ongoing basis. Very detailed design --whether of technology or procedures -- on the IETF list has almost never worked for us in the past, yet it seems that is exactly what people are trying to do with this proposal. Just my opinion, of course. john _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 05:42:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfuL0-0001wJ-7k; Thu, 11 Oct 2007 05:28:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfuKy-0001t8-70 for ietf@ietf.org; Thu, 11 Oct 2007 05:28:12 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfuKm-0008TS-Qa for ietf@ietf.org; Thu, 11 Oct 2007 05:28:07 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IfuJU-0007hl-8w for ietf@ietf.org; Thu, 11 Oct 2007 09:26:40 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 11 Oct 2007 09:26:40 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 11 Oct 2007 09:26:40 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: "Frank Ellermann" Date: Thu, 11 Oct 2007 11:23:18 +0200 Lines: 98 Message-ID: References: <2788466ED3E31C418E9ACC5C316615570534E4@mou1wnexmb09.vcorp.ad.vrsn.com><6.2.5.6.2.20071004111028.031d08e0@resistor.net><3D19D707-31B1-4753-8B33-2F9761A5451A@mail-abuse.org><41DFA083-E582-4A09-9C6D-A73EB5E93BA0@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Subject: Re: TMDA backscatter X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Douglas Otis wrote: > Macro expansion and text strings can be combined with any SPF record > mechanism and CIDR mask. Any email-address differing in just the > local-part must then be iteratively processed across the SPF record > set (up to 10 follow-on SPF records or mechanisms). Yes, an attacker can use 10 mx mechanisms in his malicious policy for domains under his control with names containing 10 different parts of the LHS (local part) in his envelope sender address. > The SPF record is able to conclude with "+all" and still obtain a > PASS Sure, a PASS for "mail from" unknown strangers only guarantees that=20 bounces and other auto-replies won't hit innocent bystanders. A PASS can be still spam or an attack, but it won't create backscatter, that is more or less the idea of SPF. > A single message can be sent to 100 different recipients. 100 x 100 > =3D 10,000 DNS transactions! The number of RCPT TO for a given MAIL FROM at the border MTA where SPF is checked is irrelevant, it's evaluated once. Actually the same MAIL FROM at a given border MTA has no further effect while the SPF and MX records of the attacker are still cached. But of course an attacker can send more mails to more domains with different envelope sender addresses, and he can tune the TTL of his SPF and MX records. Whatever he does, your attack scenario depends on the mx mechanism, and you get an amplification factor of about 10 DNS queries to the victim per DNS query to the attacker. The attacker could also try to abuse "call back verification" with his bogus MX records for a better amplification factor without SPF. AFAIK SPF is so far the only protocol specifying "processing limits" for DNS based attacks. RFC 2821 certainly doesn't talk about it, and I'm not aware of any processing limits wrt SRV or NS records. Maybe you should propose some "MX processing limits" for 2821bis. > DKIM could be extended to avoid backscatter and replay abuse. Hardly. DKIM is intentionally independent of SMTP, it doesn't look at the envelope sender address. The envelope sender address (aka return path, mail from, or bounce address) and the MX concept are the essence of SMTP, anything else is syntactical sugar. The PRA is the best approximation of the envelope sender address, but DKIM also doesn't look at the PRA, it's not designed to fight backscatter. =20 > Unfortunately, Sender-ID is being heavily promoted as the anti-=20 > phishing solution. A problem not addressed by RFC4408. RFC 4408 doesn't discuss PRA or phishing or 2822, it's about SMTP and backscatter. For discussions why the best approximation PRA isn't good enough see the pages. =20 Using PRA as anti-phishing solution might make sense, with several caveats addressed in the IESG note. Unlike PRA pure DKIM offers no FAIL, it can help to identify various kinds of "non-phishing". That's not the same as "anti-phishing". > Had the recipient known who sent the message, SPF would not be > needed. Indeed, SPF is used to figure out when "originator as indicated in the reverse path" in RFC 2821 is acceptable (PASS) or should be rejected (FAIL) at a border MTA. Other uses of SPF are at best nice to have, and in the worst case dangerous. >> Oops, bell.ca still has this ridiculous policy, that certainly =20 >> won't help them to reduce backscatter. > Obviously that is not why the SPF record is published. If all they want is a PASS they could use a short "v=3Dspf1 +all" without the other PASSing gibberish they're publishing now. > At least the "+all" discourages use of dangerous SPF libraries No, "v=3Dspf1 +all" and more verbose policies with the same effect are perfectly valid and supported by SPF libraries, dangerous or otherwise. =20 > the example attack scenario is not prevented by any RFC4408=20 > SHOULD or MUSTs | SPF implementations SHOULD limit the total amount of data obtained | from the DNS queries. For example, when DNS over TCP or EDNS0 are | available, there may need to be an explicit limit to how much data | will be accepted to prevent excessive bandwidth usage or memory usage | and DoS attacks. Frank _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 07:04:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfvZZ-00055p-H4; Thu, 11 Oct 2007 06:47:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfvZY-00054j-Av for ietf@ietf.org; Thu, 11 Oct 2007 06:47:20 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfvZT-0002nR-UG for ietf@ietf.org; Thu, 11 Oct 2007 06:47:16 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id 52D96233D1; Thu, 11 Oct 2007 19:46:53 +0900 (JST) To: brian.e.carpenter@gmail.com In-Reply-To: Your message of "Thu, 11 Oct 2007 09:45:25 +1300" <470D39E5.5060807@gmail.com> References: <470D39E5.5060807@gmail.com> X-Mailer: Cue version 0.8 (070521-1856/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20071011104653.52D96233D1@coconut.itojun.org> Date: Thu, 11 Oct 2007 19:46:53 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: -0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ietf@ietf.org Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > Not viewed from the socket programmer's point of view. > Look at how an AF_INET6 socket behaves when given > an address like ::FFFF:192.0.2.3 > afaik the behavior is then exactly what you describe. > Whether the stacks are independent code modules or > alternate paths through the same code is irrelevant > to the externally observed behavior. see draft-ietf-v6ops-security-overview-06.txt section 2.2. itojun _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 07:04:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifvk1-00063E-OL; Thu, 11 Oct 2007 06:58:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifvjz-000638-JV for ietf@ietf.org; Thu, 11 Oct 2007 06:58:07 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifvjz-0005Sk-1Y for ietf@ietf.org; Thu, 11 Oct 2007 06:58:07 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9BAvY3c017594 for ; Thu, 11 Oct 2007 13:58:05 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 13:57:44 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 13:54:36 +0300 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" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Oct 2007 13:54:40 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Third Last Call: draft-housley-tls-authz-extns Thread-Index: AcgL9R+oss1B3MuzSxCDc8licLl7fw== From: To: X-OriginalArrivalTime: 11 Oct 2007 10:54:36.0065 (UTC) FILETIME=[1CF32910:01C80BF5] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: Re: Third Last Call: draft-housley-tls-authz-extns X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > The IESG is considering approving this draft as an experimental > track RFC with knowledge of the IPR disclosure from Redphone > Security. The IESG solicits final comments on whether the IETF > community has consensus to publish draft-housley-tls-authz-extns as > an experimental standard given the IPR claimed. Basically repeating the comments I made earlier: I think this document is somewhat useful, and whatever you may think about IPRs, basically nobody has claimed that the technical solution is flawed (except one minor detail, easily solved by an RFC editor note -- see below) or undesirable.=20 However, since there doesn't seem to be widespread support for this draft, an Experimental RFC seems like the most appropriate forward (since Experimental does not need to represent IETF community consensus or recommendation).=20 The minor detail that should be fixed (as was pointed out by others) is changing the length fields from 16 bits to 24 bits=20 (the rest of TLS already uses 24-bit length fields for certificates). Best regards, Pasi _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 07:50:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfwN8-000168-95; Thu, 11 Oct 2007 07:38:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfwN6-00013F-Nz; Thu, 11 Oct 2007 07:38:32 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfwN1-0004Ue-GT; Thu, 11 Oct 2007 07:38:32 -0400 X-IronPort-AV: E=Sophos;i="4.21,259,1188770400"; d="scan'208";a="155528107" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Oct 2007 13:38:09 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9BBc96v024857; Thu, 11 Oct 2007 13:38:09 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp4612.cisco.com [10.61.82.3]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9BBc2SO017961; Thu, 11 Oct 2007 11:38:07 GMT Message-ID: <470E0B1A.20507@cisco.com> Date: Thu, 11 Oct 2007 13:38:02 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=330; t=1192102689; x=1192966689; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Comments=20on=20draft-aboba-sg-experiment-03.txt |Sender:=20; bh=n0owKlhQM1wLQq+22a/F/58cjadwFN101YhruxsPu/g=; b=hVNxAE5m6itDrdqxNkcHdq+Bn0yMLc2mwYbpT6GuJzRAm6ww7b/H841fYrFmoNhwbB5p2pLA 49aCkDci7EGGHLA5CxkdFMww0D7oNJ88ivxt/3RnD/hFQtOWN3LIfNvG; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Aaron Falk , ietf@ietf.org, 'IESG' Subject: Re: Comments on draft-aboba-sg-experiment-03.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I have one additional concern about this proposal. If a study group is intended to meet at an IETF, it will compete with slot requests both from IETF working groups and IRTF research groups. I wouldn't want to prohibit f2fs but I would certainly suggest that they come in low on the totem pole for space requests. Eliot _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 08:34:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifx24-0001CL-Hs; Thu, 11 Oct 2007 08:20:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifx22-0001Bi-Va for ietf@ietf.org; Thu, 11 Oct 2007 08:20:51 -0400 Received: from burp.tkv.asdf.org ([212.16.99.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifx22-00089l-AW for ietf@ietf.org; Thu, 11 Oct 2007 08:20:50 -0400 Received: from burp.tkv.asdf.org (localhost [127.0.0.1]) by burp.tkv.asdf.org (8.14.1/8.14.1/Debian-8ubuntu1) with ESMTP id l9BCKmBP024902 for ; Thu, 11 Oct 2007 15:20:48 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.14.1/8.14.1/Submit) id l9BCKmJX024899; Thu, 11 Oct 2007 15:20:48 +0300 Date: Thu, 11 Oct 2007 15:20:48 +0300 From: Markku Savela Message-Id: <200710111220.l9BCKmJX024899@burp.tkv.asdf.org> To: ietf@ietf.org In-reply-to: <20071011104653.52D96233D1@coconut.itojun.org> References: <470D39E5.5060807@gmail.com> <20071011104653.52D96233D1@coconut.itojun.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > From: itojun@itojun.org (Jun-ichiro itojun Hagino) > Cc: ietf@ietf.org > > > Not viewed from the socket programmer's point of view. > > Look at how an AF_INET6 socket behaves when given > > an address like ::FFFF:192.0.2.3 > > afaik the behavior is then exactly what you describe. > > Whether the stacks are independent code modules or > > alternate paths through the same code is irrelevant > > to the externally observed behavior. > > see draft-ietf-v6ops-security-overview-06.txt section 2.2. My view is that "::FFFF:192.0.0.2" totally identical with "192.0.0.2" (internally inside the host stack implementation). There will be no functional difference anywhere in API, whichever form is used. I realize, that the above is not easy to achieve using the legacy POSIX socket API, which has has different sized address structures for IPv4 and IPv6. In Symbian OS, there is no such problem. The generic address structure allocation (TInetAddr) can hold both IPv4 and IPv6 address. Thus, the there is only one IP stack, which just happens to do IPv4, when address is IPv4 (either 192.0.0.2 or ::FFFF:192.0.0.2"). Real IPv6 addresses trigger IPv6 processing. Logically stack implements *one* "INET family" (PF_INET) with two possible address families "AF_INET" and "AF_INET6". Applications can be written totally agnostic on whether connection is over IPv4 or IPv6. All sockets are just opened as AF_INET, and the addresses used determine whether IPv4 or IPv6 gets used. On listening "undefined address family" can be used to accept both IPv4 and IPv6 for the same socket (TCP or UDP). Receiving "::FFFF:127.0.0.1" from network is not going to work as an attack, because of "strong model", and 127.0.0.1 is not configured for the real interface (=> destination 127.0.0.1 does not match configured address and gets dropped). _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 10:08:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfyUP-0007Zr-MS; Thu, 11 Oct 2007 09:54:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfyUN-0007ZS-VP for ietf@ietf.org; Thu, 11 Oct 2007 09:54:11 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfyUN-0005Bf-It for ietf@ietf.org; Thu, 11 Oct 2007 09:54:11 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IfyUM-000AuC-GX; Thu, 11 Oct 2007 09:54:10 -0400 Date: Thu, 11 Oct 2007 09:54:09 -0400 From: John C Klensin To: Pasi.Eronen@nokia.com Message-ID: <9712782B6C5C89F23D11EEAD@p3.JCK.COM> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ietf@ietf.org Subject: Re: Third Last Call: draft-housley-tls-authz-extns X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org --On Thursday, 11 October, 2007 13:54 +0300 Pasi.Eronen@nokia.com wrote: >... > I think this document is somewhat useful, and whatever you may > think about IPRs, basically nobody has claimed that the > technical solution is flawed (except one minor detail, easily > solved by an RFC editor note -- see below) or undesirable. > > However, since there doesn't seem to be widespread support for > this draft, an Experimental RFC seems like the most > appropriate forward (since Experimental does not need to > represent IETF community consensus or recommendation). Assuming that this logic is reasonable (and, personally, I do), the question remains as to why the document deserves the special treatment of IESG sponsorship, rather than turning it over to the tender mercies and independent review of the independent submission process. If nothing else, handling it as an independent submission would remove any suspicion that it was being given special treatment because one of its authors was IETF Chair. I'm not strongly advocating that approach, just asking. john _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 10:12:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfyhZ-0002J1-97; Thu, 11 Oct 2007 10:07:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfyhX-0002HR-5f for ietf@ietf.org; Thu, 11 Oct 2007 10:07:47 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfyhW-0005dv-LA for ietf@ietf.org; Thu, 11 Oct 2007 10:07:47 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9BE72Dt023309; Thu, 11 Oct 2007 17:07:42 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 17:07:35 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 17:05:20 +0300 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" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Oct 2007 17:05:20 +0300 Message-ID: In-Reply-To: <9712782B6C5C89F23D11EEAD@p3.JCK.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Third Last Call: draft-housley-tls-authz-extns Thread-Index: AcgMDpkNETJj2SQjQWey3eLwAtKW6gAANb1w References: <9712782B6C5C89F23D11EEAD@p3.JCK.COM> From: To: X-OriginalArrivalTime: 11 Oct 2007 14:05:20.0341 (UTC) FILETIME=[C2451850:01C80C0F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ietf@ietf.org Subject: RE: Third Last Call: draft-housley-tls-authz-extns X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org John C Klensin wrote: > Assuming that this logic is reasonable (and, personally, I do), > the question remains as to why the document deserves the special > treatment of IESG sponsorship, rather than turning it over to > the tender mercies and independent review of the independent > submission process. If nothing else, handling it as an > independent submission would remove any suspicion that it was > being given special treatment because one of its authors was > IETF Chair. >=20 > I'm not strongly advocating that approach, just asking. The IANA rules in this case require a document approved by the IESG; otherwise, independent submission would indeed be preferable. Best regards, Pasi _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 10:22:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifyqd-0001mu-Ac; Thu, 11 Oct 2007 10:17:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifyqc-0001av-5M for ietf@ietf.org; Thu, 11 Oct 2007 10:17:10 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfyqT-0005zC-EB for ietf@ietf.org; Thu, 11 Oct 2007 10:17:01 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JPR004OS3OBS5@usaga01-in.huawei.com> for ietf@ietf.org; Thu, 11 Oct 2007 07:17:00 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JPR00C8M3O946@usaga01-in.huawei.com> for ietf@ietf.org; Thu, 11 Oct 2007 07:16:59 -0700 (PDT) Date: Thu, 11 Oct 2007 09:16:31 -0500 From: Spencer Dawkins To: ietf@ietf.org Message-id: <0c9301c80c11$5278b980$6a01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5C4564C6F879D2DF9E4C88DD@p3.JCK.COM> X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org John, Thank you for upleveling. I plead guilty to wandering through the detailed design. I agree without comment with the rest of your observations, but one stuck out. > (2) As the discussion goes on, if appears to me that, in > practice, an SG is little more than a normal WG with an > unusual set of charter-time constraints. While unusual, > those constraints are well within the boundaries of what > the IESG is permitted to do today. Indeed, I believe > that groups have been chartered under constraints and > with responsibilities not appreciably different from > those that would apply to an SG. If your understanding of the intention for SGs is correct (and I think it is), and if current process BCPs allow this mode of operation (and I think they would), I'm wondering if this draft should be published as an ION. ftp://ftp.rfc-editor.org/in-notes/rfc3933.txt is intended for process CHANGES. As we both know, the goal was to describe a lightweight alternative to formal/two-BOFs-plus-a-WG change to formal BCPs - RFC 3933 experiments are still relatively heavyweight, compared to publishing an ION. Perhaps all that is required is to describe a style of WG charter, since the IESG already has discretion to charter as many, or as few, WGs with this style of charter as seems appropriate, and has discretion to continue doing that, or to stop doing that, as results seem to dictate. If there are formal process changes required (doesn't matter what change, only that SGs require something that is explicitly disallowed in RFC 2418), then a process experiment would make sense, but if we don't change formal processes we don't have to worry about unintended side effects that require formal process change AGAIN to fix (with http://www1.ietf.org/mail-archive/web/ietf/current/msg48434.html for a recent example of what "require formal process change AGAIN to fix" looks like, for anyone else who might have missed it). Thanks, Spencer _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 11:01:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfzKx-0006v6-6S; Thu, 11 Oct 2007 10:48:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfzKv-0006su-4h for ietf@ietf.org; Thu, 11 Oct 2007 10:48:29 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfzKt-00055A-S9 for ietf@ietf.org; Thu, 11 Oct 2007 10:48:29 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IfzKt-000ClU-3y; Thu, 11 Oct 2007 10:48:27 -0400 Date: Thu, 11 Oct 2007 10:48:26 -0400 From: John C Klensin To: Pasi.Eronen@nokia.com Message-ID: <64ECC96122232BBA8ED1FABF@p3.JCK.COM> In-Reply-To: References: <9712782B6C5C89F23D11EEAD@p3.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ietf@ietf.org Subject: RE: Third Last Call: draft-housley-tls-authz-extns X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org --On Thursday, 11 October, 2007 17:05 +0300 Pasi.Eronen@nokia.com wrote: > John C Klensin wrote: > >> Assuming that this logic is reasonable (and, personally, I >> do), the question remains as to why the document deserves the >> special treatment of IESG sponsorship, rather than turning it >> over to the tender mercies and independent review of the >> independent submission process. If nothing else, handling it >> as an independent submission would remove any suspicion that >> it was being given special treatment because one of its >> authors was IETF Chair. >> >> I'm not strongly advocating that approach, just asking. > > The IANA rules in this case require a document approved by the > IESG; otherwise, independent submission would indeed be > preferable. Strictly speaking, at least as I understand it, the IANA rules (actually, the IETF rules imposed on the IANA) require IESG approval of the registration, not IESG approval/publication of the document. If independent submission would be preferable, nothing would prohibit making that submission. Then, assuming that the RFC Editor tentatively agreed to publish, the document would be submitted for RFC 3932 review and the IESG could sign off on IANA registration at that point. That effectively requires the IESG to make a decision to register at RFC 3932 review time, since doing otherwise would presumably block publication of a document that specified such registration, but it seems to me that is not a big deal, especially in this case (where the registration has already occurred as the result of the first IESG decision on the matter). It may be, in practice, too late to handle this document that way because of the discussion and IANA registration that have already occurred, but, in terms of thinking about future cases... john _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 11:15:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifzd9-0007fz-1v; Thu, 11 Oct 2007 11:07:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifzd7-0007fB-02 for ietf@ietf.org; Thu, 11 Oct 2007 11:07:17 -0400 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifzd6-00018U-EN for ietf@ietf.org; Thu, 11 Oct 2007 11:07:16 -0400 Received: from [192.168.169.243] (72-255-65-82.client.stsn.net [72.255.65.82]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l9BF6WEw005634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Oct 2007 08:06:35 -0700 Message-ID: <470E3C29.2070006@bbiw.net> Date: Thu, 11 Oct 2007 11:07:21 -0400 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian E Carpenter References: <46EAE465.8070104@dcrocker.net> <4707ECB0.6020302@gmail.com> <26E67D75-E5A0-4142-AC29-7CB0C24FFBD0@cisco.com> <470BE18F.3070105@dcrocker.net> <200710101331.l9ADV4ph013995@localhost.localdomain> <470CDEF4.5030805@bbiw.net> <470D39E5.5060807@gmail.com> In-Reply-To: <470D39E5.5060807@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: IETF-Discussion Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Brian E Carpenter wrote: >> No more than having your TCP use selective acks constitutes a 'dual >> stack', relative to having TCP not use selective acks. While what I >> suggested isn't that "minor" an enhancement to the stack, neither does it >> constitute an entirely separate stack. >> >> To repeat: Dual stack is entirely separate. > > Not viewed from the socket programmer's point of view. Look at how an > AF_INET6 socket behaves when given an address like ::FFFF:192.0.2.3 afaik > the behavior is then exactly what you describe. Apparently you missed most of the rest of my note, such as: >> Yes, it is not perfectly compatible. The only way to achieve that is to >> have purely syntactic differences. >> >> Oh. Wait a minute. hat I described -- as a first step for adoption -- >> would have been a purely syntactic difference, albeit one that set the >> basis for fixing the only problem that IPv6 was originally asked to >> solve: bigger address space. >> >> Exploiting that basis would have been moved to a strictly administrative >> step. Prior to exploiting it, interoperability between IPv4 and IPv6 >> could have been perfect and easy. The underlying point of my note was: > One would think that a 15-year project that was pursued to solve a > fundamental Internet limitation but has achieved such poor adoption and use > would motivate some worrying about having made some poor decisions. A > quick response that says "we talked about that" but says no more seems a > little bit facile. Yet your response continues down the path of "What was decided was fine. So let's dismiss expressions of concerns about it by citing a previous decision, as if that choice was inevitable." In particular, my point was that a v6-specific API was not immediately required. The approach to IPv6 could have been vastly more incremental, so as to make its adoption vastly less disruptive. But you have to start by considering the benefits of such an approach. Brian, the approach to IPv6 ignored protecting the installed base and ignored finding a way to have the lowest possible barriers to adoption. As 15 years of non-adoption has demonstrated, the value proposition for adopters also was not compelling. To repeat: At some point, it would help to take history as being instructive, rather than to dismiss attempts at considering alternatives. This might not change the situation with IPv6, but it could have an effect on other, future work. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 11:19:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifzlt-0006wH-Jv; Thu, 11 Oct 2007 11:16:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifzlr-0006vU-QS for ietf@ietf.org; Thu, 11 Oct 2007 11:16:19 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifzll-0006Cx-MS for ietf@ietf.org; Thu, 11 Oct 2007 11:16:19 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id F0F601EE2C8; Thu, 11 Oct 2007 11:15:57 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+3G5eBY1VM8; Thu, 11 Oct 2007 11:15:55 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 265731EE2AD; Thu, 11 Oct 2007 11:15:55 -0400 (EDT) Message-ID: <470E3E2A.60307@cs.utk.edu> Date: Thu, 11 Oct 2007 11:15:54 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Dave Crocker References: <46EAE465.8070104@dcrocker.net> <4707ECB0.6020302@gmail.com> <26E67D75-E5A0-4142-AC29-7CB0C24FFBD0@cisco.com> <470BE18F.3070105@dcrocker.net> <200710101331.l9ADV4ph013995@localhost.localdomain> <470CDEF4.5030805@bbiw.net> <470D39E5.5060807@gmail.com> <470E3C29.2070006@bbiw.net> In-Reply-To: <470E3C29.2070006@bbiw.net> X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: IETF-Discussion Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > The underlying point of my note was: > >> One would think that a 15-year project that was pursued to solve a >> fundamental Internet limitation but has achieved such poor adoption >> and use >> would motivate some worrying about having made some poor decisions. A >> quick response that says "we talked about that" but says no more seems a >> little bit facile. > > Yet your response continues down the path of "What was decided was > fine. So let's dismiss expressions of concerns about it by citing a > previous decision, as if that choice was inevitable." In particular, > my point was that a v6-specific API was not immediately required. perhaps not. but without such an API, software would not have been able to migrate. so at the point when people started to actually want to use the extended addresses, the software would not have been there. > To repeat: At some point, it would help to take history as being > instructive, rather than to dismiss attempts at considering alternatives. yes. but it's not instructive to pick apart the solution that was chosen and claim that some other solution would have produced a better result, without applying similar analysis to the alternative. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 12:23:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig0c1-0006HB-Ti; Thu, 11 Oct 2007 12:10:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig0c0-0006Du-Pd for ietf@ietf.org; Thu, 11 Oct 2007 12:10:12 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig0bu-0000JJ-C0 for ietf@ietf.org; Thu, 11 Oct 2007 12:10:07 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Ig0bn-000FKg-D7; Thu, 11 Oct 2007 12:09:59 -0400 Date: Thu, 11 Oct 2007 12:09:58 -0400 From: John C Klensin To: Dave Crocker , Brian E Carpenter Message-ID: In-Reply-To: <470E3C29.2070006@bbiw.net> References: <46EAE465.8070104@dcrocker.net> <4707ECB0.6020302@gmail.com> <26E67D75-E5A0-4142-AC29-7CB0C24FFBD0@cisco.com> <470BE18F.3070105@dcrocker.net> <200710101331.l9ADV4ph013995@localhost.localdomain> <470CDEF4.5030805@bbiw.net> <470D39E5.5060807@gmail.com> <470E3C29.2070006@bbiw.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: IETF-Discussion Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Dave, Reordering your comments slightly.,.. --On Thursday, 11 October, 2007 11:07 -0400 Dave Crocker wrote: > To repeat: At some point, it would help to take history as > being instructive, rather than to dismiss attempts at > considering alternatives. > > This might not change the situation with IPv6, but it could > have an effect on other, future work. It is hard to predict the future. It is almost equally hard to draw firm conclusions from the fairly recent past, especially when drawing those conclusions requires understanding the counterfactual implications of various choices. I agree that history is instructive and should not be ignored, but think we should hesitate to jump to conclusions about what it tells us. > The approach to IPv6 could have been vastly more incremental, > so as to make its adoption vastly less disruptive. But you > have to start by considering the benefits of such an approach. > > Brian, the approach to IPv6 ignored protecting the installed > base and ignored finding a way to have the lowest possible > barriers to adoption. As 15 years of non-adoption has > demonstrated, the value proposition for adopters also was not > compelling. Examining a value proposition requires asking both the question "how hard, expensive, or risky is it for me to do this?" and "how do I benefit if I do?". Larger benefits justify larger investments; a perception of few benefits may not justify even a small investment. From that perspective, even small changes to something that is perceived as working satisfactorily involve risks of bugs and disruption. There is no way to make a change zero-cost and zero-risk. Certainly it is reasonable to hypothesize, as you are doing, that decisions about transition and compatibilities with IPv6 created a bad value proposition by making transition too complicated and costly. But it is equally reasonable to hypothesize that the error lay in our failure to address enough other issues -- to solve enough other problems -- to create real "pull" for making changes, no matter how cheap those changes appeared to be. Would IPv6 have been more successful had the solution addressed fundamental routing issues more directly? If it somehow made small-site multihoming more straightforward and plausible? If it incorporated a solution to the semantic and management issues implied by RFC 3514? If it solved some other real or imagined problem with IP? If we had simultaneously overhauled TCP to support more connection-agile or address-insensitive use of applications? As things have turned out, we've pretty much ended up with "IPv4 with more bits". Selling that one to the community is hard except on the basis of either an anti-NAT campaign or one based on the imminent falling of the sky. The former is made more difficult by the observation that most user organizations do not perceive that they are suffering real harm from NATs (whether that perception is correct or incorrect is irrelevant) and more difficult yet by concerns that IPv6 will not eliminate some of the factors that cause NATs. The latter is made more difficult by too many prior predictions, some unrealistic over-marketing, and an inability to see the sky moving downward and accurately and convincingly anticipate the dire effects of its coming down. Can one demonstrate that, given those factors, an easier transition process would have made a significant difference? Possibly it would have, but I don't think there is any way to be convinced. On the other hand, had IPv6 offered more than what the market seems to see as a mostly-theoretical improvement (elimination of NATs) and avoidance of a future address space catastrophe) -- some obvious advantages to those who who already have deployed IPv4 installations and the address space needed to support them-- would we have seen wider adoption? Again, there is no way to know for sure but, if the answer is "yes", then it is hard to guess how much difference a slightly easier transition would have made. So, let us by all means look at history and try to learn its lessons. But let us also be sure we know what those lessons actually are, rather than using the historical argument to justify a position that may not be supported by the evidence. best, john _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 13:16:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig1Rg-0000MS-FF; Thu, 11 Oct 2007 13:03:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig1Rd-0000BD-K6 for ietf@ietf.org; Thu, 11 Oct 2007 13:03:34 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig1RX-0003FW-A9 for ietf@ietf.org; Thu, 11 Oct 2007 13:03:33 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9BH3FFC026920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 Oct 2007 10:03:16 -0700 Received: from [129.46.78.94] (ldondeti.na.qualcomm.com [129.46.78.94]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9BH3DF6010482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Oct 2007 10:03:13 -0700 Message-ID: <470E5757.7070802@qualcomm.com> Date: Thu, 11 Oct 2007 10:03:19 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: John C Klensin References: <5C4564C6F879D2DF9E4C88DD@p3.JCK.COM> In-Reply-To: <5C4564C6F879D2DF9E4C88DD@p3.JCK.COM> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ietf@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Just for the record, if the norm ends up being "Idea --> BoF-1 --> BoF-2 --> SG --> WG," I would be very disappointed and would chalk that up under the law of unintended consequences :). I am hoping that "Idea --> SG --> WG" or "Idea --> BoF1 --> SG --> WG" in that order become the norm (where SG is involved of course), especially when proponents of new work are people who may not be regulars at the IETF. regards, Lakshminath On 10/11/2007 1:38 AM, John C Klensin wrote: In the notation of Lakshminath's > recent chart, we have moved from "Idea --> WG" being > the normal case, to "Idea --> BoF-1 --> BoF-2 --> WG" > being the normal case, to some risk of making "Idea --> > BoF-1 --> BoF-2 --> SG --> WG" normal. Under some > circumstances, that would be a year well spent. Under > others, it is just another year wasted in exploration, > extended problem description, and procedures when the > goal should be to do technical work and get useful > results out (and to cut unfocused ideas and ideas with > insufficient support out of the system with as little > wasted time and energy as possible). > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 14:14:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig2N4-0006rv-Ff; Thu, 11 Oct 2007 14:02:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig2N3-0006qY-0x for ietf@ietf.org; Thu, 11 Oct 2007 14:02:53 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig2Mw-0005XJ-Ob for ietf@ietf.org; Thu, 11 Oct 2007 14:02:53 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Ig2Mr-000Jlc-3E; Thu, 11 Oct 2007 14:02:41 -0400 Date: Thu, 11 Oct 2007 14:02:40 -0400 From: John C Klensin To: Lakshminath Dondeti Message-ID: <789A2774B09717149D2C31D4@p3.JCK.COM> In-Reply-To: <470E5757.7070802@qualcomm.com> References: <5C4564C6F879D2DF9E4C88DD@p3.JCK.COM> <470E5757.7070802@qualcomm.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ietf@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org --On Thursday, 11 October, 2007 10:03 -0700 Lakshminath Dondeti wrote: > Just for the record, if the norm ends up being "Idea --> BoF-1 > --> BoF-2 --> SG --> WG," I would be very disappointed and > would chalk that up under the law of unintended consequences > :). Unfortunately, there is some history in the IETF that might lead someone who is even mildly cynical about the way procedures unfold and are used (and it is probably obvious that I passed "mildly" long ago) to predict that would be exactly the outcome, unintended or not. To the extent to which the IESG tends to be responsive to community input and sensitive to constraints about meeting and management time --and I'd hope they would be responsive to both -- it might take only a few loud voices saying "not ready" to turn BOF1 into a requirement for BOF2 (arguably we see that already) and similar voices to turn the outcome of BOF2 from "WG" into "SG and more consideration". In practice, that might turn at least some SGs into exactly what I think you are trying to avoid: an indeterminable series of BOF-list sessions with a charter and under a different name. That would also be an unintended consequence, but I don't see how to avoid it other than to trust the IESG to manage SGs more aggressively than they have historically managed WGs and to assume that the community would vigorously support them in applying that level of management. I am hoping that "Idea --> SG --> WG" or "Idea --> BoF1 > --> SG --> WG" in that order become the norm (where SG is > involved of course), especially when proponents of new work > are people who may not be regulars at the IETF. If the goal is really the education and socialization of newcomers and refinement of their ideas, shouldn't we be thinking about more direct, explicit, and efficient ways to do that, rather than about new procedures and process steps? john _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 14:34:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig2ij-0005zF-01; Thu, 11 Oct 2007 14:25:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig2ih-0005ve-Hx for ietf@ietf.org; Thu, 11 Oct 2007 14:25:15 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig2ib-0006Dj-8m for ietf@ietf.org; Thu, 11 Oct 2007 14:25:15 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9BIOv2n005332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 Oct 2007 11:24:58 -0700 Received: from [129.46.78.94] (ldondeti.na.qualcomm.com [129.46.78.94]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9BIOvTm005120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Oct 2007 11:24:57 -0700 Message-ID: <470E6A7F.9030507@qualcomm.com> Date: Thu, 11 Oct 2007 11:25:03 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: John C Klensin References: <5C4564C6F879D2DF9E4C88DD@p3.JCK.COM> <470E5757.7070802@qualcomm.com> <789A2774B09717149D2C31D4@p3.JCK.COM> In-Reply-To: <789A2774B09717149D2C31D4@p3.JCK.COM> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ietf@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org My cynicism hasn't reached that level yet, although people tell me that it will get there very soon given some of the activities I have signed up for. :) That out of the way, the intention of the proposal is to provide a framework for people with reasonable ideas for work at the IETF to develop those ideas and eventually succeed in standardization of protocols in that area, and sooner than later. (the venue for developing the ideas for work is the SG whereas standardization of protocols is to happen in WGs that may or may not have been formed as a result of the SGs). regards, Lakshminath On 10/11/2007 11:02 AM, John C Klensin wrote: > --On Thursday, 11 October, 2007 10:03 -0700 Lakshminath Dondeti > wrote: > >> Just for the record, if the norm ends up being "Idea --> BoF-1 >> --> BoF-2 --> SG --> WG," I would be very disappointed and >> would chalk that up under the law of unintended consequences >> :). > > Unfortunately, there is some history in the IETF that might lead > someone who is even mildly cynical about the way procedures > unfold and are used (and it is probably obvious that I passed > "mildly" long ago) to predict that would be exactly the outcome, > unintended or not. To the extent to which the IESG tends to be > responsive to community input and sensitive to constraints about > meeting and management time --and I'd hope they would be > responsive to both -- it might take only a few loud voices > saying "not ready" to turn BOF1 into a requirement for BOF2 > (arguably we see that already) and similar voices to turn the > outcome of BOF2 from "WG" into "SG and more consideration". > > In practice, that might turn at least some SGs into exactly what > I think you are trying to avoid: an indeterminable series of > BOF-list sessions with a charter and under a different name. > That would also be an unintended consequence, but I don't see > how to avoid it other than to trust the IESG to manage SGs more > aggressively than they have historically managed WGs and to > assume that the community would vigorously support them in > applying that level of management. > > I am hoping that "Idea --> SG --> WG" or "Idea --> BoF1 >> --> SG --> WG" in that order become the norm (where SG is >> involved of course), especially when proponents of new work >> are people who may not be regulars at the IETF. > > If the goal is really the education and socialization of > newcomers and refinement of their ideas, shouldn't we be > thinking about more direct, explicit, and efficient ways to do > that, rather than about new procedures and process steps? > > john > > > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 14:59:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig35i-00084s-Ks; Thu, 11 Oct 2007 14:49:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig35g-00084l-Q9 for ietf@ietf.org; Thu, 11 Oct 2007 14:49:00 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ig35e-0003ff-BS for ietf@ietf.org; Thu, 11 Oct 2007 14:48:58 -0400 Received: from c-71-197-208-131.hsd1.or.comcast.net ([71.197.208.131] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1Ig35d-000Kg0-FP for ietf@ietf.org; Thu, 11 Oct 2007 14:48:57 -0400 Received: by internaut.com (Postfix, from userid 1000) id 7140A82313; Thu, 11 Oct 2007 11:48:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 65C2D82311 for ; Thu, 11 Oct 2007 11:48:56 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.197.208.131 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+JzkmcXQFdFmNgJMSvGgMR Date: Thu, 11 Oct 2007 11:48:56 -0700 (PDT) From: Bernard Aboba To: ietf@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: Re: comments on draft-aboba-sg-experiment-03.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org John Klensin said: " (2) As the discussion goes on, if appears to me that, in practice, an SG is little more than a normal WG with an unusual set of charter-time constraints." No, because WGs cannot be formed to come up with a WG charter (or RFC 2418 Section 2.1 criteria for WG formation). "The worst risk associated with introducing SGs is that, just as we have evolved from "A BOF, or sometimes two, are optional steps to help get a WG organized and focused" to "BOFs are almost always required", we might evolve into the expectation of spending one or more IETF meetings in SGs, as well as an additional meeting or two in BOFs, before generating a typical WG charter." I agree that this would be a bad thing -- and that's why the draft indicates that the experiment should not short-circuit creation of WGs that already satisfy the criteria. In any case, the experiment only lasts 18 months, and it seems unlikely that the IETF would devolve that quickly. "In the notation of Lakshminath's recent chart, we have moved from "Idea --> WG" being the normal case, to "Idea --> BoF-1 --> BoF-2 --> WG" being the normal case" Do the data back up this assertion? Quite a few WGs have been formed after a single BOF, or if two BOFs were required, then the agenda of the second BOF was more like that of a WG than a BOF. "to some risk of making "Idea --> BoF-1 --> Bof-2 --> SG --> WG" normal." I am personally not very enamored of this case. If the second BoF fails, my inclination would be say "that's it". I'm also not sure if a SG can be formed without a first BOF, because the document currently states that interest is a pre-requisite for SG formation, and how do we gauge that without at least one BOF? So IMHO, the "common case" is: Idea --> BoF --> SG --> WG or nothing. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 15:23:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig3W6-0002V0-7z; Thu, 11 Oct 2007 15:16:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig3W4-0002MG-VZ for ietf@ietf.org; Thu, 11 Oct 2007 15:16:16 -0400 Received: from harry.mail-abuse.org ([168.61.5.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig3Vr-0000lO-O8 for ietf@ietf.org; Thu, 11 Oct 2007 15:16:14 -0400 Received: from [10.2.164.130] (SJC-Office-NAT-212.Mail-Abuse.ORG [168.61.10.212]) by harry.mail-abuse.org (Postfix) with ESMTP id EAB42414DE; Thu, 11 Oct 2007 12:15:47 -0700 (PDT) In-Reply-To: References: <2788466ED3E31C418E9ACC5C316615570534E4@mou1wnexmb09.vcorp.ad.vrsn.com><6.2.5.6.2.20071004111028.031d08e0@resistor.net><3D19D707-31B1-4753-8B33-2F9761A5451A@mail-abuse.org><41DFA083-E582-4A09-9C6D-A73EB5E93BA0@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <74C293FF-7E90-44F1-B4F0-55E3B10D48D9@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Date: Thu, 11 Oct 2007 12:15:52 -0700 To: Frank Ellermann X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -4.0 (----) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Cc: ietf@ietf.org Subject: Re: TMDA backscatter X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 11, 2007, at 2:23 AM, Frank Ellermann wrote: > Douglas Otis wrote: > >> Macro expansion and text strings can be combined with any SPF >> record mechanism and CIDR mask. Any email-address differing in >> just the local-part must then be iteratively processed across the >> SPF record set (up to 10 follow-on SPF records or mechanisms). > > Yes, an attacker can use 10 mx mechanisms in his malicious policy > for domains under his control with names containing 10 different > parts of the LHS (local part) in his envelope sender address. Each of 10 MX records may necessitate resolving 10 target addresses for a total of 100 targeted DNS transactions per SPF name evaluation. By using the local-part in a spam campaign, one cached SPF record is able to reference an unlimited sequence of MX records. Targets within MX records can also utilize a small variable label together with large static labels to leverage DNS name compression. Without MX records being cached with dependence upon negative cache expiring, the network amplification of an SPF related attack using MX targeting would be about 10. After a recipient's negative caching expires, repeating a sequence of local-parts in a spam campaign could thereafter use cached MX records. Negative caching is not always under the control of the victim. Once a set of MX records becomes cached and their target's negative response expire, the entire attack becomes entirely _free_ for spammers. Spammers often send messages continuously. A spam campaign can come from any source, purport to be from any domain, and yet attack the same innocent victim which can not be identified by examining the message. : ( >> The SPF record is able to conclude with "+all" and still obtain a >> PASS > > Sure, a PASS for "mail from" unknown strangers only guarantees that > bounces and other auto-replies won't hit innocent bystanders. A > PASS can be still spam or an attack, but it won't create > backscatter, that is more or less the idea of SPF. Compared to an SPF related attack, most auto-replies will consume a greater amount of an attackers resources, identify the source of the attack, and not achieve the same level of amplification. In the case of SPF, the attack can become entirely free and completely hidden while spamming! Rate limiting auto-replies would be a much safer solution for the recipient to perform. >> A single message can be sent to 100 different recipients. 100 x >> 100 = 10,000 DNS transactions! > > The number of RCPT TO for a given MAIL FROM at the border MTA where > SPF is checked is irrelevant, it's evaluated once. Actually the > same MAIL FROM at a given border MTA has no further effect while > the SPF and MX records of the attacker are still cached. But of > course an attacker can send more mails to more domains with > different envelope sender addresses, and he can tune the TTL of his > SPF and MX records. Each recipient can be within a different domain where a MAIL FROM and the PRA may be both evaluated. By expanding upon the local-part of the email-address, caching SPF records actually aids the attack. The only tuning required would be that of the local-part sequence. Duration of the sequence only needs to be a bit longer than the negative caching of the recipient. > Whatever he does, your attack scenario depends on the mx mechanism, > and you get an amplification factor of about 10 DNS queries to the > victim per DNS query to the attacker. Do you really think a spammer is unable to attack at a gain of 10, and then continue the attack at no cost once the duration of the attack exceeds the negative caching (determined by the recipients). SPF enables a long duration DDoS attack. Good luck at attempting to prevent this type of attack or at identifying the source. Block all SPF records? > The attacker could also try to abuse "call back verification" with > his bogus MX records for a better amplification factor without SPF. The SPF can also attack those using wildcard MX, TXT or A records. This attack would be instantly free and much simpler as it would not require waiting for negative caching to expire. : ( > AFAIK SPF is so far the only protocol specifying "processing > limits" for DNS based attacks. RFC 2821 certainly doesn't talk > about it, and I'm not aware of any processing limits wrt SRV or NS > records. SPF introduces a long list of macros locating a sequence of records, that then often involve additional DNS transactions. Even the time limit applied by SPF disables DNS congestion avoidance! > Maybe you should propose some "MX processing limits" for 2821bis. Most systems are fairly careful about where they send messages to avoid being blocked, nor would the normal use of MX records require all targets be resolved. Timeouts recommended by RFC2821 ensure this operation remains fairly safe, unlike that for SPF. Even the packet limitation of DNS provides a fairly reasonable limit. >> DKIM could be extended to avoid backscatter and replay abuse. > > Hardly. DKIM is intentionally independent of SMTP, it doesn't look > at the envelope sender address. The envelope sender address (aka > return path, mail from, or bounce address) and the MX concept are > the essence of SMTP, anything else is syntactical sugar. A policy record at the MAIL FROM domain could reference an authorized DKIM signature within a single DNS transaction. The same type of policy record could be applied against the SMTP client to curtail replay abuse. The MAIL FROM policy could thereby ensure a DSN is issued when there is a problem, and the SMTP client could avoid possible grey-listing should the recipient find replay abuse to be problematic. > The PRA is the best approximation of the envelope sender address, > but DKIM also doesn't look at the PRA, it's not designed to fight > backscatter. DKIM can be processed prior to acceptance, and could safely help prevent backscatter with a few minor by-name extensions. >> Unfortunately, Sender-ID is being heavily promoted as the anti- >> phishing solution. A problem not addressed by RFC4408. > > RFC 4408 doesn't discuss PRA or phishing or 2822, it's about SMTP > and backscatter. For discussions why the best approximation PRA > isn't good enough see the pages. Agreed, but that does not mean that two names PRA and MAIL FROM will not be checked. > Using PRA as anti-phishing solution might make sense, with several > caveats addressed in the IESG note. Unlike PRA pure DKIM offers no > FAIL, it can help to identify various kinds of "non-phishing". > That's not the same as "anti-phishing". From my point of view, anti-phishing requires examination of message content more than just email headers. When the message appears to be misleading, and is not signed as expected, it should be marked as suspicious or rejected. >> Had the recipient known who sent the message, SPF would not be >> needed. > > Indeed, SPF is used to figure out when "originator as indicated in > the reverse path" in RFC 2821 is acceptable (PASS) or should be > rejected (FAIL) at a border MTA. Other uses of SPF are at best > nice to have, and in the worst case dangerous. When desired, path registration should be by-name and not by-address to avoid the unscalability, complexity, and risk. Something as simple as CSV and a MAIL FROM policy record is far more scalable, easier to manage, and much safer. >>> Oops, bell.ca still has this ridiculous policy, that certainly >>> won't help them to reduce backscatter. > >> Obviously that is not why the SPF record is published. > > If all they want is a PASS they could use a short "v=spf1 +all" > without the other PASSing gibberish they're publishing now. I suspect they felt pressured by ISPs like AOL who use SPF records to white-list other large providers. This indicates being part of the club. >> At least the "+all" discourages use of dangerous SPF libraries > > No, "v=spf1 +all" and more verbose policies with the same effect > are perfectly valid and supported by SPF libraries, dangerous or > otherwise. It also removes any possible advantage for running these libraries and avoids problems where the path of the message and the path expressed by SPF legitimately differ. >> the example attack scenario is not prevented by any RFC4408 SHOULD >> or MUSTs > > > | SPF implementations SHOULD limit the total amount of data obtained > | from the DNS queries. For example, when DNS over TCP or EDNS0 are > | available, there may need to be an explicit limit to how much data > | will be accepted to prevent excessive bandwidth usage or memory > usage > | and DoS attacks. The example attack scenario never exceeded typical DNS transaction sizes. It did not use TCP or EDNS0. It did not exceed the SHOULD limits on the number of mechanisms or subsequent address resolutions. SPF, as current defined, remains very dangerous. The use of libraries implementing SPF per this specification are dangerous as they permit a totally free attack, where the source is hidden, and there is not a means to defend against it. -Doug _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 15:47:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig3rL-0008P9-Ms; Thu, 11 Oct 2007 15:38:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig3rJ-0008GA-DC for ietf@ietf.org; Thu, 11 Oct 2007 15:38:13 -0400 Received: from rv-out-0910.google.com ([209.85.198.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig3rE-0001dF-60 for ietf@ietf.org; Thu, 11 Oct 2007 15:38:13 -0400 Received: by rv-out-0910.google.com with SMTP id l15so538944rvb for ; Thu, 11 Oct 2007 12:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=eH0S8sGx2aJTAeMmD86O27DfIKZkFhyugoBriu958U4=; b=B9zuqJK6CJXIUCvwx+ZyWH5K5KxMA943cy1zlSrqVLJYNK99n783/OrRDzuL23G1n9o28tPpcpulTCBxwFH1lJf8hjOE84lBkW0qGGQKkrKGTk3S/Z9R5bqD2MVOLqAmGNW9ZMm8uvjAsMvm/y30IYgR87HSYOmunOS+L78BQYQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=q4vSVlg9Bv2cNeY7Xr6yQ8ZhXVGglhksUXezJxAX3dHu2zFTtiDSp5rYGlfOeDWsZLLOYXFrinI5vAD+cCTc52oRVLp6uHvFkJQNVnwJSvAdiNVni1cahben2tNunn3OjPDovvvIxP00WsTYs/Fg9GIRqNM6tlx7AZrD3ROikhQ= Received: by 10.141.44.15 with SMTP id w15mr1132681rvj.1192131460267; Thu, 11 Oct 2007 12:37:40 -0700 (PDT) Received: from ?10.1.1.7? ( [222.153.1.229]) by mx.google.com with ESMTPS id 3sm4346627rvi.2007.10.11.12.37.35 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Oct 2007 12:37:39 -0700 (PDT) Message-ID: <470E7B76.3080106@gmail.com> Date: Fri, 12 Oct 2007 08:37:26 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eliot Lear References: <20071008014006.88BB233C21@delta.rtfm.com> <4709D647.7070004@piuha.net> <20071008125725.3B71233C57@delta.rtfm.com> <470A30CC.2030603@cisco.com> <470D4034.9090809@cisco.com> <470DDA92.4010804@cisco.com> In-Reply-To: <470DDA92.4010804@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: iesg@ietf.org, ietf@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-11 21:10, Eliot Lear wrote: ... > As I wrote earlier, I am not at all sure that we should even have dates > associated with milestones with this kind of experiment. I'm afraid that this would allow people to game the IETF by abusing the SG mechanism to give their effort an appearance of open-ended status. We probably don't want to see CV's including lines like "chair of IETF foobar Study Group, 2008-2011". Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 15:47:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig3wc-0001Ay-Pk; Thu, 11 Oct 2007 15:43:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig3wb-00019D-Lg for ietf@ietf.org; Thu, 11 Oct 2007 15:43:41 -0400 Received: from rv-out-0910.google.com ([209.85.198.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ig3wb-000726-9q for ietf@ietf.org; Thu, 11 Oct 2007 15:43:41 -0400 Received: by rv-out-0910.google.com with SMTP id l15so540644rvb for ; Thu, 11 Oct 2007 12:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=N08F8S1ta9xUpahSd07Ep86Y5b5u5LD4HRW82lPiZ3c=; b=uBA4KT7w1Gcqm73DaYESe69TsjJAW/Ddg8hE+NFfHLONkPl40gYv/X7+1Y7RdWxhqd1iiIC61VhDz2lODs0CidrbxJAkV5JmLP0u0e1OtZvmJvfadFOrh+P21tW2nlA7fu5C59o/2MHYDjmgm0+7KTXB06I/LVCV1K/WvEoL7lU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=KY27m/2y2N2qf87lwcyEjQEdcb8uoZfIomyyPJu9QwTfA6sy4TgeSobYU8QlrpcVLye1mfzUgNwBxkznh2LBg+FeJFIyfDAfjPaFQxzSRYmv8ITp2TZeOTkFLOA6setqt2ZXyxBzY5mz+NRU16yNLG0uic34+5/p/scD18SlTTg= Received: by 10.141.15.19 with SMTP id s19mr1140529rvi.1192131819888; Thu, 11 Oct 2007 12:43:39 -0700 (PDT) Received: from ?10.1.1.7? ( [222.153.1.229]) by mx.google.com with ESMTPS id b34sm4408869rvf.2007.10.11.12.43.33 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Oct 2007 12:43:35 -0700 (PDT) Message-ID: <470E7CD5.3000209@gmail.com> Date: Fri, 12 Oct 2007 08:43:17 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jun-ichiro itojun Hagino References: <470D39E5.5060807@gmail.com> <20071011104653.52D96233D1@coconut.itojun.org> In-Reply-To: <20071011104653.52D96233D1@coconut.itojun.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ietf@ietf.org Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-11 23:46, Jun-ichiro itojun Hagino wrote: >> Not viewed from the socket programmer's point of view. >> Look at how an AF_INET6 socket behaves when given >> an address like ::FFFF:192.0.2.3 >> afaik the behavior is then exactly what you describe. >> Whether the stacks are independent code modules or >> alternate paths through the same code is irrelevant >> to the externally observed behavior. > > see draft-ietf-v6ops-security-overview-06.txt section 2.2. Sure. I absolutely don't like to see ::FFFF/96 on the wire. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 15:49:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig3zu-0001iu-UR; Thu, 11 Oct 2007 15:47:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig3zt-0001d9-84 for ietf@ietf.org; Thu, 11 Oct 2007 15:47:05 -0400 Received: from rv-out-0910.google.com ([209.85.198.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig3zl-00021M-3J for ietf@ietf.org; Thu, 11 Oct 2007 15:47:04 -0400 Received: by rv-out-0910.google.com with SMTP id l15so541285rvb for ; Thu, 11 Oct 2007 12:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=kuEo8E25b/BdEzOekxPuALVvU/vBYpr9wz4kiHTDJKc=; b=tceztORz9h5tpkcTtob9diliROphSA6ub16Ubzng7Mt3FYP2RUZvYyoh9OQtyxJwo3N0zF6XPbW6PYX/Fhz249G/lCatzvxQKialgV/Ja9dulqrrKttvqqJA8Q70BSsQL19kgaMIedCKub9ONxP/63Fpzq4KPGDNXoZ6fK2RhPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=cOk6514uRf7JA+DAck8KdM0spRYl2K5D9BLWR0KTUzpuAWOlJLEnGvYpm0xcjYDHElNekhdhFpJu5GIEH8FDC5v6cJwYNrDKb+p67PXxNwHnJzgp9PrDUlK6mi3I+pJI/vi5fPGI0s8W5HAM3PRP+zFqIvXZMdPok5pBCBfMZRA= Received: by 10.141.210.5 with SMTP id m5mr1142009rvq.1192132001782; Thu, 11 Oct 2007 12:46:41 -0700 (PDT) Received: from ?10.1.1.7? ( [222.153.1.229]) by mx.google.com with ESMTPS id b5sm4439424rva.2007.10.11.12.46.40 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Oct 2007 12:46:41 -0700 (PDT) Message-ID: <470E7D97.7050503@gmail.com> Date: Fri, 12 Oct 2007 08:46:31 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dave Crocker References: <46EAE465.8070104@dcrocker.net> <4707ECB0.6020302@gmail.com> <26E67D75-E5A0-4142-AC29-7CB0C24FFBD0@cisco.com> <470BE18F.3070105@dcrocker.net> <200710101331.l9ADV4ph013995@localhost.localdomain> <470CDEF4.5030805@bbiw.net> <470D39E5.5060807@gmail.com> <470E3C29.2070006@bbiw.net> In-Reply-To: <470E3C29.2070006@bbiw.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: IETF-Discussion Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Dave, On 2007-10-12 04:07, Dave Crocker wrote: > ... > The underlying point of my note was: > >> One would think that a 15-year project that was pursued to solve a >> fundamental Internet limitation but has achieved such poor adoption >> and use >> would motivate some worrying about having made some poor decisions. A >> quick response that says "we talked about that" but says no more seems a >> little bit facile. > > Yet your response continues down the path of "What was decided was fine. No, I'm on the path of trying to be precise and accurate about what was decided. Since it's engineering, it isn't perfect. > So let's dismiss expressions of concerns about it by citing a previous > decision, as if that choice was inevitable." In particular, my point was > that a v6-specific API was not immediately required. > > The approach to IPv6 could have been vastly more incremental, so as to > make its adoption vastly less disruptive. But you have to start by > considering the benefits of such an approach. > > Brian, the approach to IPv6 ignored protecting the installed base and > ignored finding a way to have the lowest possible barriers to adoption. > As 15 years of non-adoption has demonstrated, the value proposition for > adopters also was not compelling. > > To repeat: At some point, it would help to take history as being > instructive, rather than to dismiss attempts at considering alternatives. > > This might not change the situation with IPv6, but it could have an > effect on other, future work. I can't possibly disagree with that, but my interest is in getting the implemented code deployed before the IPv4 clock winds down. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 18:54:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig6aa-00015j-30; Thu, 11 Oct 2007 18:33:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig6aX-0000vy-RI for ietf@ietf.org; Thu, 11 Oct 2007 18:33:05 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ig6aP-0000ro-Fq for ietf@ietf.org; Thu, 11 Oct 2007 18:32:57 -0400 Received: from c-71-197-208-131.hsd1.or.comcast.net ([71.197.208.131] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1Ig6aO-000Jnk-SS for ietf@ietf.org; Thu, 11 Oct 2007 18:32:57 -0400 Received: by internaut.com (Postfix, from userid 1000) id D4B6682316; Thu, 11 Oct 2007 15:32:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id CAC3C8230B for ; Thu, 11 Oct 2007 15:32:55 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.197.208.131 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18o2jpU2SBrISDc47Ys58Y/ Date: Thu, 11 Oct 2007 15:32:55 -0700 (PDT) From: Bernard Aboba To: ietf@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: Re: comments on draft-aboba-sg-experiment-03.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Brian Carpenter said: "I'm afraid that this would allow people to game the IETF by abusing the SG mechanism to give their effort an appearance of open-ended status. We probably don't want to see CV's including lines like "chair of IETF foobar Study Group, 2008-2011"." That would be scary indeed. The basic idea is to provide clear goals and feedback on status -- and encourage the participants to make quick progress. Nothing clears the mind better than an upcoming deadline, particularly one that is difficult to extend. Frankly, if a SG can't come up with consensus on a WG charter and an explanation of why the RFC 2418 criteria are satisfied within the 6 to 12 month initial milestone, the odds of WG success are not very good either. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 18:59:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig6vR-0005Lc-KX; Thu, 11 Oct 2007 18:54:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig6vP-00058V-9y; Thu, 11 Oct 2007 18:54:39 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ig6vO-0001dn-W9; Thu, 11 Oct 2007 18:54:39 -0400 X-IronPort-AV: E=Sophos;i="4.21,261,1188802800"; d="scan'208";a="235161500" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 11 Oct 2007 15:54:38 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l9BMscvR009216; Thu, 11 Oct 2007 15:54:38 -0700 Received: from [192.168.4.2] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l9BMsbG2027868; Thu, 11 Oct 2007 22:54:37 GMT In-Reply-To: <470E0B1A.20507@cisco.com> References: <470E0B1A.20507@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1EADBBE4-82AD-4B90-958B-EBB2A09585C6@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Thu, 11 Oct 2007 15:54:31 -0700 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=457; t=1192143278; x=1193007278; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20Comments=20on=20draft-aboba-sg-experiment-03.txt |Sender:=20; bh=qwQxfWZWghgPCOD+8YaQdsaMcZGpwNH7v7mYQfFjO6Y=; b=gsWmhVn3W/OlLUtYMoefszLfCUdRJkaaBYlFjzr0QpaFY6TAG6rUjk7sB0+7peqTOgrAd1Rx 7tWlxkwUJ9qdhZSfyD/dpF7ycbnphMTfX5Li94R1D3NIAXCiPOaT4dUm; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: IESG , Aaron Falk , ietf@ietf.org, Bernard Aboba Subject: Re: Comments on draft-aboba-sg-experiment-03.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Would you see them being above or below BOFs? On Oct 11, 2007, at 4:38 AM, Eliot Lear wrote: > I have one additional concern about this proposal. If a study > group is > intended to meet at an IETF, it will compete with slot requests both > from IETF working groups and IRTF research groups. I wouldn't want to > prohibit f2fs but I would certainly suggest that they come in low > on the > totem pole for space requests. > > Eliot > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 19:19:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig7B1-0000Yz-GE; Thu, 11 Oct 2007 19:10:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig7Az-0008A1-3d for ietf@ietf.org; Thu, 11 Oct 2007 19:10:45 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig7Am-0001w8-RB for ietf@ietf.org; Thu, 11 Oct 2007 19:10:38 -0400 Received: from c-71-197-208-131.hsd1.or.comcast.net ([71.197.208.131] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1Ig7AX-00051U-Aj; Thu, 11 Oct 2007 19:10:17 -0400 Received: by internaut.com (Postfix, from userid 1000) id 7622982317; Thu, 11 Oct 2007 16:10:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 66D2E8230B; Thu, 11 Oct 2007 16:10:16 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.197.208.131 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/aGQB2p8YtQSY97O5L/TKJ Date: Thu, 11 Oct 2007 16:10:16 -0700 (PDT) From: Bernard Aboba To: Cullen Jennings In-Reply-To: <1EADBBE4-82AD-4B90-958B-EBB2A09585C6@cisco.com> Message-ID: References: <470E0B1A.20507@cisco.com> <1EADBBE4-82AD-4B90-958B-EBB2A09585C6@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ietf@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-03.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org The number of slots taken up by SGs is controlled by how many SGs are chartered and how long the SGs take. Both factors are under the control of the IESG, which has already suggested a maximum of 3 GS to be chartered under the experiment. Assuming that the IESG charters SGs for the minimum period initially (6 months), is tough on extensions, and balances the value of SGs with the available room slots and other factors, the problem seems controllable, particularly since a fair number of WGs are on the verge of concluding. On Thu, 11 Oct 2007, Cullen Jennings wrote: > > Would you see them being above or below BOFs? > > On Oct 11, 2007, at 4:38 AM, Eliot Lear wrote: > > >I have one additional concern about this proposal. If a study group is > >intended to meet at an IETF, it will compete with slot requests both > >from IETF working groups and IRTF research groups. I wouldn't want to > >prohibit f2fs but I would certainly suggest that they come in low on the > >totem pole for space requests. > > > >Eliot > > > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 19:48:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig7ZZ-000422-F2; Thu, 11 Oct 2007 19:36:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig7ZX-00041x-Pi for ietf@ietf.org; Thu, 11 Oct 2007 19:36:07 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig7ZW-0002cV-JQ for ietf@ietf.org; Thu, 11 Oct 2007 19:36:07 -0400 X-IronPort-AV: E=Sophos;i="4.21,261,1188802800"; d="scan'208";a="235188320" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 11 Oct 2007 16:35:56 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9BNZtAw010604; Thu, 11 Oct 2007 16:35:55 -0700 Received: from [192.168.4.2] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l9BNZnZq013309; Thu, 11 Oct 2007 23:35:54 GMT In-Reply-To: References: <470E0B1A.20507@cisco.com> <1EADBBE4-82AD-4B90-958B-EBB2A09585C6@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Thu, 11 Oct 2007 16:35:42 -0700 To: "Bernard Aboba" X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1928; t=1192145756; x=1193009756; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20Comments=20on=20draft-aboba-sg-experiment-03.txt |Sender:=20; bh=EOgfcMUo/eHBILaEK8iRQDgyz++LNJkiG5wMxkNSJ/I=; b=FogI0C6/D0l4uMvZxKXQ0GeYxCw7D3boSth4WUiOQVS0EcscwYVxVaKi0PKiUqkdsrtecrs5 RNiBI8AEkPiGzHq6Fy/RTd3f/eZ5cm76v7RdAS1VgMTagJgSaTRxrTWY; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ietf@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-03.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Sure, I agree with all that but I was wondering how people would view the SG vs BOF issues. I know anything will be a judgement call with tradeoffs - I'm sure we have had occasion where running the BOF was more important than some of the WGs but as for the most part WG get strong precedence over BOFs. I'm wondering if the SGs are going to make it even harder to schedule BOF of if the SGs should expect to get 100% bumped when we have a meeting that wants a few BOFs in one of the fuller areas. Clearly neither of these sounds much fun but given I sometimes have to help make theses scheduling tradeoffs, I would love to have any input from the community on what I should be doing. On Oct 11, 2007, at 4:10 PM, Bernard Aboba wrote: > The number of slots taken up by SGs is controlled by how many SGs are > chartered and how long the SGs take. Both factors are under the > control > of the IESG, which has already suggested a maximum of 3 GS to be > chartered > under the experiment. > > Assuming that the IESG charters SGs for the minimum period > initially (6 > months), is tough on extensions, and balances the value of SGs with > the available room slots and other factors, the problem seems > controllable, particularly since a fair number of WGs are on the > verge of > concluding. > > > > On Thu, 11 Oct 2007, Cullen Jennings wrote: > > > > > Would you see them being above or below BOFs? > > > > On Oct 11, 2007, at 4:38 AM, Eliot Lear wrote: > > > > >I have one additional concern about this proposal. If a study > group is > > >intended to meet at an IETF, it will compete with slot requests > both > > >from IETF working groups and IRTF research groups. I wouldn't > want to > > >prohibit f2fs but I would certainly suggest that they come in > low on the > > >totem pole for space requests. > > > > > >Eliot > > > > > > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 11 23:46:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgBC6-0004La-2p; Thu, 11 Oct 2007 23:28:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgBC5-0004E2-13 for ietf@ietf.org; Thu, 11 Oct 2007 23:28:09 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgBC3-0001IS-4T for ietf@ietf.org; Thu, 11 Oct 2007 23:28:09 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id 4E4F7233C5; Fri, 12 Oct 2007 12:27:58 +0900 (JST) To: brian.e.carpenter@gmail.com In-Reply-To: Your message of "Fri, 12 Oct 2007 08:43:17 +1300" <470E7CD5.3000209@gmail.com> References: <470E7CD5.3000209@gmail.com> X-Mailer: Cue version 0.8 (070521-1856/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20071012032758.4E4F7233C5@coconut.itojun.org> Date: Fri, 12 Oct 2007 12:27:58 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: -0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ietf@ietf.org Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > On 2007-10-11 23:46, Jun-ichiro itojun Hagino wrote: > >> Not viewed from the socket programmer's point of view. > >> Look at how an AF_INET6 socket behaves when given > >> an address like ::FFFF:192.0.2.3 > >> afaik the behavior is then exactly what you describe. > >> Whether the stacks are independent code modules or > >> alternate paths through the same code is irrelevant > >> to the externally observed behavior. > > > > see draft-ietf-v6ops-security-overview-06.txt section 2.2. > > Sure. I absolutely don't like to see ::FFFF/96 on the wire. then we'd have to deprecate SIIT at least. still, you cannot be sure that ::ffff:0:0/96 are not on the wire. itojun _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 01:01:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgCQv-0005TO-Iv; Fri, 12 Oct 2007 00:47:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgCQu-0005TH-KF for ietf@ietf.org; Fri, 12 Oct 2007 00:47:32 -0400 Received: from netcore.fi ([193.94.160.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgCQu-0003fF-14 for ietf@ietf.org; Fri, 12 Oct 2007 00:47:32 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l9C4lPjW016533; Fri, 12 Oct 2007 07:47:25 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l9C4lNGo016530; Fri, 12 Oct 2007 07:47:24 +0300 Date: Fri, 12 Oct 2007 07:47:23 +0300 (EEST) From: Pekka Savola To: Lakshminath Dondeti In-Reply-To: <470E5757.7070802@qualcomm.com> Message-ID: References: <5C4564C6F879D2DF9E4C88DD@p3.JCK.COM> <470E5757.7070802@qualcomm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4530/Thu Oct 11 23:02:20 2007 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.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: John C Klensin , ietf@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Thu, 11 Oct 2007, Lakshminath Dondeti wrote: > Just for the record, if the norm ends up being "Idea --> BoF-1 --> BoF-2 > --> SG --> WG," I would be very disappointed and would chalk that up > under the law of unintended consequences :). I am hoping that "Idea --> SG > --> WG" or "Idea --> BoF1 --> SG --> WG" in that order become the norm (where > SG is involved of course), especially when proponents of new work are people > who may not be regulars at the IETF. One of the reasons for having a BoF is that the BoF proponents need to convince the rest of the IETF that the idea is workable and there's sufficient interest to work on the topic. If there is expectation that no BoF is held between the SG and WG phase, how can we guarantee that the IETF as a whole thinks the charter and the other deliverables the SG worked on are convincing and worth doing? As for the timeslot scheduling, I'd say SGs should have a precedence over IRTF research groups, given that we're talking about IETF meetings, not IRTF meetings. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 01:01:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgCWJ-0005oB-LO; Fri, 12 Oct 2007 00:53:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgCWH-0005lI-Rt for ietf@ietf.org; Fri, 12 Oct 2007 00:53:05 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgCWH-0003pb-BS for ietf@ietf.org; Fri, 12 Oct 2007 00:53:05 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l9C4r3WJ020560 for ; Fri, 12 Oct 2007 00:53:03 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9C4r3lk412734 for ; Thu, 11 Oct 2007 22:53:03 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l9C4r39U024569 for ; Thu, 11 Oct 2007 22:53:03 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l9C4r2c1024558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Oct 2007 22:53:03 -0600 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.14.1/8.12.5) with ESMTP id l9C4r2At010999 for ; Fri, 12 Oct 2007 00:53:02 -0400 Received: (from narten@localhost) by rotala.raleigh.ibm.com (8.14.1/8.14.1/Submit) id l9C4r2gf010992 for ietf@ietf.org; Fri, 12 Oct 2007 00:53:02 -0400 Date: Fri, 12 Oct 2007 00:53:02 -0400 From: Thomas Narten Message-Id: <200710120453.l9C4r2gf010992@rotala.raleigh.ibm.com> To: ietf@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: Weekly posting summary for ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Total of 125 messages in the last 7 days. script run at: Fri Oct 12 00:53:02 EDT 2007 Messages | Bytes | Who --------+------+--------+----------+------------------------ 7.20% | 9 | 7.35% | 57906 | brian.e.carpenter@gmail.com 7.20% | 9 | 7.16% | 56468 | moore@cs.utk.edu 6.40% | 8 | 7.73% | 60955 | dotis@mail-abuse.org 5.60% | 7 | 6.34% | 49943 | ldondeti@qualcomm.com 4.80% | 6 | 4.17% | 32885 | jari.arkko@piuha.net 4.00% | 5 | 4.52% | 35623 | ekr@networkresonance.com 3.20% | 4 | 4.82% | 38036 | spencer@mcsr-labs.org 4.00% | 5 | 3.85% | 30320 | john-ietf@jck.com 4.00% | 5 | 3.75% | 29534 | aboba@internaut.com 3.20% | 4 | 3.12% | 24628 | nobody@xyzzy.claranet.de 2.40% | 3 | 3.67% | 28959 | dromasca@avaya.com 3.20% | 4 | 2.57% | 20222 | lear@cisco.com 3.20% | 4 | 2.52% | 19848 | pasi.eronen@nokia.com 3.20% | 4 | 2.35% | 18518 | hartmans-ietf@mit.edu 2.40% | 3 | 2.60% | 20519 | michel@arneill-py.sacramento.ca.us 2.40% | 3 | 2.24% | 17629 | olaf@nlnetlabs.nl 1.60% | 2 | 2.49% | 19664 | alexey.melnikov@isode.com 1.60% | 2 | 1.81% | 14307 | dcrocker@bbiw.net 1.60% | 2 | 1.75% | 13794 | rdroms@cisco.com 1.60% | 2 | 1.66% | 13062 | narten@us.ibm.com 1.60% | 2 | 1.53% | 12086 | jason_livingood@cable.comcast.com 1.60% | 2 | 1.51% | 11941 | tli@cisco.com 1.60% | 2 | 1.43% | 11273 | fluffy@cisco.com 1.60% | 2 | 1.36% | 10744 | iljitsch@muada.com 1.60% | 2 | 1.21% | 9544 | dot@dotat.at 1.60% | 2 | 0.97% | 7617 | itojun@itojun.org 0.80% | 1 | 1.56% | 12322 | g.e.montenegro@hotmail.com 0.80% | 1 | 0.89% | 7007 | ole@cisco.com 0.80% | 1 | 0.84% | 6654 | loa@pi.se 0.80% | 1 | 0.84% | 6589 | sisyphus@dial.pipex.com 0.80% | 1 | 0.80% | 6320 | pete@codalogic.com 0.80% | 1 | 0.76% | 5998 | bernard_aboba@hotmail.com 0.80% | 1 | 0.74% | 5844 | dwm@xpasc.com 0.80% | 1 | 0.73% | 5726 | mrc@cac.washington.edu 0.80% | 1 | 0.71% | 5614 | black_david@emc.com 0.80% | 1 | 0.69% | 5440 | stephen@sprunk.org 0.80% | 1 | 0.66% | 5231 | leiba@watson.ibm.com 0.80% | 1 | 0.66% | 5206 | mark_andrews@isc.org 0.80% | 1 | 0.65% | 5137 | msa@moth.iki.fi 0.80% | 1 | 0.65% | 5126 | paul.hoffman@vpnc.org 0.80% | 1 | 0.62% | 4896 | dhc2@dcrocker.net 0.80% | 1 | 0.58% | 4595 | scott@kitterman.com 0.80% | 1 | 0.54% | 4253 | drc@virtualized.org 0.80% | 1 | 0.54% | 4231 | bortzmeyer@nic.fr 0.80% | 1 | 0.54% | 4224 | chair@ietf.org 0.80% | 1 | 0.53% | 4191 | kre@munnari.oz.au 0.80% | 1 | 0.52% | 4124 | raeburn@mit.edu 0.80% | 1 | 0.46% | 3610 | iesg@ietf.org --------+------+--------+----------+------------------------ 100.00% | 125 |100.00% | 788363 | Total _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 01:01:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgCQv-0005TO-Iv; Fri, 12 Oct 2007 00:47:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgCQu-0005TH-KF for ietf@ietf.org; Fri, 12 Oct 2007 00:47:32 -0400 Received: from netcore.fi ([193.94.160.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgCQu-0003fF-14 for ietf@ietf.org; Fri, 12 Oct 2007 00:47:32 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l9C4lPjW016533; Fri, 12 Oct 2007 07:47:25 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l9C4lNGo016530; Fri, 12 Oct 2007 07:47:24 +0300 Date: Fri, 12 Oct 2007 07:47:23 +0300 (EEST) From: Pekka Savola To: Lakshminath Dondeti In-Reply-To: <470E5757.7070802@qualcomm.com> Message-ID: References: <5C4564C6F879D2DF9E4C88DD@p3.JCK.COM> <470E5757.7070802@qualcomm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4530/Thu Oct 11 23:02:20 2007 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.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: John C Klensin , ietf@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Thu, 11 Oct 2007, Lakshminath Dondeti wrote: > Just for the record, if the norm ends up being "Idea --> BoF-1 --> BoF-2 > --> SG --> WG," I would be very disappointed and would chalk that up > under the law of unintended consequences :). I am hoping that "Idea --> SG > --> WG" or "Idea --> BoF1 --> SG --> WG" in that order become the norm (where > SG is involved of course), especially when proponents of new work are people > who may not be regulars at the IETF. One of the reasons for having a BoF is that the BoF proponents need to convince the rest of the IETF that the idea is workable and there's sufficient interest to work on the topic. If there is expectation that no BoF is held between the SG and WG phase, how can we guarantee that the IETF as a whole thinks the charter and the other deliverables the SG worked on are convincing and worth doing? As for the timeslot scheduling, I'd say SGs should have a precedence over IRTF research groups, given that we're talking about IETF meetings, not IRTF meetings. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 01:01:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgCWJ-0005oB-LO; Fri, 12 Oct 2007 00:53:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgCWH-0005lI-Rt for ietf@ietf.org; Fri, 12 Oct 2007 00:53:05 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgCWH-0003pb-BS for ietf@ietf.org; Fri, 12 Oct 2007 00:53:05 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l9C4r3WJ020560 for ; Fri, 12 Oct 2007 00:53:03 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9C4r3lk412734 for ; Thu, 11 Oct 2007 22:53:03 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l9C4r39U024569 for ; Thu, 11 Oct 2007 22:53:03 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l9C4r2c1024558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Oct 2007 22:53:03 -0600 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.14.1/8.12.5) with ESMTP id l9C4r2At010999 for ; Fri, 12 Oct 2007 00:53:02 -0400 Received: (from narten@localhost) by rotala.raleigh.ibm.com (8.14.1/8.14.1/Submit) id l9C4r2gf010992 for ietf@ietf.org; Fri, 12 Oct 2007 00:53:02 -0400 Date: Fri, 12 Oct 2007 00:53:02 -0400 From: Thomas Narten Message-Id: <200710120453.l9C4r2gf010992@rotala.raleigh.ibm.com> To: ietf@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: Weekly posting summary for ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Total of 125 messages in the last 7 days. script run at: Fri Oct 12 00:53:02 EDT 2007 Messages | Bytes | Who --------+------+--------+----------+------------------------ 7.20% | 9 | 7.35% | 57906 | brian.e.carpenter@gmail.com 7.20% | 9 | 7.16% | 56468 | moore@cs.utk.edu 6.40% | 8 | 7.73% | 60955 | dotis@mail-abuse.org 5.60% | 7 | 6.34% | 49943 | ldondeti@qualcomm.com 4.80% | 6 | 4.17% | 32885 | jari.arkko@piuha.net 4.00% | 5 | 4.52% | 35623 | ekr@networkresonance.com 3.20% | 4 | 4.82% | 38036 | spencer@mcsr-labs.org 4.00% | 5 | 3.85% | 30320 | john-ietf@jck.com 4.00% | 5 | 3.75% | 29534 | aboba@internaut.com 3.20% | 4 | 3.12% | 24628 | nobody@xyzzy.claranet.de 2.40% | 3 | 3.67% | 28959 | dromasca@avaya.com 3.20% | 4 | 2.57% | 20222 | lear@cisco.com 3.20% | 4 | 2.52% | 19848 | pasi.eronen@nokia.com 3.20% | 4 | 2.35% | 18518 | hartmans-ietf@mit.edu 2.40% | 3 | 2.60% | 20519 | michel@arneill-py.sacramento.ca.us 2.40% | 3 | 2.24% | 17629 | olaf@nlnetlabs.nl 1.60% | 2 | 2.49% | 19664 | alexey.melnikov@isode.com 1.60% | 2 | 1.81% | 14307 | dcrocker@bbiw.net 1.60% | 2 | 1.75% | 13794 | rdroms@cisco.com 1.60% | 2 | 1.66% | 13062 | narten@us.ibm.com 1.60% | 2 | 1.53% | 12086 | jason_livingood@cable.comcast.com 1.60% | 2 | 1.51% | 11941 | tli@cisco.com 1.60% | 2 | 1.43% | 11273 | fluffy@cisco.com 1.60% | 2 | 1.36% | 10744 | iljitsch@muada.com 1.60% | 2 | 1.21% | 9544 | dot@dotat.at 1.60% | 2 | 0.97% | 7617 | itojun@itojun.org 0.80% | 1 | 1.56% | 12322 | g.e.montenegro@hotmail.com 0.80% | 1 | 0.89% | 7007 | ole@cisco.com 0.80% | 1 | 0.84% | 6654 | loa@pi.se 0.80% | 1 | 0.84% | 6589 | sisyphus@dial.pipex.com 0.80% | 1 | 0.80% | 6320 | pete@codalogic.com 0.80% | 1 | 0.76% | 5998 | bernard_aboba@hotmail.com 0.80% | 1 | 0.74% | 5844 | dwm@xpasc.com 0.80% | 1 | 0.73% | 5726 | mrc@cac.washington.edu 0.80% | 1 | 0.71% | 5614 | black_david@emc.com 0.80% | 1 | 0.69% | 5440 | stephen@sprunk.org 0.80% | 1 | 0.66% | 5231 | leiba@watson.ibm.com 0.80% | 1 | 0.66% | 5206 | mark_andrews@isc.org 0.80% | 1 | 0.65% | 5137 | msa@moth.iki.fi 0.80% | 1 | 0.65% | 5126 | paul.hoffman@vpnc.org 0.80% | 1 | 0.62% | 4896 | dhc2@dcrocker.net 0.80% | 1 | 0.58% | 4595 | scott@kitterman.com 0.80% | 1 | 0.54% | 4253 | drc@virtualized.org 0.80% | 1 | 0.54% | 4231 | bortzmeyer@nic.fr 0.80% | 1 | 0.54% | 4224 | chair@ietf.org 0.80% | 1 | 0.53% | 4191 | kre@munnari.oz.au 0.80% | 1 | 0.52% | 4124 | raeburn@mit.edu 0.80% | 1 | 0.46% | 3610 | iesg@ietf.org --------+------+--------+----------+------------------------ 100.00% | 125 |100.00% | 788363 | Total _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 01:43:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgD8N-000795-7e; Fri, 12 Oct 2007 01:32:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgD8L-0006tc-BL for ietf@ietf.org; Fri, 12 Oct 2007 01:32:25 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgD8A-0004pp-33 for ietf@ietf.org; Fri, 12 Oct 2007 01:32:20 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9C5VqML004889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 Oct 2007 22:31:52 -0700 Received: from [10.50.65.47] (qconnect-10-50-65-47.qualcomm.com [10.50.65.47]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9C5Vppr021082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Oct 2007 22:31:51 -0700 Message-ID: <470F06CD.6070206@qualcomm.com> Date: Thu, 11 Oct 2007 22:31:57 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pekka Savola References: <5C4564C6F879D2DF9E4C88DD@p3.JCK.COM> <470E5757.7070802@qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: John C Klensin , ietf@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-02 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 10/11/2007 9:47 PM, Pekka Savola wrote: > On Thu, 11 Oct 2007, Lakshminath Dondeti wrote: >> Just for the record, if the norm ends up being "Idea --> BoF-1 --> >> BoF-2 --> SG --> WG," I would be very disappointed and would chalk >> that up under the law of unintended consequences :). I am hoping that >> "Idea --> SG --> WG" or "Idea --> BoF1 --> SG --> WG" in that order >> become the norm (where SG is involved of course), especially when >> proponents of new work are people who may not be regulars at the IETF. > > One of the reasons for having a BoF is that the BoF proponents need to > convince the rest of the IETF that the idea is workable and there's > sufficient interest to work on the topic. > > If there is expectation that no BoF is held between the SG and WG phase, > how can we guarantee that the IETF as a whole thinks the charter and the > other deliverables the SG worked on are convincing and worth doing? Hi Pekka, Section 2.3 of 2418 would apply. regards, Lakshminath > > As for the timeslot scheduling, I'd say SGs should have a precedence > over IRTF research groups, given that we're talking about IETF meetings, > not IRTF meetings. > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 02:11:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgDXs-0006iG-89; Fri, 12 Oct 2007 01:58:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgDXr-0006iB-9U for ietf@ietf.org; Fri, 12 Oct 2007 01:58:47 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgDXr-0005dM-1T for ietf@ietf.org; Fri, 12 Oct 2007 01:58:47 -0400 X-IronPort-AV: E=Sophos;i="4.21,264,1188792000"; d="scan'208";a="134740152" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 12 Oct 2007 01:58:46 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9C5wkb8009124; Fri, 12 Oct 2007 01:58:46 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9C5wkrj026532; Fri, 12 Oct 2007 05:58:46 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 01:58:46 -0400 Received: from [192.168.0.110] ([10.82.232.208]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 01:58:46 -0400 In-Reply-To: <470E7D97.7050503@gmail.com> References: <46EAE465.8070104@dcrocker.net> <4707ECB0.6020302@gmail.com> <26E67D75-E5A0-4142-AC29-7CB0C24FFBD0@cisco.com> <470BE18F.3070105@dcrocker.net> <200710101331.l9ADV4ph013995@localhost.localdomain> <470CDEF4.5030805@bbiw.net> <470D39E5.5060807@gmail.com> <470E3C29.2070006@bbiw.net> <470E7D97.7050503@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Date: Thu, 11 Oct 2007 22:58:35 -0700 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Oct 2007 05:58:46.0146 (UTC) FILETIME=[F3963620:01C80C94] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15478.002 X-TM-AS-Result: No--9.763300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=402; t=1192168726; x=1193032726; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20Call=20for=20action=20vs.=20lost=20opportunity=20(Was =3A=20Re=3A=20Renumbering) |Sender:=20 |To:=20Brian=20E=20Carpenter=20; bh=52D8MttCYv10D04u5bkXqKIJXEJA9k85RaRmhYRWVU0=; b=HVtB+vM/w6CQT7YBJRBsEAycEikN1RMxfhsh7c2pOwnXwR1u3hQAB4LX/SmuSHZp0JsrekZK 3rMm58HC/sjsfqQgswOFn9reVwVcS+FaRviyyOFBkFalk293s05p7klS; Authentication-Results: rtp-dkim-1; header.From=tli@cisco.com; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Dave Crocker , IETF-Discussion Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 11, 2007, at 12:46 PM, Brian E Carpenter wrote: > I can't possibly disagree with that, but my interest is in getting > the implemented code deployed before the IPv4 clock winds down. The IPv4 clock will wind down right after the last FORTRAN compiler is decomissioned. Wouldn't it make more sense to put the effort into morphing v6 into something that *IS* attractive? Tony _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 02:23:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgDmd-0007zz-RB; Fri, 12 Oct 2007 02:14:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgDmd-0007zt-3S for ietf@ietf.org; Fri, 12 Oct 2007 02:14:03 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgDmc-0005yy-Sg for ietf@ietf.org; Fri, 12 Oct 2007 02:14:03 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id E84DA1EE252; Fri, 12 Oct 2007 02:14:01 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsxAOtRIrvkf; Fri, 12 Oct 2007 02:13:59 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id E1FBB1EE254; Fri, 12 Oct 2007 02:13:58 -0400 (EDT) Message-ID: <470F10A6.6040909@cs.utk.edu> Date: Fri, 12 Oct 2007 02:13:58 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Tony Li References: <46EAE465.8070104@dcrocker.net> <4707ECB0.6020302@gmail.com> <26E67D75-E5A0-4142-AC29-7CB0C24FFBD0@cisco.com> <470BE18F.3070105@dcrocker.net> <200710101331.l9ADV4ph013995@localhost.localdomain> <470CDEF4.5030805@bbiw.net> <470D39E5.5060807@gmail.com> <470E3C29.2070006@bbiw.net> <470E7D97.7050503@gmail.com> In-Reply-To: X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: IETF-Discussion , Dave Crocker Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > The IPv4 clock will wind down right after the last FORTRAN compiler is > decomissioned. actually it looks like FORTRAN is going to outlast IPv4 by several years. > Wouldn't it make more sense to put the effort into morphing v6 into > something that *IS* attractive? perhaps, though there's precious little time left to do that, and still a lot of denial to overcome. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 03:31:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgEjL-0001Fv-VO; Fri, 12 Oct 2007 03:14:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgEjK-0001FT-Rh; Fri, 12 Oct 2007 03:14:42 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgEjK-0007ij-G0; Fri, 12 Oct 2007 03:14:42 -0400 X-IronPort-AV: E=Sophos;i="4.21,264,1188770400"; d="scan'208";a="155599393" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2007 09:14:42 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9C7Efh1026232; Fri, 12 Oct 2007 09:14:41 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp784.cisco.com [10.61.67.16]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9C7EcSO004567; Fri, 12 Oct 2007 07:14:38 GMT Message-ID: <470F1EE0.6080105@cisco.com> Date: Fri, 12 Oct 2007 09:14:40 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Cullen Jennings References: <470E0B1A.20507@cisco.com> <1EADBBE4-82AD-4B90-958B-EBB2A09585C6@cisco.com> In-Reply-To: <1EADBBE4-82AD-4B90-958B-EBB2A09585C6@cisco.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=178; t=1192173281; x=1193037281; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Comments=20on=20draft-aboba-sg-experiment-03.txt |Sender:=20; bh=jRvr+Nf67ZNFChSC7MEZCr36orMjA6WAFg42071I35g=; b=jySH8TeVKhO+BPJzfEycEPNPQgmaa/p5YwafnytdszozzBzrfZj6A83effJxr2SrASkzafRO UTqK5wDFFOX/GGPhBfL/y2gKU733/agYB4Jjn7qIH93BoIgHgnJXg/vu; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: IESG , Aaron Falk , ietf@ietf.org, Bernard Aboba Subject: Re: Comments on draft-aboba-sg-experiment-03.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Cullen Jennings wrote: > Would you see [SG meetings] being above or below BOFs? Well now that's the question, isn't it? I'd be curious as to what Bernard thinks. Eliot _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 05:23:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgGWz-0000Y2-St; Fri, 12 Oct 2007 05:10:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgGWy-0000Ut-TP for ietf@ietf.org; Fri, 12 Oct 2007 05:10:04 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgGWy-0004Dr-Bj for ietf@ietf.org; Fri, 12 Oct 2007 05:10:04 -0400 Received: from [163.117.139.34] ([163.117.139.34]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l9C96Mm8028959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Oct 2007 11:06:57 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <200710101331.l9ADV4ph013995@localhost.localdomain> References: <46EAE465.8070104@dcrocker.net> <4707ECB0.6020302@gmail.com> <26E67D75-E5A0-4142-AC29-7CB0C24FFBD0@cisco.com> <470BE18F.3070105@dcrocker.net> <200710101331.l9ADV4ph013995@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5C9571CF-D76D-436C-A8B6-EF42CB0812DC@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Thu, 11 Oct 2007 19:43:30 +0200 To: Thomas Narten X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, score=-0.8 required=3.5 tests=AWL,BAYES_00, ILJQX_SUBJ_COMMA,ILJQX_SUBJ_NUMINWORD autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 1.8 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: dcrocker@bbiw.net, IETF-Discussion Subject: IPv4.6, was: Call for action vs. lost opportunity X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 10-okt-2007, at 15:31, Thomas Narten wrote: > If there was a magic "trivial" transition/upgrade strategy, we would > have done it years ago. How about this: we magically go back 10 years in time and define "IPv4.6" which is the first 32 bits of the IPv6 address in the IPv4 address fields and the other 96 bits in a new header that sits between the IPv4 header and the upper layer protocol (TCP/UDP/etc). IPv4 stacks are updated to copy back the extra header with the lower 96 bits whenever sending packets in reponse to ones with those 96 bits in them. I'm pretty sure we'd still have issues with unupgraded TCP stacks and firewalls, but just implementing the simple copyback mechanism and adjusting firewalls accordingly would be a much simpler way for existing IPv4 users to be able to talk to IPv6 users than adding IPv6 to their networks. Applications on the IPv4 host that are unaware of the fact that they're talking to an IPv6 host would still have NAT issues, but it would also be possible to run applications that know about the IPv6 address of the correspondent so the communication would be end-to-end clean. (Ok there would have to be some extra bit shuffling to avoid using up the IPv6 address space as fast as the IPv4 space but that's just details. Maybe copy bits 4 - 31 and set bits 0 - 3 to 1111 in the IPv4 address if they are 0010 in the IPv6 address.) _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 07:25:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgIMH-0001QW-R6; Fri, 12 Oct 2007 07:07:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgIMG-0001Of-62 for ietf@ietf.org; Fri, 12 Oct 2007 07:07:08 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgIMC-0007hY-P5 for ietf@ietf.org; Fri, 12 Oct 2007 07:07:05 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id 6FF5D233C5; Fri, 12 Oct 2007 20:06:39 +0900 (JST) To: tli@cisco.com In-Reply-To: Your message of "Thu, 11 Oct 2007 22:58:35 -0700" References: X-Mailer: Cue version 0.8 (070521-1856/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20071012110639.6FF5D233C5@coconut.itojun.org> Date: Fri, 12 Oct 2007 20:06:39 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: -0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ietf@ietf.org Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > The IPv4 clock will wind down right after the last FORTRAN compiler is > decomissioned. Wouldn't it make more sense to put the effort into > morphing v6 into something that *IS* attractive? hope you can do that in time... (i mean, not just for the States but for the entire planet) for me, IPv6 itself is attractive enough (that's why i'm putting so much time on it). if it can lose some of the extra meat which makes it a little bit more complex than it should be, it would be super. itojun _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 08:31:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgJNX-0001Bd-7R; Fri, 12 Oct 2007 08:12:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgHxu-0004f3-Ir for ietf@ietf.org; Fri, 12 Oct 2007 06:41:58 -0400 Received: from smtp1.us4.outblaze.com ([205.158.62.78]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IgHxj-0007Sm-P7 for ietf@ietf.org; Fri, 12 Oct 2007 06:41:48 -0400 Received: (qmail 15781 invoked from network); 12 Oct 2007 10:23:58 -0000 Received: from unknown (HELO ?192.168.3.65?) (jcurran:mail.com?mail.com@69.255.34.88) by smtp1.us4.outblaze.com with SMTP; 12 Oct 2007 10:23:58 -0000 Mime-Version: 1.0 Message-Id: Date: Fri, 12 Oct 2007 06:23:57 -0400 To: ietf@ietf.org From: John Curran Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Fri, 12 Oct 2007 08:12:29 -0400 Subject: Re: IPv4 to IPv6 transition X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Folks - There is an objection by Dean Anderson to the accuracy of statements posted to the IETF list by Stephen Sprunk on October 3 regarding ARIN's obligations to legacy IP address holders. While ARIN hasn't obtained a formal legal opinion on ARIN's obligations to legacy IP assignments, ARIN's counsel responded to questions about ARIN's potential obligations in providing registration services to legacy IP space holders at the the last ARIN member meeting. It is the analysis of these comments in Stephen Sprunk's posting that is challenged by Dean Anderson. The full Transcript of the legacy panel is at http://www.arin.net/meetings/minutes/ARIN_XIX/ppm1_transcript.html#anchor_13 Dean Anderson has a produced an analysis of the statements at http://www.av8.net/IETF-watch/People/StephenSprunk/ARIN-legal-comments.html It is in ARIN's interest to insure informed discussion of the topic, and while I disagree with Dean's assessment, I agreed to send this message to the list so that the community can understand that there is a variety of interpretations of the statements that were made. /John _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 10:42:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgLZc-0001Na-Nh; Fri, 12 Oct 2007 10:33:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgLZb-0001Bx-6p for ietf@ietf.org; Fri, 12 Oct 2007 10:33:07 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgLZW-0001Dx-OA for ietf@ietf.org; Fri, 12 Oct 2007 10:33:03 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9CEWvCV017366 for ; Fri, 12 Oct 2007 07:32:57 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9CEWtE0002081 for ; Fri, 12 Oct 2007 07:32:56 -0700 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 Content-Transfer-Encoding: 7bit Date: Fri, 12 Oct 2007 07:32:45 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Travel Considerations Thread-Index: AcgM3MEZgv2eBnV6QqmCWgsharAqGA== From: "Eric Burger" To: x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: Travel Considerations X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Here is an interesting optimization problem: it turns out the most polluting part of a conference is people taking jets to fly to the conference. Minimize that and the planet wins. Favors hub cities over spokes, like San Diego or Prague, where you "can't get there from here", no matter where "here" is. See http://www.sciencemag.org/cgi/reprint/318/5847/36.pdf Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 11:02:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgLzM-00004r-Fn; Fri, 12 Oct 2007 10:59:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgLzL-0008WR-Bx for ietf@ietf.org; Fri, 12 Oct 2007 10:59:43 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgLzL-0003sV-2W for ietf@ietf.org; Fri, 12 Oct 2007 10:59:43 -0400 X-IronPort-AV: E=Sophos;i="4.21,267,1188770400"; d="scan'208";a="155660010" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2007 16:59:42 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9CExg6M013941; Fri, 12 Oct 2007 16:59:42 +0200 Received: from stewart-bryants-computer.local (ams3-vpn-dhcp4571.cisco.com [10.61.81.218]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9CExfSO007490; Fri, 12 Oct 2007 14:59:42 GMT Message-ID: <470F8BDE.8050700@cisco.com> Date: Fri, 12 Oct 2007 15:59:42 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Eric Burger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=164; t=1192201182; x=1193065182; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20Travel=20Considerations |Sender:=20; bh=/bXq8rk1711MMxqtdWrJxEaJuttKAOBGGzsOVIOIsTg=; b=YZ1Fn9sG5trTMn5Nsjyug47nQ7bL0PfeFOQoK3nh/5vCCO7PEwizT6vJne5OnYTLSeKfYKQ7 a3k1QjgK0XmMAw2X1VY4xqWoQgQKYJwS2P8bj6UPtet7VV2dpKT2x/Iy; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ietf@ietf.org Subject: Re: Travel Considerations X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stbryant@cisco.com List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Eric Burger wrote: > > See http://www.sciencemag.org/cgi/reprint/318/5847/36.pdf > > Which seems to be only available to those prepared to pay. Stewart _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 11:02:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgLtX-0002g5-0P; Fri, 12 Oct 2007 10:53:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgLtV-0002c9-Rc for ietf@ietf.org; Fri, 12 Oct 2007 10:53:41 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgLtK-0000KW-ON for ietf@ietf.org; Fri, 12 Oct 2007 10:53:36 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 675148732E; Fri, 12 Oct 2007 10:53:00 -0400 (EDT) To: ietf@ietf.org Message-Id: <20071012145300.675148732E@mercury.lcs.mit.edu> Date: Fri, 12 Oct 2007 10:53:00 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: jnc@mercury.lcs.mit.edu Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > From: Keith Moore >> Wouldn't it make more sense to put the effort into morphing v6 into >> something that *IS* attractive? > there's precious little time left to do that Umm, Keith, we're *already* 'out' (in some sense) of IPv4 space, and have been for a decade or more. Why do you think there are all those blasted NAT boxes out there? So the future just holds a *different* kind of 'running out of IPv4' addresses, which, when it happens, the world will deal with in what seems at the time to be the most cost-effective way of dealing with the problem, even if it's ugly (q.v. NAT). Noel _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 11:23:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgMD4-0005ji-SG; Fri, 12 Oct 2007 11:13:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgMD4-0005jc-5B for ietf@ietf.org; Fri, 12 Oct 2007 11:13:54 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgMD3-0004Qi-Q7 for ietf@ietf.org; Fri, 12 Oct 2007 11:13:54 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 6A39E1EE2DB; Fri, 12 Oct 2007 11:13:53 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbqxCzXeiyzv; Fri, 12 Oct 2007 11:13:50 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id E41591EE2FC; Fri, 12 Oct 2007 11:13:49 -0400 (EDT) Message-ID: <470F8F2D.2070702@cs.utk.edu> Date: Fri, 12 Oct 2007 11:13:49 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Noel Chiappa References: <20071012145300.675148732E@mercury.lcs.mit.edu> In-Reply-To: <20071012145300.675148732E@mercury.lcs.mit.edu> X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ietf@ietf.org Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Noel Chiappa wrote: > > From: Keith Moore > > >> Wouldn't it make more sense to put the effort into morphing v6 into > >> something that *IS* attractive? > > > there's precious little time left to do that > > Umm, Keith, we're *already* 'out' (in some sense) of IPv4 space, and have > been for a decade or more. > Given that addresses are still available for the time being, I'm not sure what sense you mean there. (of course, without NAT we would have reached this point years ago.) > Why do you think there are all those blasted NAT boxes out there? > Different reasons. A big one is because the commodity IPv4 connection is a /32, and it turns out that lots of customers have reason to hook up more than one host. Another one is that pretty much everyone uses Windows, which has a long history of (deliberately introduced) insecurity, and people have been duped into thinking that private networks and NATs offer substantial protection. Groupthink is also a big factor, I suspect. People bought NATs because their friends did. Also, NATs spread at a time when most widely-used Internet apps were client-server. > So the future just holds a *different* kind of 'running out of IPv4'addresses, which, when it happens, the world will deal with in what seems at the time to be the most cost-effective way of dealing with the problem, even if it's ugly (q.v. NAT) > Why do you believe that the world chooses the most cost-effective solution? As far as I can tell the market mostly engages in hill-climbing, which rarely produces an optimal result. Now if instead you had said people would do whatever seemed to be easiest, without much regard to the long-term cost, I'd probably agree with you. Maybe I should buy stock in application hosting firms that "own" substantial chunks of IPv4 space. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 11:47:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgMXL-0003SD-Kh; Fri, 12 Oct 2007 11:34:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgMXK-0003QV-KQ for ietf@ietf.org; Fri, 12 Oct 2007 11:34:50 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgMXH-0005CH-V8 for ietf@ietf.org; Fri, 12 Oct 2007 11:34:48 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9CFYf6B003027; Fri, 12 Oct 2007 08:34:41 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9CFYdeK014646; Fri, 12 Oct 2007 08:34:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Fri, 12 Oct 2007 08:34:39 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Travel Considerations Thread-Index: AcgM4Ip+y9ZSyIT0TMGS0jO2WTrgrgABNyI6 From: "Eric Burger" To: x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ietf@ietf.org Subject: Re: Travel Considerations X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Whoops. Didn't realize it. I'll see if I can get permission to post it. Summary is the vast percentage of emissions related to conferences is key fuel. -- Sent from my wireless e-mail device. Sorry if terse. We all need lemonade: see for what lemonade is. ----- Original Message ----- From: Stewart Bryant To: Eric Burger Cc: ietf@ietf.org Sent: Fri Oct 12 07:59:42 2007 Subject: Re: Travel Considerations Eric Burger wrote: > > See http://www.sciencemag.org/cgi/reprint/318/5847/36.pdf > > Which seems to be only available to those prepared to pay. Stewart Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 11:55:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgMnR-0001fo-RV; Fri, 12 Oct 2007 11:51:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgMnP-0001fd-Tl for ietf@ietf.org; Fri, 12 Oct 2007 11:51:27 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgMnP-0005og-IH for ietf@ietf.org; Fri, 12 Oct 2007 11:51:27 -0400 X-IronPort-AV: E=Sophos;i="4.21,267,1188802800"; d="scan'208";a="534394589" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 12 Oct 2007 08:51:27 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l9CFpQqv002263; Fri, 12 Oct 2007 08:51:26 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9CFpQlD018630; Fri, 12 Oct 2007 15:51:26 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 08:51:26 -0700 Received: from [192.168.0.110] ([10.21.91.136]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 08:51:25 -0700 In-Reply-To: <470F8F2D.2070702@cs.utk.edu> References: <20071012145300.675148732E@mercury.lcs.mit.edu> <470F8F2D.2070702@cs.utk.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Date: Fri, 12 Oct 2007 08:51:13 -0700 To: Keith Moore X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Oct 2007 15:51:26.0009 (UTC) FILETIME=[BEEAB290:01C80CE7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1030; t=1192204286; x=1193068286; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20Call=20for=20action=20vs.=20lost=20opportunity=20(Was =3A=20Re=3A=20Renumbering) |Sender:=20; bh=OHlK7qPrI24r3IashAOjJg2u5WEgpkfmE7jspbRx2GU=; b=GEsfdrKxfqb2VrJ6OV6Ye8bRmypKe3ixaE8bqDXRCGAgPuk5hBB/OzKOsRHmwnCxl/r+EzFM BNMEaJJcKcCfm1dj7WRSoyrb4XXVoMdbiizIADPwcR2BTgKwSlZy6Qyu; Authentication-Results: sj-dkim-4; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Noel Chiappa , ietf@ietf.org Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 12, 2007, at 8:13 AM, Keith Moore wrote: >>> there's precious little time left to do that >> >> Umm, Keith, we're *already* 'out' (in some sense) of IPv4 space, >> and have >> been for a decade or more. >> > Given that addresses are still available for the time being, I'm not > sure what sense you mean there. The only thing that's about to change is that the cost of v4 addresses will go up slightly. The black market in addresses is now inevitable. As demand climbs, more people with assigned addresses will switch to NAT and put their prefixes on the market, providing the 'supply' side of the equation. This situation will persist, with the 'demand' side slowly driving prices up. Only when v6 becomes sufficiently attractive will it begin to be possible to deploy v6 only sites and reduce demand. So, until both content providers and 'eyeballs' see some obvious and compelling advantage to deploying v6, we have a game of chicken, which no one will win. Tony _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 14:30:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgOyB-0002WK-Q3; Fri, 12 Oct 2007 14:10:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgOyA-0002WD-Jz for ietf@ietf.org; Fri, 12 Oct 2007 14:10:42 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgOyA-00022B-9L for ietf@ietf.org; Fri, 12 Oct 2007 14:10:42 -0400 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 8551683; Fri, 12 Oct 2007 14:10:41 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9D438F76-1683-4EF7-B70A-B21341DB9067@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Date: Fri, 12 Oct 2007 14:10:35 -0400 To: Eric Burger X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ietf@ietf.org Subject: Re: Travel Considerations X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 12, 2007, at 10:32 AM, Eric Burger wrote: > Here is an interesting optimization problem: it turns out the most > polluting part of a conference is people taking jets to fly to the > conference. Minimize that and the planet wins. Favors hub cities > over > spokes, like San Diego or Prague, where you "can't get there from > here", > no matter where "here" is. > > See http://www.sciencemag.org/cgi/reprint/318/5847/36.pdf If the Internet really uses 9.4% of total US electricity consumption, as is claimed here, http://uclue.com/index.php?xq=724 then the problem is much worse than travel to IETF meetings. Regards Marshall > > Notice: This email message, together with any attachments, may > contain information of BEA Systems, Inc., its subsidiaries > and affiliated entities, that may be confidential, proprietary, > copyrighted and/or legally privileged, and is intended solely for > the use of the individual or entity named in this message. If you > are not the intended recipient, and have received this message in > error, please immediately return this by email and then delete it. > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 14:36:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgPHh-0004Bq-Iw; Fri, 12 Oct 2007 14:30:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgPHg-0004BS-Is for ietf@ietf.org; Fri, 12 Oct 2007 14:30:52 -0400 Received: from colo.trepanning.net ([69.55.226.174] helo=mail1.trepanning.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgPHX-0007yc-1A for ietf@ietf.org; Fri, 12 Oct 2007 14:30:52 -0400 Received: from www.trepanning.net (localhost [127.0.0.1]) by mail1.trepanning.net (Postfix) with ESMTP id 740A51FA6101; Fri, 12 Oct 2007 11:30:28 -0700 (PDT) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 12 Oct 2007 11:30:28 -0700 (PDT) Message-ID: <28109.216.31.249.246.1192213828.squirrel@www.trepanning.net> In-Reply-To: References: Date: Fri, 12 Oct 2007 11:30:28 -0700 (PDT) From: "Dan Harkins" To: "Eric Burger" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ietf@ietf.org Subject: Re: Travel Considerations X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org You're assuming that if 1000 people decide not to fly to Prague some weekend that the number of planes burning jet fuel to fly there will be different. I don't think so. Maybe you can start a "Boycott Prague The Spoke City" campaign which, if wildly successful, will reduce demand to fly there by some discernable amount and thereby reduce the number of planes flying there and the amoun= t of jet fuel they would've burned. Well, as long as the planes that aren't flying to Prague aren't used to fly to Heathrow or Frankfurt or some othe= r hub city. Also doubtful. I do not intend on making ietf-discuss into a forum for discussing the pluses and minuses resulting from a degree centigrade temperature change but let me just say that "the planet wins" is a somewhat dubious statement. Dan. On Fri, October 12, 2007 7:32 am, Eric Burger wrote: > Here is an interesting optimization problem: it turns out the most > polluting part of a conference is people taking jets to fly to the > conference. Minimize that and the planet wins. Favors hub cities over > spokes, like San Diego or Prague, where you "can't get there from here"= , > no matter where "here" is. > > See http://www.sciencemag.org/cgi/reprint/318/5847/36.pdf > > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individua= l > or entity named in this message. If you are not the intended recipient, > and have received this message in error, please immediately return this= by > email and then delete it. > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 14:59:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgPZy-0000Jf-Nm; Fri, 12 Oct 2007 14:49:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgPZw-0000JJ-Ty for ietf@ietf.org; Fri, 12 Oct 2007 14:49:44 -0400 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgPZw-00031D-Eh for ietf@ietf.org; Fri, 12 Oct 2007 14:49:44 -0400 Received: from [192.168.0.2] (ppp-67-124-88-239.dsl.pltn13.pacbell.net [67.124.88.239]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l9CInEaa023461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Oct 2007 11:49:15 -0700 Message-ID: <470FC1A8.9030501@dcrocker.net> Date: Fri, 12 Oct 2007 11:49:12 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eric Burger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ietf@ietf.org Subject: Re: Travel Considerations X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Eric Burger wrote: > Here is an interesting optimization problem: it turns out the most > polluting part of a conference is people taking jets to fly to the > conference. Minimize that and the planet wins. Favors hub cities over > spokes, like San Diego or Prague, where you "can't get there from here", > no matter where "here" is. Ecological arguments merely add to the list of reasons that major international hubs are the better choice. Additional travel time for each participant. Typically additional travel cost. Travel connections, that introduce subsantially higher risks of delays, lost luggage, etc. Fragile air linkage -- fewer carriers and fewer flights means that it is easier to interrupt service. The only logistical factor that can be in favor of secondary venues is cost. If the on-site costs are low enough, they might offset the travel factors that increase the cost. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 15:25:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQ1I-0005a9-2r; Fri, 12 Oct 2007 15:18:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQ1G-0005a3-Fa for ietf@ietf.org; Fri, 12 Oct 2007 15:17:58 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgQ1F-0003wh-Uz for ietf@ietf.org; Fri, 12 Oct 2007 15:17:58 -0400 X-IronPort-AV: E=Sophos;i="4.21,268,1188802800"; d="scan'208";a="23043378" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 12 Oct 2007 12:17:57 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l9CJHvo7001522; Fri, 12 Oct 2007 12:17:57 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9CJHqxD028804; Fri, 12 Oct 2007 19:17:56 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 12:17:55 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.95.254]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 12:17:55 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Oct 2007 14:17:53 -0500 To: "Dan Harkins" , "Eric Burger" From: "James M. Polk" In-Reply-To: <28109.216.31.249.246.1192213828.squirrel@www.trepanning.ne t> References: <28109.216.31.249.246.1192213828.squirrel@www.trepanning.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 12 Oct 2007 19:17:55.0214 (UTC) FILETIME=[97755AE0:01C80D04] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3021; t=1192216677; x=1193080677; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20Travel=20Considerations |Sender:=20; bh=R5zCs8yseExr58+sjRGB/tG0OoWXKv5FfONpySfus4I=; b=RNVwxE33gpsZKDO69n7uWBanfamNaxFPu+jo1wDumCJ16vDVlGbnTrQugTfyfPee0FFxDVa9 vGppSbGlFrZ8pR4ODCZtbvev43qJXDF3XHHWA2adTYLSoUyCajJm7srQ; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ietf@ietf.org Subject: Re: Travel Considerations X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Unfortunately, using this logic -- I can buy a tank and get 2 gallons-to-the-mile mileage because the rest of the planet (or at least America) is still buying SUVs that get horrible mileage too, since there will be nearly an unmeasurable difference to global warming if I drive my tank or not... so why not drive it anyway. There is an individual responsibility to change what we each can change to help. As an organization, we can have a greater positive affect if we reduce demand for such spoke flights by only flying to hub sites of major airlines -- if we're going to continue to meet in person. If other organizations see ours as an example, and do the same, then the positive affect is greater on us doing the right thing... Doing the right thing in mass has to start somewhere -- why does it have to start somewhere else here? It's Friday... At 01:30 PM 10/12/2007, Dan Harkins wrote: > You're assuming that if 1000 people decide not to fly to Prague >some weekend that the number of planes burning jet fuel to fly there >will be different. I don't think so. > > Maybe you can start a "Boycott Prague The Spoke City" campaign which, >if wildly successful, will reduce demand to fly there by some discernable >amount and thereby reduce the number of planes flying there and the amount >of jet fuel they would've burned. Well, as long as the planes that aren't >flying to Prague aren't used to fly to Heathrow or Frankfurt or some other >hub city. Also doubtful. > > I do not intend on making ietf-discuss into a forum for discussing >the pluses and minuses resulting from a degree centigrade temperature >change but let me just say that "the planet wins" is a somewhat dubious >statement. > > Dan. > >On Fri, October 12, 2007 7:32 am, Eric Burger wrote: > > Here is an interesting optimization problem: it turns out the most > > polluting part of a conference is people taking jets to fly to the > > conference. Minimize that and the planet wins. Favors hub cities over > > spokes, like San Diego or Prague, where you "can't get there from here", > > no matter where "here" is. > > > > See http://www.sciencemag.org/cgi/reprint/318/5847/36.pdf > > > > Notice: This email message, together with any attachments, may contain > > information of BEA Systems, Inc., its subsidiaries and affiliated > > entities, that may be confidential, proprietary, copyrighted and/or > > legally privileged, and is intended solely for the use of the individual > > or entity named in this message. If you are not the intended recipient, > > and have received this message in error, please immediately return this by > > email and then delete it. > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf > > > > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 15:33:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQAT-0003Kh-SO; Fri, 12 Oct 2007 15:27:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQAS-0003If-NU for ietf@ietf.org; Fri, 12 Oct 2007 15:27:28 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IgQAS-0004TR-AY for ietf@ietf.org; Fri, 12 Oct 2007 15:27:28 -0400 X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1192217247!21573908!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 22970 invoked from network); 12 Oct 2007 19:27:27 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-128.messagelabs.com with SMTP; 12 Oct 2007 19:27:27 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l9CJRQin022432 for ; Fri, 12 Oct 2007 12:27:26 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l9CJRQwr009185 for ; Fri, 12 Oct 2007 14:27:26 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l9CJRPmH009180 for ; Fri, 12 Oct 2007 14:27:26 -0500 (CDT) 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" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Oct 2007 15:27:24 -0400 Message-ID: <3870C46029D1F945B1472F170D2D97900321932F@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF / UN Thread-Index: AcgNBeq6Q2KPbU/XTA+K+smC5VJo6g== From: "Eastlake III Donald-LDE008" To: X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: IETF / UN X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org ... "But the UN is a government--" "No it isn't," Martin insisted, "It's a talking shop. Started out as a treaty organization, turned into a bureaucracy, then an escrow agent for various transnational trade and standards agreements. After the Singularity, it was taken over by the Internet engineering task force. It's not the government of Earth; it's just the only remaining relic of Earth's governments that your people can recognize. ..." Singularity Sky, by Charles Stross, ISBN: 0-441-01179-9, Ace Books. From page 281 of the July 2004 paperback edition. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 15:35:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQFB-0001rS-1o; Fri, 12 Oct 2007 15:32:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQF8-0001bJ-R0 for ietf@ietf.org; Fri, 12 Oct 2007 15:32:18 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgQF2-0001gf-KE for ietf@ietf.org; Fri, 12 Oct 2007 15:32:18 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l9CJVnOR023411; Fri, 12 Oct 2007 14:31:49 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 14:31:48 -0500 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" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Oct 2007 14:31:47 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01C26BAA@eusrcmw721.eamcs.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Travel Considerations Thread-Index: AcgNBXKA7FziYFrATNSMTW9SnKPK4QAAOACQ References: <28109.216.31.249.246.1192213828.squirrel@www.trepanning.net> From: "Eric Gray" To: "James M. Polk" , "Dan Harkins" , "Eric Burger" X-OriginalArrivalTime: 12 Oct 2007 19:31:48.0937 (UTC) FILETIME=[88656390:01C80D06] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: ietf@ietf.org Subject: RE: Travel Considerations X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Wow, has this conversation wandered into the weeds, or what? Time out for station identification; this is the "Internet Engineering Task Force." Thanks! -- Eric Gray Principal Engineer Ericsson =20 > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > Sent: Friday, October 12, 2007 3:18 PM > To: Dan Harkins; Eric Burger > Cc: ietf@ietf.org > Subject: Re: Travel Considerations >=20 > Unfortunately, using this logic -- I can buy a tank and get 2=20 > gallons-to-the-mile mileage because the rest of the planet (or at=20 > least America) is still buying SUVs that get horrible mileage too,=20 > since there will be nearly an unmeasurable difference to global=20 > warming if I drive my tank or not... so why not drive it anyway. >=20 > There is an individual responsibility to change what we each can=20 > change to help. As an organization, we can have a greater positive=20 > affect if we reduce demand for such spoke flights by only flying to=20 > hub sites of major airlines -- if we're going to continue to=20 > meet in person. >=20 > If other organizations see ours as an example, and do the same, then=20 > the positive affect is greater on us doing the right thing... >=20 > Doing the right thing in mass has to start somewhere -- why does it=20 > have to start somewhere else here? >=20 > It's Friday... >=20 > At 01:30 PM 10/12/2007, Dan Harkins wrote: >=20 > > You're assuming that if 1000 people decide not to fly to Prague > >some weekend that the number of planes burning jet fuel to fly there > >will be different. I don't think so. > > > > Maybe you can start a "Boycott Prague The Spoke City"=20 > campaign which, > >if wildly successful, will reduce demand to fly there by=20 > some discernable > >amount and thereby reduce the number of planes flying there=20 > and the amount > >of jet fuel they would've burned. Well, as long as the=20 > planes that aren't > >flying to Prague aren't used to fly to Heathrow or Frankfurt=20 > or some other > >hub city. Also doubtful. > > > > I do not intend on making ietf-discuss into a forum for discussing > >the pluses and minuses resulting from a degree centigrade temperature > >change but let me just say that "the planet wins" is a=20 > somewhat dubious > >statement. > > > > Dan. > > > >On Fri, October 12, 2007 7:32 am, Eric Burger wrote: > > > Here is an interesting optimization problem: it turns out the most > > > polluting part of a conference is people taking jets to fly to the > > > conference. Minimize that and the planet wins. Favors=20 > hub cities over > > > spokes, like San Diego or Prague, where you "can't get=20 > there from here", > > > no matter where "here" is. > > > > > > See http://www.sciencemag.org/cgi/reprint/318/5847/36.pdf > > > > > > Notice: This email message, together with any=20 > attachments, may contain > > > information of BEA Systems, Inc., its subsidiaries =20 > and affiliated > > > entities, that may be confidential, proprietary, =20 > copyrighted and/or > > > legally privileged, and is intended solely for the use of=20 > the individual > > > or entity named in this message. If you are not the=20 > intended recipient, > > > and have received this message in error, please=20 > immediately return this by > > > email and then delete it. > > > > > > _______________________________________________ > > > Ietf mailing list > > > Ietf@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ietf > > > > > > > > > > >_______________________________________________ > >Ietf mailing list > >Ietf@ietf.org > >https://www1.ietf.org/mailman/listinfo/ietf >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 16:09:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQk3-0000FC-IP; Fri, 12 Oct 2007 16:04:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQk2-0000EY-86 for ietf@ietf.org; Fri, 12 Oct 2007 16:04:14 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgQk1-0002oY-2L for ietf@ietf.org; Fri, 12 Oct 2007 16:04:14 -0400 X-IronPort-AV: E=Sophos;i="4.21,268,1188792000"; d="scan'208";a="73941549" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 12 Oct 2007 16:04:11 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9CK4AUD000829; Fri, 12 Oct 2007 16:04:10 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9CK418p019688; Fri, 12 Oct 2007 20:04:10 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 16:04:06 -0400 Received: from 10.86.115.70 ([10.86.115.70]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Oct 2007 20:04:05 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 12 Oct 2007 16:04:03 -0400 From: Melinda Shore To: Eric Gray , "James M. Polk" , Dan Harkins , Eric Burger Message-ID: Thread-Topic: Travel Considerations Thread-Index: AcgNBXKA7FziYFrATNSMTW9SnKPK4QAAOACQAAEtq4c= In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF01C26BAA@eusrcmw721.eamcs.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Oct 2007 20:04:06.0330 (UTC) FILETIME=[0B2C19A0:01C80D0B] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15478.002 X-TM-AS-Result: No--15.320500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=487; t=1192219450; x=1193083450; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20 |Subject:=20Re=3A=20Travel=20Considerations |Sender:=20 |To:=20Eric=20Gray=20, =20=22James=20M.=20Polk=22= 20, =0A=20=20=20=20=20=20=20=20Dan=20Harkins=20,=20Eric=20Burger=20; bh=snWHhgf0wQXTq7FJsdCFwR47v4FtOYXg3D9zuCUc8jM=; b=efJkhLMKmFL5WWXLRJLgqdIEgDHHSakLiRXZfX/N0e3qvh2kV8AhhA0wDFImjfMxCJmhVdtq Sps9g66BY5UhqG64xKJQmvpbqNhMW3Hnsd7tIfYuDrdxpwBy4qRM41IA; Authentication-Results: rtp-dkim-1; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ietf@ietf.org Subject: Re: Travel Considerations X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 10/12/07 3:31 PM, "Eric Gray" wrote: > Time out for station identification; this is the "Internet > Engineering Task Force." I tend to think of it as at least in part an engineering question. Obvious questions about tradeoffs and whatnot, and then the question of engineering for errors/exceptions. What are the consequences of assuming and being incorrect? What are the consequences of being incorrect about the alternative? etc. Melinda _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 16:54:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgRKU-0000Ex-70; Fri, 12 Oct 2007 16:41:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgRKS-0007oX-K7 for ietf@ietf.org; Fri, 12 Oct 2007 16:41:52 -0400 Received: from cliffie.verisignlabs.com ([65.201.175.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgRKJ-0007Go-BZ for ietf@ietf.org; Fri, 12 Oct 2007 16:41:43 -0400 Received: from monsoon.verisignlabs.com (scooter.bo.verisignlabs.com [172.25.170.10]) by cliffie.verisignlabs.com (Postfix) with ESMTP id 2B2D0136803; Fri, 12 Oct 2007 16:41:43 -0400 (EDT) Received: from dul1mcmlarson-l1.verisignlabs.com (dul1mcmlarson-l1.verisignlabs.com [10.131.244.205]) by monsoon.verisignlabs.com (Postfix) with ESMTP id 217AA24231B; Fri, 12 Oct 2007 16:41:43 -0400 (EDT) Date: Fri, 12 Oct 2007 16:41:40 -0400 From: Matt Larson To: Eastlake III Donald-LDE008 Message-ID: <20071012204139.GK2453@dul1mcmlarson-l1.verisignlabs.com> References: <3870C46029D1F945B1472F170D2D97900321932F@de01exm64.ds.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3870C46029D1F945B1472F170D2D97900321932F@de01exm64.ds.mot.com> User-Agent: Mutt/1.5.11 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ietf@ietf.org Subject: Re: IETF / UN X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Fri, 12 Oct 2007, Eastlake III Donald-LDE008 wrote: > "But the UN is a government--" > "No it isn't," Martin insisted, "It's a talking shop. Started > out as a treaty organization, turned into a bureaucracy, then an escrow > agent for various transnational trade and standards agreements. After > the Singularity, it was taken over by the Internet engineering task > force. It's not the government of Earth; it's just the only remaining > relic of Earth's governments that your people can recognize. ..." > > Singularity Sky, by Charles Stross, ISBN: 0-441-01179-9, Ace Books. From > page 281 of the July 2004 paperback edition. We're already on the edge of on-topic and this comment has the risk of sending us spiraling off, but everyone really must immediately stop whatever you're doing to go out and buy and read everything by Charles Stross. You won't regret it. Matt _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 17:09:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgRfh-0005a7-CF; Fri, 12 Oct 2007 17:03:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgRfg-0005Va-Ha for ietf@ietf.org; Fri, 12 Oct 2007 17:03:48 -0400 Received: from m4.sparta.com ([157.185.61.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgRfg-0007qj-6e for ietf@ietf.org; Fri, 12 Oct 2007 17:03:48 -0400 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l9CL3lSP021329 for ; Fri, 12 Oct 2007 16:03:47 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l9CL3lZb017544 for ; Fri, 12 Oct 2007 16:03:47 -0500 Received: from localhost ([157.185.80.253]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Oct 2007 17:03:46 -0400 Date: Fri, 12 Oct 2007 17:03:45 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@mint.samweiler.com To: ietf@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 12 Oct 2007 21:03:46.0945 (UTC) FILETIME=[61629710:01C80D13] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Fri, 12 Oct 2007 16:03:47 -0500 (CDT) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: Re: IETF / UN X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > We're already on the edge of on-topic and this comment has the risk > of sending us spiraling off, but everyone really must immediately > stop whatever you're doing to go out and buy and read everything by > Charles Stross. You won't regret it. As long as we're off-topic... Stross is doing a signing in San Francisco today at 7pm. http://www.antipope.org/charlie/blog-static/index.html http://www.bordersstores.com/stores/store_pg.jsp?storeID=57 -- Sam _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 17:09:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgRfQ-0004Av-73; Fri, 12 Oct 2007 17:03:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgRfO-00046T-KU for ietf@ietf.org; Fri, 12 Oct 2007 17:03:30 -0400 Received: from colo.trepanning.net ([69.55.226.174] helo=mail1.trepanning.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgRfN-00050n-B8 for ietf@ietf.org; Fri, 12 Oct 2007 17:03:30 -0400 Received: from www.trepanning.net (localhost [127.0.0.1]) by mail1.trepanning.net (Postfix) with ESMTP id C79531FA6107; Fri, 12 Oct 2007 14:03:25 -0700 (PDT) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 12 Oct 2007 14:03:25 -0700 (PDT) Message-ID: <1080.216.31.249.246.1192223005.squirrel@www.trepanning.net> In-Reply-To: References: <28109.216.31.249.246.1192213828.squirrel@www.trepanning.net> Date: Fri, 12 Oct 2007 14:03:25 -0700 (PDT) From: "Dan Harkins" To: "James M. Polk" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: ietf@ietf.org Subject: Re: Travel Considerations X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi James, I think you're missing the point. I'm not advocating being wasteful because everyone else is. I'm saying that this effort is futile and will not result in _any_ "win" for the planet. Your analogy to driving an SUV is incorrect because not driving the SUV (or driving an electric car instead) results in less emissions. A trivial amount but every little bit helps. Flying 1000 people to Frankfurt instead of Prague does not result in any less emissions. Encouraging other organizations to follow our lead-- having 10000 people scattered over the course of a year fly to a hub instead of through the hub to a spoke-- won't either. The demand is still there to fly to places like Prague and San Diego and airlines typically fly at less than 100% capacity, sometimes significantly so. If you think there is an individual responsibility to change what you can then please don't waste your effort on something that won't have any effect! Do something that will make a difference. I for one would rather fly to (spoke) Prague than (hub) Frankfurt; to (spoke) San Diego than to (hub) Chicago; and anywhere (spoke) on God's green earth (yes, it's still green in spite of the IETF World Tour) than (hub) London. Dan. On Fri, October 12, 2007 12:17 pm, James M. Polk wrote: > Unfortunately, using this logic -- I can buy a tank and get 2 > gallons-to-the-mile mileage because the rest of the planet (or at > least America) is still buying SUVs that get horrible mileage too, > since there will be nearly an unmeasurable difference to global > warming if I drive my tank or not... so why not drive it anyway. > > There is an individual responsibility to change what we each can > change to help. As an organization, we can have a greater positive > affect if we reduce demand for such spoke flights by only flying to > hub sites of major airlines -- if we're going to continue to meet in > person. > > If other organizations see ours as an example, and do the same, then > the positive affect is greater on us doing the right thing... > > Doing the right thing in mass has to start somewhere -- why does it > have to start somewhere else here? > > It's Friday... > > At 01:30 PM 10/12/2007, Dan Harkins wrote: > >> You're assuming that if 1000 people decide not to fly to Prague >>some weekend that the number of planes burning jet fuel to fly there >>will be different. I don't think so. >> >> Maybe you can start a "Boycott Prague The Spoke City" campaign which= , >>if wildly successful, will reduce demand to fly there by some discernab= le >>amount and thereby reduce the number of planes flying there and the >> amount >>of jet fuel they would've burned. Well, as long as the planes that aren= 't >>flying to Prague aren't used to fly to Heathrow or Frankfurt or some >> other >>hub city. Also doubtful. >> >> I do not intend on making ietf-discuss into a forum for discussing >>the pluses and minuses resulting from a degree centigrade temperature >>change but let me just say that "the planet wins" is a somewhat dubious >>statement. >> >> Dan. >> >>On Fri, October 12, 2007 7:32 am, Eric Burger wrote: >> > Here is an interesting optimization problem: it turns out the most >> > polluting part of a conference is people taking jets to fly to the >> > conference. Minimize that and the planet wins. Favors hub cities >> over >> > spokes, like San Diego or Prague, where you "can't get there from >> here", >> > no matter where "here" is. >> > >> > See http://www.sciencemag.org/cgi/reprint/318/5847/36.pdf >> > >> > Notice: This email message, together with any attachments, may >> contain >> > information of BEA Systems, Inc., its subsidiaries and >> affiliated >> > entities, that may be confidential, proprietary, copyrighted >> and/or >> > legally privileged, and is intended solely for the use of the >> individual >> > or entity named in this message. If you are not the intended >> recipient, >> > and have received this message in error, please immediately return >> this by >> > email and then delete it. >> > >> > _______________________________________________ >> > Ietf mailing list >> > Ietf@ietf.org >> > https://www1.ietf.org/mailman/listinfo/ietf >> > >> >> >> >>_______________________________________________ >>Ietf mailing list >>Ietf@ietf.org >>https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 17:52:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgSEW-0005Jy-2s; Fri, 12 Oct 2007 17:39:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgSES-0005JV-Hu for ietf@ietf.org; Fri, 12 Oct 2007 17:39:44 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgSEK-0005rl-FW for ietf@ietf.org; Fri, 12 Oct 2007 17:39:42 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Fri, 12 Oct 2007 17:39:16 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 12 Oct 2007 17:39:16 -0400 From: Hadriel Kaplan To: Dan Harkins , "James M. Polk" Date: Fri, 12 Oct 2007 17:39:05 -0400 Thread-Topic: Travel Considerations Thread-Index: AcgNFJ53y84TS7z4Q4K+J8xez6TUJwAAcMnQ Message-ID: References: <28109.216.31.249.246.1192213828.squirrel@www.trepanning.net> <1080.216.31.249.246.1192223005.squirrel@www.trepanning.net> In-Reply-To: <1080.216.31.249.246.1192223005.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: "ietf@ietf.org" Subject: RE: Travel Considerations X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org If 1000 fewer people board planes, I'm pretty sure it consumes some trivial= amount less in jet fuel, simply due to the lighter weight of the plane. B= ut that difference would be more than made up by the proximity of the hotel= to the airport and available mass transit to it, which would put San Diego= 's Sheraton pretty high up on the list. Also, there is probably some proportional relationship of how many people a= ttend the IETF meetings compared to the reachability of their locations; so= having it at hub airports may be worse, and we should really have it at le= ss accessible destinations... such as an island in the middle of a big ocea= n. Therefore, I vote for Kauai, Hawaii, as the future permanent host islan= d. -hadriel > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Friday, October 12, 2007 5:03 PM > To: James M. Polk > Cc: ietf@ietf.org > Subject: Re: Travel Considerations > > > Hi James, > > I think you're missing the point. I'm not advocating being wasteful > because everyone else is. I'm saying that this effort is futile and > will not result in _any_ "win" for the planet. Your analogy to driving > an SUV is incorrect because not driving the SUV (or driving an > electric car instead) results in less emissions. A trivial amount but > every little bit helps. Flying 1000 people to Frankfurt instead of > Prague does not result in any less emissions. Encouraging other > organizations to follow our lead-- having 10000 people scattered over > the course of a year fly to a hub instead of through the hub to a > spoke-- won't either. The demand is still there to fly to places like > Prague and San Diego and airlines typically fly at less than 100% > capacity, sometimes significantly so. > > If you think there is an individual responsibility to change what > you can then please don't waste your effort on something that won't > have any effect! Do something that will make a difference. > > I for one would rather fly to (spoke) Prague than (hub) Frankfurt; > to (spoke) San Diego than to (hub) Chicago; and anywhere (spoke) on > God's green earth (yes, it's still green in spite of the IETF World > Tour) than (hub) London. > > Dan. > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 19:20:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgTSk-00015Z-SS; Fri, 12 Oct 2007 18:58:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgTSj-00011w-7D for ietf@ietf.org; Fri, 12 Oct 2007 18:58:33 -0400 Received: from nz-out-0506.google.com ([64.233.162.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgTSU-0007yq-7L for ietf@ietf.org; Fri, 12 Oct 2007 18:58:24 -0400 Received: by nz-out-0506.google.com with SMTP id n1so775938nzf for ; Fri, 12 Oct 2007 15:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Lprkoz4lV5U/yWtRMe6F2iIgtjeoJHrZIDyLBlMQu7g=; b=o+VtjHKC4wSPzFxc1W/+ysH9NyWzBJVRO/mWZdG+1WE7FF5v8cJZY6TXa4j3YBa2luEQxQ1yII5J30PtFq7zVmlKYnxAGOQX/w9ipj2M8uODwxSK1HPfrmVlkjcUO7kUdcAYaA4EwGviZIgzpwtjv+i9XGm0njOxZ1Dbct3iilo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pVF+R4lYoB5IF59DfMZxp/I82FvkeDMmcoKHyAR8Rq9aNsbofxwY1XXexbMLTfV+kE+uNwCGZKLrDMWh5gztXKNsE6hRvLHlY+3EIZ52w8iUsPaKKP1nVPWePif3qEanNTEPyXMruDJNcpXQWCxhwemwsndoEUSd8Ol65dYro94= Received: by 10.142.211.10 with SMTP id j10mr1233771wfg.1192229867307; Fri, 12 Oct 2007 15:57:47 -0700 (PDT) Received: by 10.142.226.14 with HTTP; Fri, 12 Oct 2007 15:57:47 -0700 (PDT) Message-ID: Date: Fri, 12 Oct 2007 15:57:47 -0700 From: "Clint Chaplin" To: "ietf@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <28109.216.31.249.246.1192213828.squirrel@www.trepanning.net> <1080.216.31.249.246.1192223005.squirrel@www.trepanning.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: Re: Travel Considerations X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 10/12/07, Hadriel Kaplan wrote: > If 1000 fewer people board planes, I'm pretty sure it consumes some trivial amount less in jet fuel, simply due to the lighter weight of the plane. But that difference would be more than made up by the proximity of the hotel to the airport and available mass transit to it, which would put San Diego's Sheraton pretty high up on the list. > > Also, there is probably some proportional relationship of how many people attend the IETF meetings compared to the reachability of their locations; so having it at hub airports may be worse, and we should really have it at less accessible destinations... such as an island in the middle of a big ocean. Therefore, I vote for Kauai, Hawaii, as the future permanent host island. > +1 > -hadriel > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@lounge.org] > > Sent: Friday, October 12, 2007 5:03 PM > > To: James M. Polk > > Cc: ietf@ietf.org > > Subject: Re: Travel Considerations > > > > > > Hi James, > > > > I think you're missing the point. I'm not advocating being wasteful > > because everyone else is. I'm saying that this effort is futile and > > will not result in _any_ "win" for the planet. Your analogy to driving > > an SUV is incorrect because not driving the SUV (or driving an > > electric car instead) results in less emissions. A trivial amount but > > every little bit helps. Flying 1000 people to Frankfurt instead of > > Prague does not result in any less emissions. Encouraging other > > organizations to follow our lead-- having 10000 people scattered over > > the course of a year fly to a hub instead of through the hub to a > > spoke-- won't either. The demand is still there to fly to places like > > Prague and San Diego and airlines typically fly at less than 100% > > capacity, sometimes significantly so. > > > > If you think there is an individual responsibility to change what > > you can then please don't waste your effort on something that won't > > have any effect! Do something that will make a difference. > > > > I for one would rather fly to (spoke) Prague than (hub) Frankfurt; > > to (spoke) San Diego than to (hub) Chicago; and anywhere (spoke) on > > God's green earth (yes, it's still green in spite of the IETF World > > Tour) than (hub) London. > > > > Dan. > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > -- Clint (JOATMON) Chaplin Principal Engineer Corporate Standardization (US) SISA _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 21:32:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgVY9-0002vo-VE; Fri, 12 Oct 2007 21:12:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgVY8-0002s8-2I for ietf@ietf.org; Fri, 12 Oct 2007 21:12:16 -0400 Received: from machshav.com ([198.180.150.44]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgVY5-0002Hi-L7 for ietf@ietf.org; Fri, 12 Oct 2007 21:12:13 -0400 Received: by machshav.com (Postfix, from userid 512) id 53AC2627; Sat, 13 Oct 2007 01:12:13 +0000 (GMT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 809D460D; Sat, 13 Oct 2007 01:12:12 +0000 (GMT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 96C49766013; Fri, 12 Oct 2007 21:12:25 -0400 (EDT) Date: Sat, 13 Oct 2007 01:12:25 +0000 From: "Steven M. Bellovin" To: Matt Larson Message-ID: <20071013011225.71564768@berkshire.machshav.com> In-Reply-To: <20071012204139.GK2453@dul1mcmlarson-l1.verisignlabs.com> References: <3870C46029D1F945B1472F170D2D97900321932F@de01exm64.ds.mot.com> <20071012204139.GK2453@dul1mcmlarson-l1.verisignlabs.com> Organization: Columbia University X-Mailer: Claws Mail 3.0.1 (GTK+ 2.10.14; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ietf@ietf.org Subject: Re: IETF / UN X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Fri, 12 Oct 2007 16:41:40 -0400 Matt Larson wrote: > On Fri, 12 Oct 2007, Eastlake III Donald-LDE008 wrote: > > "But the UN is a government--" > > "No it isn't," Martin insisted, "It's a talking shop. > > Started out as a treaty organization, turned into a bureaucracy, > > then an escrow agent for various transnational trade and standards > > agreements. After the Singularity, it was taken over by the > > Internet engineering task force. It's not the government of Earth; > > it's just the only remaining relic of Earth's governments that your > > people can recognize. ..." > > > > Singularity Sky, by Charles Stross, ISBN: 0-441-01179-9, Ace Books. > > From page 281 of the July 2004 paperback edition. > > We're already on the edge of on-topic and this comment has the risk of > sending us spiraling off, but everyone really must immediately stop > whatever you're doing to go out and buy and read everything by Charles > Stross. You won't regret it. > Indeed. A few years ago, I dropped him a note and mentioned that that line was quite popular in the IETF. He replied As it happens I'd be quite surprised if the IETF or something like it *doesn't* end up running the planet one of these days. (Running the planet being a thankless infrastructure maintenance task, after all.) --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 23:22:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgXDm-0000dE-Oz; Fri, 12 Oct 2007 22:59:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgXDk-0000ag-S2 for ietf@ietf.org; Fri, 12 Oct 2007 22:59:20 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgXDa-0001aX-LE for ietf@ietf.org; Fri, 12 Oct 2007 22:59:16 -0400 Received: from E03MVC4-UKBR.domain1.systemhost.net ([193.113.197.115]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 Oct 2007 03:58:55 +0100 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" Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Oct 2007 04:01:23 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Travel Considerations Thread-Index: AcgM3MEZgv2eBnV6QqmCWgsharAqGAAaAxMA References: From: To: X-OriginalArrivalTime: 13 Oct 2007 02:58:55.0546 (UTC) FILETIME=[FE4D11A0:01C80D44] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: RE: Travel Considerations X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > Here is an interesting optimization problem: it turns out the=20 > most polluting part of a conference is people taking jets to=20 > fly to the conference. Minimize that and the planet wins. =20 Simple solution. Only allow people to attend if they take a train or bus to the conference. Enforce this by including tickets for train or bus (your choice) when registering to attend a conference. It makes trans-continental conferences impossible (although you might add an ocean liner option) but that is not necessarily a bad thing. What is wrong with have several different continental chapters of the IETF, given that all decisionmaking is supposed to be done online, not in meetings? --Michael Dillon P.S. if you look at a map of Europe, Prague is rather centrally located an makes an ideal location for a "green" conference like this. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 23:34:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgXdC-0002Ea-TG; Fri, 12 Oct 2007 23:25:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgXdA-00025i-WD; Fri, 12 Oct 2007 23:25:37 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgXd4-0002Pg-Py; Fri, 12 Oct 2007 23:25:36 -0400 X-IronPort-AV: E=Sophos;i="4.21,269,1188802800"; d="scan'208";a="534650561" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-3.cisco.com with ESMTP; 12 Oct 2007 20:25:24 -0700 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9D3PNGj031159; Sat, 13 Oct 2007 05:25:23 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9D3PNUh029663; Sat, 13 Oct 2007 03:25:23 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 Oct 2007 05:25:23 +0200 Received: from [192.130.162.177] ([10.61.64.213]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 Oct 2007 05:25:22 +0200 In-Reply-To: <1080.216.31.249.246.1192223005.squirrel@www.trepanning.net> References: <28109.216.31.249.246.1192213828.squirrel@www.trepanning.net> <1080.216.31.249.246.1192223005.squirrel@www.trepanning.net> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <72A37528-3B71-4208-919B-4D7A072334F3@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Sat, 13 Oct 2007 06:25:13 +0300 To: chair@ietf.org X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Oct 2007 03:25:22.0995 (UTC) FILETIME=[B07E9030:01C80D48] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15480.000 X-TM-AS-Result: No--3.822500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=529; t=1192245923; x=1193109923; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Travel=20Considerations |Sender:=20; bh=/gLromeurHcStJ48d7fmF34TtgvBKLLqXxHrMtKs3q0=; b=tmWukkdXyfTB4OuzoKXVrUrXOFCPXJy/ARTmb4JCsNtrMxcA1ecodiUPaEzd5kCtF++QKUi6 z3T9qrsNB3uR3KyjOVnG/CbepRa12UFcUa4XEkxEiQ6fceeG9tj9dzjA; Authentication-Results: ams-dkim-1; header.From=fred@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: IETF-Discussion Subject: Re: Travel Considerations X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mr Chairman, I have a suggestion. I suggest that we have a BOF at the next IETF on heat transfer issues, and subsequently open a working group. It can deal with this issue right after it solves the leakage current problem in fine lithography silicon, which I imagine contributes quite a bit to the use of electricity by the Internet. -----BEGIN PGP SIGNATURE----- iD8DBQFHEDqZbjEdbHIsm0MRAn8DAKDJqy0i4AFofEMKBGrmaWs1c0yOsACgqKx+ NHxE0PUARkk7FPcMiPJuGzE= =8u8Y -----END PGP SIGNATURE----- _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 12 23:34:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgXcn-0008Fy-N0; Fri, 12 Oct 2007 23:25:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgXcl-000885-Sd for ietf@ietf.org; Fri, 12 Oct 2007 23:25:11 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgXcX-0002P3-DF for ietf@ietf.org; Fri, 12 Oct 2007 23:25:11 -0400 X-IronPort-AV: E=Sophos;i="4.21,269,1188770400"; d="scan'208";a="155685316" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2007 05:24:52 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9D3OpE0008646 for ; Sat, 13 Oct 2007 05:24:51 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9D3OpUh029517 for ; Sat, 13 Oct 2007 03:24:51 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 Oct 2007 05:24:51 +0200 Received: from [192.130.162.177] ([10.61.64.213]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 Oct 2007 05:24:51 +0200 In-Reply-To: <1080.216.31.249.246.1192223005.squirrel@www.trepanning.net> References: <28109.216.31.249.246.1192213828.squirrel@www.trepanning.net> <1080.216.31.249.246.1192223005.squirrel@www.trepanning.net> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <72A3B0E4-9D7F-4897-98C2-3AEEC5ADD389@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Sat, 13 Oct 2007 06:24:41 +0300 To: IETF-Discussion X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Oct 2007 03:24:51.0120 (UTC) FILETIME=[9D7ED300:01C80D48] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15480.000 X-TM-AS-Result: No--36.218400-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5926; t=1192245891; x=1193109891; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Travel=20Considerations |Sender:=20; bh=B44T/Bls6ZUj+jyl2wiq1Xv4XM0BRa0kuPzR2qCeoCo=; b=dv+mslcg3x2zgefZh/D0aQt09EfiJudxcSel88xx/lvljTLioB1ZXKlu4BupiPIH7QB/AQBg 4M0pVU64dZQdxDpWYbjbeve0HZA+dXSvwlNlaT7Eq9/RTojElSmvk4DJ; Authentication-Results: ams-dkim-2; header.From=fred@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Subject: Re: Travel Considerations X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I asked James this privately, but if we're going to get into an off- topic discussion of global warming, I'll ask it publicly to whoever has a good answer. We all agree that global warming is happening. If you go to the terminal moraine, the farthest south that the ice went doing the largest or perhaps the most recent ice age, and you don't see any ice, the earth is provably warmer than it once was. That said, do we not see ice at the terminal moraine because people drive SUVs, or because warming and cooling is something that has been happening since God created the earth? In the latter case, specifically what scientific evidence do we have that our current global warming event (which started in the 16th century, which was a mini-ice-age) is related to emissions? What scientific evidence do we have that changing emissions behavior will change global warming in any way? On Oct 13, 2007, at 12:03 AM, Dan Harkins wrote: > > Hi James, > > I think you're missing the point. I'm not advocating being wasteful > because everyone else is. I'm saying that this effort is futile and > will not result in _any_ "win" for the planet. Your analogy to driving > an SUV is incorrect because not driving the SUV (or driving an > electric car instead) results in less emissions. A trivial amount but > every little bit helps. Flying 1000 people to Frankfurt instead of > Prague does not result in any less emissions. Encouraging other > organizations to follow our lead-- having 10000 people scattered over > the course of a year fly to a hub instead of through the hub to a > spoke-- won't either. The demand is still there to fly to places like > Prague and San Diego and airlines typically fly at less than 100% > capacity, sometimes significantly so. > > If you think there is an individual responsibility to change what > you can then please don't waste your effort on something that won't > have any effect! Do something that will make a difference. > > I for one would rather fly to (spoke) Prague than (hub) Frankfurt; > to (spoke) San Diego than to (hub) Chicago; and anywhere (spoke) on > God's green earth (yes, it's still green in spite of the IETF World > Tour) than (hub) London. > > Dan. > > On Fri, October 12, 2007 12:17 pm, James M. Polk wrote: >> Unfortunately, using this logic -- I can buy a tank and get 2 >> gallons-to-the-mile mileage because the rest of the planet (or at >> least America) is still buying SUVs that get horrible mileage too, >> since there will be nearly an unmeasurable difference to global >> warming if I drive my tank or not... so why not drive it anyway. >> >> There is an individual responsibility to change what we each can >> change to help. As an organization, we can have a greater positive >> affect if we reduce demand for such spoke flights by only flying to >> hub sites of major airlines -- if we're going to continue to meet in >> person. >> >> If other organizations see ours as an example, and do the same, then >> the positive affect is greater on us doing the right thing... >> >> Doing the right thing in mass has to start somewhere -- why does it >> have to start somewhere else here? >> >> It's Friday... >> >> At 01:30 PM 10/12/2007, Dan Harkins wrote: >> >>> You're assuming that if 1000 people decide not to fly to Prague >>> some weekend that the number of planes burning jet fuel to fly there >>> will be different. I don't think so. >>> >>> Maybe you can start a "Boycott Prague The Spoke City" campaign >>> which, >>> if wildly successful, will reduce demand to fly there by some >>> discernable >>> amount and thereby reduce the number of planes flying there and the >>> amount >>> of jet fuel they would've burned. Well, as long as the planes >>> that aren't >>> flying to Prague aren't used to fly to Heathrow or Frankfurt or some >>> other >>> hub city. Also doubtful. >>> >>> I do not intend on making ietf-discuss into a forum for discussing >>> the pluses and minuses resulting from a degree centigrade >>> temperature >>> change but let me just say that "the planet wins" is a somewhat >>> dubious >>> statement. >>> >>> Dan. >>> >>> On Fri, October 12, 2007 7:32 am, Eric Burger wrote: >>>> Here is an interesting optimization problem: it turns out the most >>>> polluting part of a conference is people taking jets to fly to the >>>> conference. Minimize that and the planet wins. Favors hub cities >>> over >>>> spokes, like San Diego or Prague, where you "can't get there from >>> here", >>>> no matter where "here" is. >>>> >>>> See http://www.sciencemag.org/cgi/reprint/318/5847/36.pdf >>>> >>>> Notice: This email message, together with any attachments, may >>> contain >>>> information of BEA Systems, Inc., its subsidiaries and >>> affiliated >>>> entities, that may be confidential, proprietary, copyrighted >>> and/or >>>> legally privileged, and is intended solely for the use of the >>> individual >>>> or entity named in this message. If you are not the intended >>> recipient, >>>> and have received this message in error, please immediately return >>> this by >>>> email and then delete it. >>>> >>>> _______________________________________________ >>>> Ietf mailing list >>>> Ietf@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ietf >>>> >>> >>> >>> >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ietf >> > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf -----BEGIN PGP SIGNATURE----- iD8DBQFHEDp5bjEdbHIsm0MRAslgAKDSi+UeR/OnCD1QiXbjIwbHB6RV/ACgqPve GXSX3XJqDkWibCQ1NeuDivA= =TqSH -----END PGP SIGNATURE----- _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 13 02:19:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgZyq-0002sv-5r; Sat, 13 Oct 2007 01:56:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgZyo-0002on-ER for ietf@ietf.org; Sat, 13 Oct 2007 01:56:06 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgZyn-0004as-1E for ietf@ietf.org; Sat, 13 Oct 2007 01:56:06 -0400 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 8555095; Sat, 13 Oct 2007 01:56:02 -0400 In-Reply-To: <72A3B0E4-9D7F-4897-98C2-3AEEC5ADD389@cisco.com> References: <28109.216.31.249.246.1192213828.squirrel@www.trepanning.net> <1080.216.31.249.246.1192223005.squirrel@www.trepanning.net> <72A3B0E4-9D7F-4897-98C2-3AEEC5ADD389@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6786A142-4D37-4B6C-BE0E-FC37794EC435@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Date: Sat, 13 Oct 2007 01:55:59 -0400 To: Fred Baker X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b Cc: IETF-Discussion Subject: Re: Travel Considerations X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 12, 2007, at 11:24 PM, Fred Baker wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I asked James this privately, but if we're going to get into an off- > topic discussion of global warming, I'll ask it publicly to whoever > has a good answer. > > > We all agree that global warming is happening. If you go to the > terminal moraine, the farthest south that the ice went doing the > largest or perhaps the most recent ice age, and you don't see any > ice, the earth is provably warmer than it once was. > > That said, do we not see ice at the terminal moraine because people > drive SUVs, or because warming and cooling is something that has > been happening since God created the earth? In the latter case, > specifically what scientific evidence do we have that our current > global warming event (which started in the 16th century, which was > a mini-ice-age) is related to emissions? What scientific evidence > do we have that changing emissions behavior will change global > warming in any way? > Dear Fred; As a physicist who worked a little in climate change in the late 1980's, let me give a capsule answer and then shut up. I will look, in turn, at the Greenhouse effect, at the CO2 changes, and at possible effects of the ongoing human forcing of the climate. If the Earth's atmosphere did not trap heat, the mean surface temperature would be well below freezing. This math is not too difficult; you know the solar constant (input heating), mean albedo and rotation rate (the Earth warms during the day, cools at night by radiation) and you set up a spherically uniform model, which can be solved analytically. Instead, the Earth's mean surface is above freezing. (Supposedly, at this moment as I write the globally mean surface temp is 6.72 C, but the annual average is more like 14 C. The Northern hemisphere, having a good deal more land, dominates the annual cycle.) The difference between observed and no-atmosphere predicted mean temperatures for the Earth is about 40 C. This difference is caused by the so called "Greenhouse" effect, the blockage of IR radiation out from the Earth's surface. (Actual Greenhouses work mostly by stopping convection, not IR heat loss.) This blockage is mostly due to CO2, but Methane (from cows!) and other trace gases are also important, as is water vapor due to its prevalence. The simple uniform models do a reasonable job predicting the average lunar temperature; the lunar mean surface temperature is -50 C, which shows what an atmosphere can do for you. Thus, there is no doubt of the existence of the Greenhouse effect; not only does the physics work out approximately well not only for the Earth and Moon, but also for Mars (a little Greenhouse, but noticeable) and Venus. Venus is a very interesting case, being so similar to the Earth in size and composition. On the Earth, CO2 is mostly in certain rocks, like limestone, then dissolved in the Oceans, then in the Atmosphere, by a relative proportion of roughly >10,000:50:1. On Venus, a comparable amount of CO2 is all in the atmosphere, and, as a result, the surface is very hot (mean temperature ~ 460 C). This is _not_ primarily due it being closer to the Sun, if it had terrestrial oceans and a terrestrial atmosphere, it would be a temperate place. (By isotopic evidence Venus used to have oceans, but it lost them - note that the rocks that contain CO2 here would mostly give it up at 400+ C - apparently, once Venus heated up all the CO2 went into the atmosphere and now it can never cool down.) So, we have 4 objects (Earth, Moon, Venus, Mars), 3 of which have Greenhouse effects, and for all 4 of which we can calculate the observed surface temperatures reasonably well from fairly simple first principles. So, I regard the greenhouse effect as about as well proven as anything in planetary physics. You might have seen in the press that we just passed the 50th anniversary of Sputnik 1; this being launched as part of the IGY. As another part of the IGY, we started measuring CO2 from the top of Mauna Loa, Hawaii, on a daily basis. This is not only the longest CO2 measurement series, but it's also a good place to do it, as the top of the volcano is above the local effects, and samples air mixed over a good portion of the Northern hemisphere. These and other data show without a doubt that the CO2 is rising, and match reasonably well with estimates of human forcing. Other trace gases are also important, and they are also increasing (such as methane from increased beef production). Now, it is true that when you go a little further into the physics, things get messy fast. There are sources and sinks of everything. (If the top 50 meters of the oceans warm, will that increase or decrease the dissolved CO2 ?Will increased CO2 make forests grow faster and thus absorb more CO2 ? What about albedo from increased cloudiness ? Etc. etc. etc.) It's also hard to measure things consistently over decades. (For one of many examples, both the US and the USSR changed the way they measured temperature for their weather services soon after World War II, both in ways that caused biases in their temperature series. That's a good part of the Northern hemisphere, all messed up more or less at once.) And, as you say, there are considerable natural climate variations, which could mask, confuse or amplify any effects from human forcings. However, there are people who worry about all of these things, and their models (the complexity of the system requires numerical modeling to do anything detailed) agree roughly with what's observed. So, to me the basic situation is pretty simple. You have a system where the amount of CO2 and other trace gases in the atmosphere controls the surface temperature. You (we) are increasing the amount of CO2 and other trace gases in the atmosphere. The surface temperature is going up, unusually so. This was predicted back in the 1980's, if not before, which is always nice in any scientific test. As far as I am concerned, this is all pretty conclusive and puts the burden of proof on anyone who says that there is not any temperature rise due to human forcing. It is as if someone started eating a lot more, and started gaining weight. If they protested that their weight gain had nothing to do with the increase in their diet, their Doctor would probably be dubious, and would probably recommend a reduction in their intake. > What scientific evidence do we have that changing emissions > behavior will change global warming in any way? That is a good question. A related one is, if we reduced or even stopped emissions, would the CO2 go back to where it was before ? That requires more models, but it seems that the answer is, not for a good while (a century or so). So, we are in for a ride, no matter what we do. The scary thing is that the climate is highly non-linear, and the rough equivalent of congestive collapse (rapid change to a less favorable state when certain conditions are met) is possible, as such things have happened in the past. Our ability to model such rapid state changes is poor, especially if they are unprecedented in recent times. Note that things can go either way - model failures can under or over predict what really happens. An example of this is the story of the Ozone hole. In the 1960's, people started worrying about the effects of human produced gasses in the upper atmosphere. There were some scare stories about the entire Ozone layer going in a few decades. By the 1970's, the consensus was that the situation wasn't so bad - the models showed that there just wasn't enough Freon etc. up there to "eat" the entire Ozone layer. The discovery of the Ozone hole over Antarctica was a complete surprise. The models (due to the lack of computing resources back then) had dealt mostly with global averages. No one had thought how in the polar winter the polar atmosphere at altitude doesn't mix much with lower latitudes. Ozone is formed by sunlight, of which there is none during the polar winter. So, the Ozone over the pole sits with Freon and other antagonists all winter long, and there is no replenishment. In those conditions, there _is_ enough Freon etc. to "eat" the local Ozone, and nothing to replace it, so a hole forms. Now it is modeled reasonably well, but the models missed it then. Likewise, there could be some bad things in store with the climate not anticipated by the current modeling. Here is a paraphrase of what I said back in 1987, which I think is still pretty sound : We are undertaking a vast unplanned experiment in climate modification which could have unpleasant consequences. Prudence would suggest that we take steps to mitigate these consequences. To argue about what these steps should be is reasonable, but to totally ignore the situation is not. Hope this helps. As I said before, I'll shut up about this now, at least on this list. Regards Marshall > > On Oct 13, 2007, at 12:03 AM, Dan Harkins wrote: > >> >> Hi James, >> >> I think you're missing the point. I'm not advocating being wasteful >> because everyone else is. I'm saying that this effort is futile and >> will not result in _any_ "win" for the planet. Your analogy to >> driving >> an SUV is incorrect because not driving the SUV (or driving an >> electric car instead) results in less emissions. A trivial amount but >> every little bit helps. Flying 1000 people to Frankfurt instead of >> Prague does not result in any less emissions. Encouraging other >> organizations to follow our lead-- having 10000 people scattered over >> the course of a year fly to a hub instead of through the hub to a >> spoke-- won't either. The demand is still there to fly to places like >> Prague and San Diego and airlines typically fly at less than 100% >> capacity, sometimes significantly so. >> >> If you think there is an individual responsibility to change what >> you can then please don't waste your effort on something that won't >> have any effect! Do something that will make a difference. >> >> I for one would rather fly to (spoke) Prague than (hub) Frankfurt; >> to (spoke) San Diego than to (hub) Chicago; and anywhere (spoke) on >> God's green earth (yes, it's still green in spite of the IETF World >> Tour) than (hub) London. >> >> Dan. >> >> On Fri, October 12, 2007 12:17 pm, James M. Polk wrote: >>> Unfortunately, using this logic -- I can buy a tank and get 2 >>> gallons-to-the-mile mileage because the rest of the planet (or at >>> least America) is still buying SUVs that get horrible mileage too, >>> since there will be nearly an unmeasurable difference to global >>> warming if I drive my tank or not... so why not drive it anyway. >>> >>> There is an individual responsibility to change what we each can >>> change to help. As an organization, we can have a greater positive >>> affect if we reduce demand for such spoke flights by only flying to >>> hub sites of major airlines -- if we're going to continue to meet in >>> person. >>> >>> If other organizations see ours as an example, and do the same, then >>> the positive affect is greater on us doing the right thing... >>> >>> Doing the right thing in mass has to start somewhere -- why does it >>> have to start somewhere else here? >>> >>> It's Friday... >>> >>> At 01:30 PM 10/12/2007, Dan Harkins wrote: >>> >>>> You're assuming that if 1000 people decide not to fly to Prague >>>> some weekend that the number of planes burning jet fuel to fly >>>> there >>>> will be different. I don't think so. >>>> >>>> Maybe you can start a "Boycott Prague The Spoke City" campaign >>>> which, >>>> if wildly successful, will reduce demand to fly there by some >>>> discernable >>>> amount and thereby reduce the number of planes flying there and the >>>> amount >>>> of jet fuel they would've burned. Well, as long as the planes >>>> that aren't >>>> flying to Prague aren't used to fly to Heathrow or Frankfurt or >>>> some >>>> other >>>> hub city. Also doubtful. >>>> >>>> I do not intend on making ietf-discuss into a forum for >>>> discussing >>>> the pluses and minuses resulting from a degree centigrade >>>> temperature >>>> change but let me just say that "the planet wins" is a somewhat >>>> dubious >>>> statement. >>>> >>>> Dan. >>>> >>>> On Fri, October 12, 2007 7:32 am, Eric Burger wrote: >>>>> Here is an interesting optimization problem: it turns out the most >>>>> polluting part of a conference is people taking jets to fly to the >>>>> conference. Minimize that and the planet wins. Favors hub cities >>>> over >>>>> spokes, like San Diego or Prague, where you "can't get there from >>>> here", >>>>> no matter where "here" is. >>>>> >>>>> See http://www.sciencemag.org/cgi/reprint/318/5847/36.pdf >>>>> >>>>> Notice: This email message, together with any attachments, may >>>> contain >>>>> information of BEA Systems, Inc., its subsidiaries and >>>> affiliated >>>>> entities, that may be confidential, proprietary, copyrighted >>>> and/or >>>>> legally privileged, and is intended solely for the use of the >>>> individual >>>>> or entity named in this message. If you are not the intended >>>> recipient, >>>>> and have received this message in error, please immediately return >>>> this by >>>>> email and then delete it. >>>>> >>>>> _______________________________________________ >>>>> Ietf mailing list >>>>> Ietf@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ietf >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ietf mailing list >>>> Ietf@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ietf >>> >> >> >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www1.ietf.org/mailman/listinfo/ietf > > -----BEGIN PGP SIGNATURE----- > > iD8DBQFHEDp5bjEdbHIsm0MRAslgAKDSi+UeR/OnCD1QiXbjIwbHB6RV/ACgqPve > GXSX3XJqDkWibCQ1NeuDivA= > =TqSH > -----END PGP SIGNATURE----- > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 13 05:17:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igclm-0004gN-No; Sat, 13 Oct 2007 04:54:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igcli-0004cw-64 for ietf@ietf.org; Sat, 13 Oct 2007 04:54:46 -0400 Received: from colo.trepanning.net ([69.55.226.174] helo=mail1.trepanning.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Igclg-0001nT-CX for ietf@ietf.org; Sat, 13 Oct 2007 04:54:46 -0400 Received: from www.trepanning.net (localhost [127.0.0.1]) by mail1.trepanning.net (Postfix) with ESMTP id 971661FA6108; Sat, 13 Oct 2007 01:54:43 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 13 Oct 2007 01:54:43 -0700 (PDT) Message-ID: <60478.69.12.173.8.1192265683.squirrel@www.trepanning.net> Date: Sat, 13 Oct 2007 01:54:43 -0700 (PDT) From: "Dan Harkins" To: "Marshall Eubanks" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad Cc: Fred Baker , IETF-Discussion Subject: Re: Travel Considerations X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Here we go.... Copious amounts of data...graphs...formulas...models...scientists predicting doom and humans are the cause. Where have I heard this before? Oh yea, the Club of Rome. Their copious amounts of data, graphs, models and formulas, predicted mass starvation and that economic growth would grind to a halt in the late 20th century. This was right before the largest peacetime expansion of the global economy in history! And wasn't there a coming Ice Age being predicted back then? It is quite anthrocentric to attribute things we cannot fully explain to humans but if humans are "increasing the amount of C02 in the atmosphere" and it is CO2 that is causing the increase in global warming then there is a simple thing each and everyone of us can do that will certainly make a "win" for the planet: stop breathing. Before anyone suggests I go first I will confirm suspicions that while I do not doubt that temperatures are rising I do doubt that human behavior can change it= . And while we're recommending books let me recommend the fantastic "The Vision of The Annointed: Self-Congratulation as a Basis for Social Policy" by Thomas Sowell, ISBN: 0-465-08994-1, Harper Collins. Dan. On Fri, October 12, 2007 10:55 pm, Marshall Eubanks wrote: > > On Oct 12, 2007, at 11:24 PM, Fred Baker wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I asked James this privately, but if we're going to get into an off- >> topic discussion of global warming, I'll ask it publicly to whoever >> has a good answer. >> >> >> We all agree that global warming is happening. If you go to the >> terminal moraine, the farthest south that the ice went doing the >> largest or perhaps the most recent ice age, and you don't see any >> ice, the earth is provably warmer than it once was. >> >> That said, do we not see ice at the terminal moraine because people >> drive SUVs, or because warming and cooling is something that has >> been happening since God created the earth? In the latter case, >> specifically what scientific evidence do we have that our current >> global warming event (which started in the 16th century, which was >> a mini-ice-age) is related to emissions? What scientific evidence >> do we have that changing emissions behavior will change global >> warming in any way? >> > > > > Dear Fred; > > As a physicist who worked a little in climate change in the late > 1980's, let me give a capsule answer and then shut up. I will look, > in turn, at the Greenhouse effect, at the CO2 changes, and at > possible effects of the ongoing human forcing of the climate. > > If the Earth's atmosphere did not trap heat, the mean surface > temperature would be well below freezing. This math is not too > difficult; you know the solar constant (input heating), mean albedo > and rotation rate (the Earth warms during the day, cools at night by > radiation) and you set up a spherically uniform model, which can be > solved analytically. Instead, the Earth's mean surface is above > freezing. (Supposedly, at this moment as I write the globally mean > surface temp is 6.72 C, but the annual average is more like 14 C. The > Northern hemisphere, having a good deal more land, dominates the > annual cycle.) The difference between observed and no-atmosphere > predicted mean temperatures for the Earth is about 40 C. > > This difference is caused by the so called "Greenhouse" effect, the > blockage of IR radiation out from the Earth's surface. (Actual > Greenhouses work mostly by stopping convection, not IR heat loss.) > This blockage is mostly due to CO2, but Methane (from cows!) and > other trace gases are also important, as is water vapor due to its > prevalence. The simple uniform models do a reasonable job predicting > the average lunar temperature; the lunar mean surface temperature is > -50 C, which shows what an atmosphere can do for you. > > Thus, there is no doubt of the existence of the Greenhouse effect; > not only does the physics work out approximately well not only for > the Earth and Moon, but also for Mars (a little Greenhouse, but > noticeable) and Venus. Venus is a very interesting case, being so > similar to the Earth in size and composition. On the Earth, CO2 is > mostly in certain rocks, like limestone, then dissolved in the > Oceans, then in the Atmosphere, by a relative proportion of roughly > >10,000:50:1. On Venus, a comparable amount of CO2 is all in the > atmosphere, and, as a result, the surface is very hot (mean > temperature ~ 460 C). This is _not_ primarily due it being closer to > the Sun, if it had terrestrial oceans and a terrestrial atmosphere, > it would be a temperate place. (By isotopic evidence Venus used to > have oceans, but it lost them - note that the rocks that contain CO2 > here would mostly give it up at 400+ C - apparently, once Venus > heated up all the CO2 went into the atmosphere and now it can never > cool down.) > > So, we have 4 objects (Earth, Moon, Venus, Mars), 3 of which have > Greenhouse effects, and for all 4 of which we can calculate the > observed surface temperatures reasonably well from fairly simple > first principles. So, I regard the greenhouse effect as about as well > proven as anything in planetary physics. > > You might have seen in the press that we just passed the 50th > anniversary of Sputnik 1; this being launched as part of the IGY. As > another part of the IGY, we started measuring CO2 from the top of > Mauna Loa, Hawaii, on a daily basis. This is not only the longest CO2 > measurement series, but it's also a good place to do it, as the top > of the volcano is above the local effects, and samples air mixed over > a good portion of the Northern hemisphere. These and other data show > without a doubt that the CO2 is rising, and match reasonably well > with estimates of human forcing. Other trace gases are also > important, and they are also increasing (such as methane from > increased beef production). > > Now, it is true that when you go a little further into the physics, > things get messy fast. There are sources and sinks of everything. (If > the top 50 meters of the oceans warm, will that increase or decrease > the dissolved CO2 ?Will increased CO2 make forests grow faster and > thus absorb more CO2 ? What about albedo from increased cloudiness ? > Etc. etc. etc.) It's also hard to measure things consistently over > decades. (For one of many examples, both the US and the USSR changed > the way they measured temperature for their weather services soon > after World War II, both in ways that caused biases in their > temperature series. That's a good part of the Northern hemisphere, > all messed up more or less at once.) And, as you say, there are > considerable natural climate variations, which could mask, confuse or > amplify any effects from human forcings. However, there are people > who worry about all of these things, and their models (the complexity > of the system requires numerical modeling to do anything detailed) > agree roughly with what's observed. > > So, to me the basic situation is pretty simple. You have a system > where the amount of CO2 and other trace gases in the atmosphere > controls the surface temperature. You (we) are increasing the amount > of CO2 and other trace gases in the atmosphere. The surface > temperature is going up, unusually so. This was predicted back in the > 1980's, if not before, which is always nice in any scientific test. > As far as I am concerned, this is all pretty conclusive and puts the > burden of proof on anyone who says that there is not any temperature > rise due to human forcing. > > It is as if someone started eating a lot more, and started gaining > weight. If they protested that their weight gain had nothing to do > with the increase in their diet, their Doctor would probably be > dubious, and would probably recommend a reduction in their intake. > >> What scientific evidence do we have that changing emissions >> behavior will change global warming in any way? > > That is a good question. A related one is, if we reduced or even > stopped emissions, would the CO2 go back to where it was before ? > That requires more models, but it seems that the answer is, not for a > good while (a century or so). > So, we are in for a ride, no matter what we do. > > The scary thing is that the climate is highly non-linear, and the > rough equivalent of congestive collapse (rapid change to a less > favorable state when certain conditions are met) is possible, as such > things have happened in the past. Our ability to model such rapid > state changes is poor, especially if they are unprecedented in recent > times. Note that things can go either way - model failures can under > or over predict what really happens. > > An example of this is the story of the Ozone hole. In the 1960's, > people started worrying about the effects of human produced gasses in > the upper atmosphere. There were some scare stories about the entire > Ozone layer going in a few decades. By the 1970's, the consensus was > that the situation wasn't so bad - the models showed that there just > wasn't enough Freon etc. up there to "eat" the entire Ozone layer. > The discovery of the Ozone hole over Antarctica was a complete > surprise. The models (due to the lack of computing resources back > then) had dealt mostly with global averages. No one had thought how > in the polar winter the polar atmosphere at altitude doesn't mix much > with lower latitudes. Ozone is formed by sunlight, of which there is > none during the polar winter. So, the Ozone over the pole sits with > Freon and other antagonists all winter long, and there is no > replenishment. In those conditions, there _is_ enough Freon etc. to > "eat" the local Ozone, and nothing to replace it, so a hole forms. > Now it is modeled reasonably well, but the models missed it then. > Likewise, there could be some bad things in store with the climate > not anticipated by the current modeling. > > Here is a paraphrase of what I said back in 1987, which I think is > still pretty sound : We are undertaking a vast unplanned experiment > in climate modification which could have unpleasant consequences. > Prudence would suggest that we take steps to mitigate these > consequences. To argue about what these steps should be is > reasonable, but to totally ignore the situation is not. > > Hope this helps. As I said before, I'll shut up about this now, at > least on this list. > > Regards > Marshall > > >> >> On Oct 13, 2007, at 12:03 AM, Dan Harkins wrote: >> >>> >>> Hi James, >>> >>> I think you're missing the point. I'm not advocating being wasteful >>> because everyone else is. I'm saying that this effort is futile and >>> will not result in _any_ "win" for the planet. Your analogy to >>> driving >>> an SUV is incorrect because not driving the SUV (or driving an >>> electric car instead) results in less emissions. A trivial amount but >>> every little bit helps. Flying 1000 people to Frankfurt instead of >>> Prague does not result in any less emissions. Encouraging other >>> organizations to follow our lead-- having 10000 people scattered over >>> the course of a year fly to a hub instead of through the hub to a >>> spoke-- won't either. The demand is still there to fly to places like >>> Prague and San Diego and airlines typically fly at less than 100% >>> capacity, sometimes significantly so. >>> >>> If you think there is an individual responsibility to change what >>> you can then please don't waste your effort on something that won't >>> have any effect! Do something that will make a difference. >>> >>> I for one would rather fly to (spoke) Prague than (hub) Frankfurt; >>> to (spoke) San Diego than to (hub) Chicago; and anywhere (spoke) on >>> God's green earth (yes, it's still green in spite of the IETF World >>> Tour) than (hub) London. >>> >>> Dan. >>> >>> On Fri, October 12, 2007 12:17 pm, James M. Polk wrote: >>>> Unfortunately, using this logic -- I can buy a tank and get 2 >>>> gallons-to-the-mile mileage because the rest of the planet (or at >>>> least America) is still buying SUVs that get horrible mileage too, >>>> since there will be nearly an unmeasurable difference to global >>>> warming if I drive my tank or not... so why not drive it anyway. >>>> >>>> There is an individual responsibility to change what we each can >>>> change to help. As an organization, we can have a greater positive >>>> affect if we reduce demand for such spoke flights by only flying to >>>> hub sites of major airlines -- if we're going to continue to meet in >>>> person. >>>> >>>> If other organizations see ours as an example, and do the same, then >>>> the positive affect is greater on us doing the right thing... >>>> >>>> Doing the right thing in mass has to start somewhere -- why does it >>>> have to start somewhere else here? >>>> >>>> It's Friday... >>>> >>>> At 01:30 PM 10/12/2007, Dan Harkins wrote: >>>> >>>>> You're assuming that if 1000 people decide not to fly to Prague >>>>> some weekend that the number of planes burning jet fuel to fly >>>>> there >>>>> will be different. I don't think so. >>>>> >>>>> Maybe you can start a "Boycott Prague The Spoke City" campaign >>>>> which, >>>>> if wildly successful, will reduce demand to fly there by some >>>>> discernable >>>>> amount and thereby reduce the number of planes flying there and the >>>>> amount >>>>> of jet fuel they would've burned. Well, as long as the planes >>>>> that aren't >>>>> flying to Prague aren't used to fly to Heathrow or Frankfurt or >>>>> some >>>>> other >>>>> hub city. Also doubtful. >>>>> >>>>> I do not intend on making ietf-discuss into a forum for >>>>> discussing >>>>> the pluses and minuses resulting from a degree centigrade >>>>> temperature >>>>> change but let me just say that "the planet wins" is a somewhat >>>>> dubious >>>>> statement. >>>>> >>>>> Dan. >>>>> >>>>> On Fri, October 12, 2007 7:32 am, Eric Burger wrote: >>>>>> Here is an interesting optimization problem: it turns out the most >>>>>> polluting part of a conference is people taking jets to fly to the >>>>>> conference. Minimize that and the planet wins. Favors hub cities >>>>> over >>>>>> spokes, like San Diego or Prague, where you "can't get there from >>>>> here", >>>>>> no matter where "here" is. >>>>>> >>>>>> See http://www.sciencemag.org/cgi/reprint/318/5847/36.pdf >>>>>> >>>>>> Notice: This email message, together with any attachments, may >>>>> contain >>>>>> information of BEA Systems, Inc., its subsidiaries and >>>>> affiliated >>>>>> entities, that may be confidential, proprietary, copyrighted >>>>> and/or >>>>>> legally privileged, and is intended solely for the use of the >>>>> individual >>>>>> or entity named in this message. If you are not the intended >>>>> recipient, >>>>>> and have received this message in error, please immediately return >>>>> this by >>>>>> email and then delete it. >>>>>> >>>>>> _______________________________________________ >>>>>> Ietf mailing list >>>>>> Ietf@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/ietf >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ietf mailing list >>>>> Ietf@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ietf >>>> >>> >>> >>> >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ietf >> >> -----BEGIN PGP SIGNATURE----- >> >> iD8DBQFHEDp5bjEdbHIsm0MRAslgAKDSi+UeR/OnCD1QiXbjIwbHB6RV/ACgqPve >> GXSX3XJqDkWibCQ1NeuDivA=3D >> =3DTqSH >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www1.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 13 06:58:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgeU8-0000Qi-Ls; Sat, 13 Oct 2007 06:44:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgeU6-0000Qd-VJ for ietf@ietf.org; Sat, 13 Oct 2007 06:44:42 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgeU1-0006uZ-NU for ietf@ietf.org; Sat, 13 Oct 2007 06:44:42 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 97293198683 for ; Sat, 13 Oct 2007 13:44:26 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 07C7D198658 for ; Sat, 13 Oct 2007 13:44:25 +0300 (EEST) Message-ID: <4710A188.5020100@piuha.net> Date: Sat, 13 Oct 2007 13:44:24 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: IETF-Discussion References: <28109.216.31.249.246.1192213828.squirrel@www.trepanning.net> <1080.216.31.249.246.1192223005.squirrel@www.trepanning.net> <72A3B0E4-9D7F-4897-98C2-3AEEC5ADD389@cisco.com> <6786A142-4D37-4B6C-BE0E-FC37794EC435@multicasttech.com> In-Reply-To: <6786A142-4D37-4B6C-BE0E-FC37794EC435@multicasttech.com> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: Re: Travel Considerations X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Please save the planet by working on a better Internet, not by posting to an off-topic mail thread. Jari _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 13 08:46:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igg6h-0007hR-Nn; Sat, 13 Oct 2007 08:28:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igg6f-0007gz-NJ for ietf@ietf.org; Sat, 13 Oct 2007 08:28:37 -0400 Received: from relay01.ispone.net.au ([124.254.72.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Igg6Y-0001iP-6O for ietf@ietf.org; Sat, 13 Oct 2007 08:28:37 -0400 Received: from dhs (124-254-82-173-static-dsl.ispone.net.au [124.254.82.173]) by relay01.ispone.net.au (8.13.6/8.13.6/Debian-1) with SMTP id l9DCS5rL015374 for ; Sat, 13 Oct 2007 22:28:06 +1000 Message-Id: <200710131228.l9DCS5rL015374@relay01.ispone.net.au> Received: (qmail 15504 invoked by uid 453); 13 Oct 2007 12:27:54 -0000 Received: from Unknown (HELO speedy) (192.168.0.8) by dhs (qpsmtpd/0.32) with ESMTP; Sat, 13 Oct 2007 22:27:51 +1000 From: "Darryl \(Dassa\) Lynch" To: "'IETF-Discussion'" Date: Sat, 13 Oct 2007 22:27:47 +1000 Organization: DHS International Pty Ltd MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgNiBPcyfJ0D7WYRF6EjMenfebHsgAC+Oiw In-Reply-To: <4710A188.5020100@piuha.net> X-Spam-Score: 1.5 (+) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: RE: Travel Considerations X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dassa@dhs.org List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Jari Arkko wrote: >> Please save the planet by working on a better Internet, not >> by posting to an off-topic mail thread. Perhaps the IETF should consider purchasing carbon credits for each standards track document produced :) Darryl (Dassa) Lynch _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 13 11:41:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igiku-0001wS-2g; Sat, 13 Oct 2007 11:18:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igiks-0001wN-Gt for ietf@ietf.org; Sat, 13 Oct 2007 11:18:18 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Igikl-0007Qj-OT for ietf@ietf.org; Sat, 13 Oct 2007 11:18:18 -0400 Received: from [192.168.0.2] (ppp-67-124-88-239.dsl.pltn13.pacbell.net [67.124.88.239]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l9DFHiLT012669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Oct 2007 08:17:45 -0700 Message-ID: <4710E196.5080000@dcrocker.net> Date: Sat, 13 Oct 2007 08:17:42 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 CC: IETF-Discussion References: <28109.216.31.249.246.1192213828.squirrel@www.trepanning.net> <1080.216.31.249.246.1192223005.squirrel@www.trepanning.net> <72A3B0E4-9D7F-4897-98C2-3AEEC5ADD389@cisco.com> <6786A142-4D37-4B6C-BE0E-FC37794EC435@multicasttech.com> In-Reply-To: <6786A142-4D37-4B6C-BE0E-FC37794EC435@multicasttech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: Re: Travel Considerations X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Marshall Eubanks wrote: > For this thread, perhaps you meant "you have been warmed." d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 13 18:31:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igp4o-0003Pc-3K; Sat, 13 Oct 2007 18:03:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igp4h-0003PH-RS; Sat, 13 Oct 2007 18:03:11 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Igp4b-0003dg-LG; Sat, 13 Oct 2007 18:03:11 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3AF18198683; Sun, 14 Oct 2007 01:02:54 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2BACB198658; Sun, 14 Oct 2007 01:02:46 +0300 (EEST) Message-ID: <4710FCC0.5090802@piuha.net> Date: Sat, 13 Oct 2007 12:13:36 -0500 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Cullen Jennings References: <470E0B1A.20507@cisco.com> <1EADBBE4-82AD-4B90-958B-EBB2A09585C6@cisco.com> In-Reply-To: <1EADBBE4-82AD-4B90-958B-EBB2A09585C6@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 1.4 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Bernard Aboba , Aaron Falk , IESG , Eliot Lear , ietf@ietf.org Subject: Re: Comments on draft-aboba-sg-experiment-03.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Eliot, >> I have one additional concern about this proposal. If a study group is >> intended to meet at an IETF, it will compete with slot requests both >> from IETF working groups and IRTF research groups. I wouldn't want to >> prohibit f2fs but I would certainly suggest that they come in low on the >> totem pole for space requests. Yes. I think I'd prefer to make the decision about having capacity for new officially recognized efforts (BOFs, SGs, WGs) at time that we're accepting these efforts. For instance, on my half of the area, I'd like have no more groups than what I can personally attend, without being in two or more places at the same time. (But lets not de-prioritize SGs (or BOFs) out of the meeting completely. The point of an official effort is that it gets attention, resources, etc; A judgment call by the AD/IESG/IAB/community that this attention is deserved in this particular case.) Jari _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 13 18:31:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igp4v-0003Vo-0G; Sat, 13 Oct 2007 18:03:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igp4t-0003VE-B0; Sat, 13 Oct 2007 18:03:23 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Igp4s-0003eM-4h; Sat, 13 Oct 2007 18:03:23 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 83A88198683; Sun, 14 Oct 2007 01:03:21 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 3C49F198658; Sun, 14 Oct 2007 01:03:16 +0300 (EEST) Message-ID: <47110056.70400@piuha.net> Date: Sat, 13 Oct 2007 12:28:54 -0500 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: "Olaf M. Kolkman" References: <5FCD348C-5927-4F18-A002-0E3BF21ED5F4@NLnetLabs.nl> In-Reply-To: <5FCD348C-5927-4F18-A002-0E3BF21ED5F4@NLnetLabs.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 1.4 (+) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: IAB IAB , The Internet Engineering Steering Group , IETF@ietf.org Subject: Re: Follow-up work on NAT-PT X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Thanks for this, Olaf. Indeed, we are considering follow-up work, and understanding the scenarios & possible need for producing a revised version of NAT-PT is on the Vancouver agenda (currently planned to be a discussion in V6OPS, with protocol work to fall out to an INT area WG). Jari _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Oct 14 09:03:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih2jz-0001EF-SA; Sun, 14 Oct 2007 08:38:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih2jz-0001BQ-9T for ietf@ietf.org; Sun, 14 Oct 2007 08:38:43 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ih2jp-0000Kr-Pp for ietf@ietf.org; Sun, 14 Oct 2007 08:38:34 -0400 Received: (qmail invoked by alias); 14 Oct 2007 12:38:32 -0000 Received: from p549861B9.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.97.185] by mail.gmx.net (mp005) with SMTP; 14 Oct 2007 14:38:32 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Oeyw5R8aO4zuzU6dKzFXRWhIE9stAk2UveGhEE2 uDbHVGUG0TCGJz Message-ID: <47120DC8.7090803@gmx.net> Date: Sun, 14 Oct 2007 15:38:32 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Bernard Aboba , 'Lakshminath Dondeti' References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: ietf@ietf.org Subject: More comments on draft-aboba-sg-experiment-03.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi Bernhard, Hi Lakshminath, I read through draft-aboba-sg-experiment-03.txt and have a few comments. I had a quick reply written and then I deleted everything again because I mainly struggled with two questions: * Pros/Cons of the SG + Some (or all) existing tools could be reused (Could also be done without a SG as well.) + Formal status within the IETF (Could be valuable in some interactions with other SDOs) - Risk of delaying work further and introducing even more formalism to the IETF. * What are the problems a SG could solve? The document is quite short on these aspects; it only says: " In some situations, while interest on the part of IETF participants and end-users may be evident, and the relevance to the Internet community may be demonstrated, the answer to other questions (such as an understanding of existing work, clarity or achievability of goals, or overlap with existing working groups or standards bodies) may not be as clear. " I really wonder whether these are truely the problems for unsuccessful BOFs. It would have been good to have meta-discussions after a BOF about why it wasn't successful and suggestions on how todo it better next time. The reasons for lack of success in a BOF are manifold. Some of them are listed in http://www.ietf.org/internet-drafts/draft-narten-successful-bof-03.txt. I am not convinced that a SG will help to improve something per-se. Last Thursday I attended the SAVA meeting in Helsinki (see http://mail.nrc.tsinghua.edu.cn/pipermail/sava/2007-October/000211.html). It was organized by Jari Arkko as an effort to help unexperienced guys with their attempt to bring some work to the IETF. (Note that's my own interpretation of Jari's intention here. He might have had other ideas in mind.) Sometimes it just seems to be better for some experienced IETF persons (e.g., IAB, IESG or other individuals) to help people with a BOF preparation effort. To me this seems to be far more efficient particularly since many BOFs fail due to the lack of "street credibility" by the folks initiating the work. Furthermore, I am not sure whether to start a SG after a BOF is the right thing todo. I personally would think that helping people earlier would be useful (e.g., after one or more Bar-BOFs). Hence, I wonder whether it would be useful todo the following: * Give the concept a name. "Study Group" is fine with me. * Start with with SG as early as possible; no need to wait for a failed BOF * Reuse the IETF tools (mailing lists, web pages, etc.). * Find a few knowledgeable IETF persons (who are interested to help -- and not delay or destroy efforts) and assign them as mentors to the preparation work. [Note: If you cannot find any experienced person to help then that's probably already an indication that something is really heading into the wrong direction.] Rather than putting this into the constraints of a working group I would intentionally leave this a bit "unregulated". This gives the participants more freedom to organize conference calls, f2f meetings, etc. and to announce them on the list without having long debates about whether it was sent with enough time in advance. Additionally, it would leave the group open to come up with other innovative ways to make progress. For example, at IETF#69 we had an adhoc meeting on SPIT prevention. In short, it was a disaster. We have a few solution approaches, we can envision a problem but we obviously do not have a lot of SPIT to determine whether the proposed mechanisms would help and which mechanism is more likely to be successful. The group of people working on the subject would obviously appreciate input from other IETF members on how we should move forward with the work since the work stalled a bit. This is a quite practical example and I would like to better understand how the proposals in draft-aboba-sg-experiment-03.txt could help me to make progress. I could also come up with a simpler example, based on the early warning adhoc meeting from IETF#69. It is a simpler case since we had constructive discussions and there was a lot of support for the work. Let me know if I should elaborate a bit more on this case if the above-mentioned one is too tough. In any case, if you come up with ways to work more efficiently then that's certainly great. Ciao Hannes _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Oct 14 15:11:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih8Wl-000870-0i; Sun, 14 Oct 2007 14:49:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih8Wi-0007q1-OB for ietf@ietf.org; Sun, 14 Oct 2007 14:49:24 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ih8WW-0001ul-IU for ietf@ietf.org; Sun, 14 Oct 2007 14:49:18 -0400 Received: from c-71-197-208-131.hsd1.or.comcast.net ([71.197.208.131] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1Ih8Vr-0006NI-TT; Sun, 14 Oct 2007 14:48:32 -0400 Received: by internaut.com (Postfix, from userid 1000) id B3FF68283A; Sun, 14 Oct 2007 11:48:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id A432682834; Sun, 14 Oct 2007 11:48:30 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.197.208.131 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/LiF6nO00H9nOfC/F+W4Nr Date: Sun, 14 Oct 2007 11:48:30 -0700 (PDT) From: Bernard Aboba To: Hannes Tschofenig In-Reply-To: <47120DC8.7090803@gmx.net> Message-ID: References: <47120DC8.7090803@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ietf@ietf.org Subject: Re: More comments on draft-aboba-sg-experiment-03.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > I am not sure whether to start a SG after a BOF is the right thing todo. Depending on the outcome of the BOF, it may or not be. A SG can only help if a problem important to the Internet community has been identified, if the problem is well understood, and if there is sufficient interest/energy to take on the work. > I personally would think that helping people earlier would be useful > (e.g., after one or more Bar-BOFs). > * Start with with SG as early as possible; no need to wait for a failed > BOF The SG experiment permits that at the AD's discretion. Personally, I would like to see how well this type of SG would work. > [Note: If you cannot find any experienced person to help then that's probably > already an indication that something is really heading into the wrong > direction.] This is part of the required "demonstration of interest" for SG formation, I would think. > For example, at IETF#69 we had an adhoc meeting on SPIT prevention. In short, > it was a disaster. > > We have a few solution approaches, we can envision a problem but we obviously > do not have a lot of SPIT to determine whether the proposed mechanisms would > help and which mechanism is more likely to be successful. > This is a quite practical example and I would like to better understand > how the proposals in draft-aboba-sg-experiment-03.txt could help me to make > progress. >From your description, it seems that there is not yet enough data to develop a problem statement, let alone to evaluate solutions. In such a situation, it seems that the most that could be accomplished would be to do a literature review, summarizing the state of the art and perhaps identifying problems for further research. I'm not clear that a SG would be the best avenue for that, due to the short duration. An IRTF RG might make more sense. > I could also come up with a simpler example, based on the early warning adhoc > meeting from IETF#69. It is a simpler case since we had constructive > discussions and there was a lot of support for the work. Of of the top of my head, this sounds like it could potentially be a better understood problem, for which the SG might be more relevant. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Oct 14 16:57:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhAGQ-0002JG-P0; Sun, 14 Oct 2007 16:40:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhAGP-0002In-39 for ietf@ietf.org; Sun, 14 Oct 2007 16:40:41 -0400 Received: from rv-out-0910.google.com ([209.85.198.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhAGE-0004OG-TV for ietf@ietf.org; Sun, 14 Oct 2007 16:40:37 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1143275rvb for ; Sun, 14 Oct 2007 13:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=dRgJFu3FjxAPyoa46t/AxXkYuH+9C8G2fDDNxxWnWsw=; b=kpFW0rQ9BHv+pnOsC6fk3cFmPCwEFbhIBTItZvGJNPXO1Tktyg07Jeu3V3lpMgqFl38yYL9G9o3F0gE4umANCUXNH0R2mIFQXVkNyfGDQH27KyrNW+GeVpTbj8kYDVbounDIlTbmsfqovc/l8zimMSBAGiiVkb2/TdYnIZiqyqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ov0v2x8qQh6ZxuYWwbEQULmLQmW0AZfrxp644/79KAkwUzQmBlW31s6iYdzrLzq6ZSC9sbCnWENUMWTw54KQCJv0pSzQO8j9RoJrOPN7O3IcE6X+pLJ4YPSRb8SD2jrNr3+3wSYokKE7/gHkl3PnWqS2mJvbxG2Y8vuFz9t1Fac= Received: by 10.114.14.1 with SMTP id 1mr6166767wan.1192394394793; Sun, 14 Oct 2007 13:39:54 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id l22sm6533548waf.2007.10.14.13.39.53 (version=SSLv3 cipher=RC4-MD5); Sun, 14 Oct 2007 13:39:54 -0700 (PDT) Message-ID: <47127E97.7020905@gmail.com> Date: Mon, 15 Oct 2007 09:39:51 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jun-ichiro itojun Hagino References: <470E7CD5.3000209@gmail.com> <20071012032758.4E4F7233C5@coconut.itojun.org> In-Reply-To: <20071012032758.4E4F7233C5@coconut.itojun.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ietf@ietf.org Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-12 16:27, Jun-ichiro itojun Hagino wrote: >> On 2007-10-11 23:46, Jun-ichiro itojun Hagino wrote: >>>> Not viewed from the socket programmer's point of view. >>>> Look at how an AF_INET6 socket behaves when given >>>> an address like ::FFFF:192.0.2.3 >>>> afaik the behavior is then exactly what you describe. >>>> Whether the stacks are independent code modules or >>>> alternate paths through the same code is irrelevant >>>> to the externally observed behavior. >>> see draft-ietf-v6ops-security-overview-06.txt section 2.2. >> Sure. I absolutely don't like to see ::FFFF/96 on the wire. > > then we'd have to deprecate SIIT at least. still, you cannot be sure > that ::ffff:0:0/96 are not on the wire. I agree, it just isn't obvious that such packets will be delivered... Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 15 04:35:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhLB0-0003mp-Ct; Mon, 15 Oct 2007 04:19:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhLAw-0003iz-QF for ietf@ietf.org; Mon, 15 Oct 2007 04:19:46 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IhLAq-0006we-GU for ietf@ietf.org; Mon, 15 Oct 2007 04:19:46 -0400 Received: (qmail invoked by alias); 15 Oct 2007 08:19:26 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp038) with SMTP; 15 Oct 2007 10:19:26 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19BaB14Rd5B1GCCft/ETfVMphCjBMm9sde/qBCyxL ieOyHwkwYQ/yHh Message-ID: <4713228C.1040307@gmx.net> Date: Mon, 15 Oct 2007 11:19:24 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Bernard Aboba References: <47120DC8.7090803@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ietf@ietf.org Subject: Re: More comments on draft-aboba-sg-experiment-03.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi Bernhard, ~snip~ >> For example, at IETF#69 we had an adhoc meeting on SPIT prevention. In short, >> it was a disaster. >> >> We have a few solution approaches, we can envision a problem but we obviously >> do not have a lot of SPIT to determine whether the proposed mechanisms would >> help and which mechanism is more likely to be successful. >> This is a quite practical example and I would like to better understand >> how the proposals in draft-aboba-sg-experiment-03.txt could help me to make >> progress. >> > > >From your description, it seems that there is not yet enough data to > develop a problem statement, let alone to evaluate solutions. Right. As you know from the Email spam the problem is only that waiting longer makes the problem substantially harder to solve later. In some sense this is similar to security in general. To make it more complicated it might not provide you a lot of additional insight when you know how the current attacks look like. The future ones will be different anyway. > In such a > situation, it seems that the most that could be accomplished would be to > do a literature review, We did this already. Most existing documents just say what has been stated in various IETF drafts already. > summarizing the state of the art and perhaps > identifying problems for further research. I am not sure whether it is such a big research topic. If you, for example, look at XMPP then these folks have already published a lot of their specifications to deal with this subject. They are far ahead of the IETF crowd. They just do it and then figure out whether it helps or not. The worst thing that can happen is that it does not get implemented when people don't think it isn't useful. > I'm not clear that a SG would > be the best avenue for that, due to the short duration. An IRTF RG might > make more sense. > I am not so sure about the value of IRTF groups. > >> I could also come up with a simpler example, based on the early warning adhoc >> meeting from IETF#69. It is a simpler case since we had constructive >> discussions and there was a lot of support for the work. >> > > Of of the top of my head, this sounds like it could potentially be a > better understood problem, for whichthe SG might be more relevant. > Good to know. Maybe we have a potential candidate for a SG experiment here. I guess I would also like to see the outcome of this experiment. I wonder what you think about my other suggestions that go more along the lines of "providing help from experienced people"? Do you think that this will automatically happen as soon as a SG is formed? I don't think so. Ciao Hannes _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 15 09:23:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhPYO-0001Fj-31; Mon, 15 Oct 2007 09:00:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhPYL-0001Ct-6D for ietf@ietf.org; Mon, 15 Oct 2007 09:00:13 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhPYF-0001zY-B8 for ietf@ietf.org; Mon, 15 Oct 2007 09:00:07 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IhPXZ-0005P7-2f for ietf@ietf.org; Mon, 15 Oct 2007 12:59:25 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Oct 2007 12:59:25 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Oct 2007 12:59:25 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: "Frank Ellermann" Date: Mon, 15 Oct 2007 14:51:38 +0200 Lines: 72 Message-ID: References: <2788466ED3E31C418E9ACC5C316615570534E4@mou1wnexmb09.vcorp.ad.vrsn.com><6.2.5.6.2.20071004111028.031d08e0@resistor.net><3D19D707-31B1-4753-8B33-2F9761A5451A@mail-abuse.org><41DFA083-E582-4A09-9C6D-A73EB5E93BA0@mail-abuse.org> <74C293FF-7E90-44F1-B4F0-55E3B10D48D9@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: Re: TMDA backscatter X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Douglas Otis wrote: > By using the local-part in a spam campaign, one cached SPF record > is able to reference an unlimited sequence of MX records. In theory IANA could publish one _spf.arpa "v=3Dspf1 mx a aaaa -all" record, and everybody could use it with "v=3Dspf1 redirect=3D_spf.arpa". That one SPF record can (kind of) reference an unlimited number of MX records doesn't depend on SPF's local-part macro. =20 And e-mail providers wishing to offer "per user policies" could also create corresponding subdomains replacing local@domain.example=20 addresses by say user@local.domain.example addresses. Likewise=20 attackers trying to cause havoc can use user@local.domain.example addresses, they don't need SPF's local part macro for this purpose. After all in your attack scenario it's the attacker who controls the MX records pointing to bogus addresses in the zone of the victim. > Spammers often send messages continuously. A spam campaign can > come from any source, purport to be from any domain, and yet attack > the same innocent victim which can not be identified by examining > the message. Your attack scenario has nothing to with a spam campaign, the goal of a spam campaign is to send unsolicited mails to receivers. The goal of your attack scenario is to flood a zone with bogus and huge A or AAAA queries. And in your scenario the mail cannot purport to come from any domain, it has to come from domains under the control of the attacker where he manages his bogus MX records. > Compared to an SPF related attack, most auto-replies will consume > a greater amount of an attackers resources, identify the source > of the attack, and not achieve the same level of amplification. Backscatter doesn't consume resources of the spammer (apart from sending the UBE with a forged envelope sender address), and it can be "mail from" any "plausible" address, not identifying the real source. That's precisely the problem solved by SPF FAIL and PASS. > SPF enables a long duration DDoS attack. Sorry, from my POV you still arrive at "MX records can be abused", not limited to SPF (or rather only limited if done using SPF). > Block all SPF records? At least we won't need a new rfc-ignorant zone to implement this=20 proposal... ;-) =20 >> Maybe you should propose some "MX processing limits" for 2821bis. =20 > Most systems are fairly careful about where they send messages to =20 > avoid being blocked, nor would the normal use of MX records require =20 > all targets be resolved. Timeouts recommended by RFC2821 ensure this = > operation remains fairly safe, unlike that for SPF. Even the packet =20 > limitation of DNS provides a fairly reasonable limit. I'm not sure that "call back verification" schemes follow the "sending strategy" (4.5.4.1) in RFC 2821, after all they don't send any DATA. You could squeeze quite a lot of names in the reply to an MX query, that's why SPF has an explicit limit 10. SMTP also doesn't specify size limits for MX queries. > DKIM can be processed prior to acceptance Yes, but unlike SPF not before DATA. I skip the "anti-phishing" discussion because it's not directly related to "backscatter". Frank _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 15 12:39:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhSp1-0001sN-4N; Mon, 15 Oct 2007 12:29:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhSoz-0001lg-NZ for ietf@ietf.org; Mon, 15 Oct 2007 12:29:37 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhSol-0008OH-0D for ietf@ietf.org; Mon, 15 Oct 2007 12:29:29 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l9FGPtDV007714; Mon, 15 Oct 2007 09:25:55 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 09:28:48 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 15 Oct 2007 09:28:47 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557084EBF@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The IETF duty for Carbon emissions, energy use &ct. Thread-Index: AcgNBXKA7FziYFrATNSMTW9SnKPK4QAAOACQAI8T23I= References: <28109.216.31.249.246.1192213828.squirrel@www.trepanning.net> <941D5DCD8C42014FAF70FB7424686DCF01C26BAA@eusrcmw721.eamcs.ericsson.se> From: "Hallam-Baker, Phillip" To: "Eric Gray" , "James M. Polk" , "Dan Harkins" , "Eric Burger" X-OriginalArrivalTime: 15 Oct 2007 16:28:48.0562 (UTC) FILETIME=[76D26120:01C80F48] X-Spam-Score: -2.2 (--) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: ietf@ietf.org Subject: The IETF duty for Carbon emissions, energy use &ct. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1026646987==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============1026646987== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80F48.764A8D67" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80F48.764A8D67 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think that whole conversation is missing the point. While one = conference with one and a half thousand participants has a significant = carbon footprint the more significant issue is the net impact of = Internet technology. We can do far more by enabling changes in the = behavior of the billion plus Internet users than our own use. Whether your objective is to reduce carbon emissions because of global = warming concerns or reduce dependence on fossil fuels that are = increasingly in short supply, there is a real incentive to reduce energy = use.=20 Here are some options: 1) Teleconferencing that works. If teleconferencing actually worked the need to hold face to face = meetings would be reduced. By work I mean really work, not almost, not = provided there is no NAT, not provided the firewall has pinhole router = configuration. Today this is simply not the case, in fact it is pretty = much impossible to get the software providers to even tell you which = ports they use. For fun try to find the information on Microsoft's site. This one is in scope for the IETF. 2) Enable better power management.=20 While I do not believe the claims that the Internet takes 9% of the US = energy supply, data centers are increasingly power hungry and the cost = of electricity and equally important, cooling is a major factor in = decisions to locate new data centers. Despite this, most data centers = operate far below peak capacity and even when a data center is operating = at 'capacity' the majority of the actual servers are not, only the ones = that are the bottleneck. Make it possible to spin up additional machines as needed to respond to = increases in demand and standby machines can be powered down. Certain approaches are in scope for IETF, others are not. 3) Removal of waste heat Today most data centers use active cooling, albeit in a pretty = inefficient fashion. Air is cooled to room temperature using = refrigeration equipment, blown through the racks and the waste heat = expelled into the atmosphere. So we use vast amounts of energy to make = heat and then use more energy to vent it to the atmosphere. First problem here is that air is not an efficient means of heat = transfer, its loud and you have to use air at human-comfortable = temperatures. This means that your racks are always going to be warm. = Cool racks are more reliable than hot ones. Passive technology such as heat pipes are much more attractive. I = believe that future data centers will be built around equipment racks = that contain separate busses for low voltage power, network and heat = elimination. The heat busses will connect together to form a cooling = grid for the machine room which will in turn vent to the outside air. = Rather than using energy to expel the heat the process could be used to = extract energy, even though the heat is low grade (below boiling point = of water at atmospheric pressure) it is clean. Getting the temperature down below the external ambient temperature = would require an energy input of course, that might make sense if you = were going to go to a really low temperature and overclock your way out = of a performance crunch (i.e. liquid nitrogen temperatures). This one is out of scope for the IETF, in fact its pretty much out of = scope everywhere at the moment, its one of those issues that falls = between the cracks of mechanical engineering and electrical. There are = plenty of folk who think about these issues on the small scale but = rather fewer thinking about what a data center built around these ideas = would look like. ------_=_NextPart_001_01C80F48.764A8D67 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Travel Considerations=0A= =0A= =0A= =0A=

I think that whole conversation is missing the point. While one = conference with one and a half thousand participants has a significant = carbon footprint the more significant issue is the net impact of = Internet technology. We can do far more by enabling changes in the = behavior of the billion plus Internet users than our own use.

=0A=

Whether your objective is to reduce carbon emissions because of = global warming concerns or reduce dependence on fossil fuels that are = increasingly in short supply, there is a real incentive to reduce energy = use.

=0A=

Here are some options:

=0A=

1) Teleconferencing that works.

=0A=

If teleconferencing actually worked the need to hold face to face = meetings would be reduced. By work I mean really work, not almost, not = provided there is no NAT, not provided the firewall has pinhole router = configuration. Today this is simply not the case, in fact it is pretty = much impossible to get the software providers to even tell you which = ports they use. For fun try to find the information on Microsoft's = site.

=0A=

This one is in scope for the IETF.

=0A=

2) Enable better power management.

=0A=

While I do not believe the claims that the Internet takes 9% of the = US energy supply, data centers are increasingly power hungry and the = cost of electricity and equally important, cooling is a major factor in = decisions to locate new data centers. Despite this, most data centers = operate far below peak capacity and even when a data center is operating = at 'capacity' the majority of the actual servers are not, only the ones = that are the bottleneck.

=0A=

Make it possible to spin up additional machines as needed to respond = to increases in demand and standby machines can be powered down.

=0A=

Certain approaches are in scope for IETF, others are not.

=0A=

3) Removal of waste heat

=0A=

Today most data centers use active cooling, albeit in a pretty = inefficient fashion. Air is cooled to room temperature using = refrigeration equipment, blown through the racks and the waste heat = expelled into the atmosphere. So we use vast amounts of energy to make = heat and then use more energy to vent it to the atmosphere.

=0A=

First problem here is that air is not an efficient means of heat = transfer, its loud and you have to use air at human-comfortable = temperatures. This means that your racks are always going to be warm. = Cool racks are more reliable than hot ones.

=0A=

Passive technology such as heat pipes are much more attractive. I = believe that future data centers will be built = around equipment racks that contain separate busses = for low voltage power, network and heat elimination. The heat = busses will connect together to form a cooling grid for the machine room = which will in turn vent to the outside air. Rather than using = energy to expel the heat the process could be used to extract energy, = even though the heat is low grade (below boiling point of water at = atmospheric pressure) it is clean.

=0A=

Getting the temperature down below the external ambient temperature = would require an energy input of course, that might make sense if you = were going to go to a really low temperature and overclock your way out = of a performance crunch (i.e. liquid nitrogen temperatures).

=0A=

This one is out of scope for the IETF, in fact its pretty much out of = scope everywhere at the moment, its one of those issues that falls = between the cracks of mechanical engineering and electrical. There are = plenty of folk who think about these issues on the small scale but = rather fewer thinking about what a data center built around these ideas = would look like.

------_=_NextPart_001_01C80F48.764A8D67-- --===============1026646987== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============1026646987==-- From ietf-bounces@ietf.org Mon Oct 15 13:47:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhTlI-00089F-CE; Mon, 15 Oct 2007 13:29:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhTlG-00086F-6v for ietf@ietf.org; Mon, 15 Oct 2007 13:29:50 -0400 Received: from mailhost.jlc.net ([199.201.159.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhTlD-0007Li-S1 for ietf@ietf.org; Mon, 15 Oct 2007 13:29:48 -0400 Received: by mailhost.jlc.net (Postfix, from userid 104) id 940B123F0C5; Mon, 15 Oct 2007 13:29:40 -0400 (EDT) Date: Mon, 15 Oct 2007 13:29:39 -0400 From: John Leslie To: "Hallam-Baker, Phillip" Message-ID: <20071015172939.GP67213@verdi> References: <941D5DCD8C42014FAF70FB7424686DCF01C26BAA@eusrcmw721.eamcs.ericsson.se> <2788466ED3E31C418E9ACC5C31661557084EBF@mou1wnexmb09.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2788466ED3E31C418E9ACC5C31661557084EBF@mou1wnexmb09.vcorp.ad.vrsn.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ietf@ietf.org Subject: Re: The IETF duty for Carbon emissions, energy use &ct. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hallam-Baker, Phillip wrote: > > Whether your objective is to reduce carbon emissions because of > global warming concerns or reduce dependence on fossil fuels that are > increasingly in short supply, there is a real incentive to reduce > energy use. > > If teleconferencing actually worked the need to hold face to face > meetings would be reduced. I am constantly surprised how little interest there is within IETF for teleconferecing that works well. > By work I mean really work, not almost, not provided there is no NAT, > not provided the firewall has pinhole router configuration. These are all "security" issues, for which we could find end-runs. The problem I see is that we just don't care. :^( -- John Leslie _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 15 13:53:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhU2y-0000jd-5a; Mon, 15 Oct 2007 13:48:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhU2w-0000DP-6x for ietf@ietf.org; Mon, 15 Oct 2007 13:48:06 -0400 Received: from robin.verisign.com ([65.205.251.75]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhU2l-00081x-Fd for ietf@ietf.org; Mon, 15 Oct 2007 13:47:56 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l9FHivfl011250; Mon, 15 Oct 2007 10:44:57 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 10:47:50 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 15 Oct 2007 10:47:49 -0700 Message-ID: <2788466ED3E31C418E9ACC5C316615570462C4@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The IETF duty for Carbon emissions, energy use &ct. Thread-Index: AcgPUPleW7aqdu6RTSm1Tt/RyFNwzQAAocUH From: "Hallam-Baker, Phillip" To: "John Leslie" X-OriginalArrivalTime: 15 Oct 2007 17:47:50.0065 (UTC) FILETIME=[80FA5210:01C80F53] X-Spam-Score: -4.0 (----) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: ietf@ietf.org Subject: Re: The IETF duty for Carbon emissions, energy use &ct. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0480512253==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============0480512253== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80F53.808F5595" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80F53.808F5595 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So often what appears to be a security issue is simply failing to = account for the security issues in the design. In this case it is also a failure to understand the internet as a = system.=20 Sent from my GoodLink Wireless Handheld (www.good.com) -----Original Message----- From: John Leslie [mailto:john@jlc.net] Sent: Monday, October 15, 2007 10:29 AM Pacific Standard Time To: Hallam-Baker, Phillip Cc: ietf@ietf.org Subject: Re: The IETF duty for Carbon emissions, energy use &ct. Hallam-Baker, Phillip wrote: >=20 > Whether your objective is to reduce carbon emissions because of > global warming concerns or reduce dependence on fossil fuels that are > increasingly in short supply, there is a real incentive to reduce > energy use.=20 >=20 > If teleconferencing actually worked the need to hold face to face > meetings would be reduced. I am constantly surprised how little interest there is within IETF for teleconferecing that works well. > By work I mean really work, not almost, not provided there is no NAT, > not provided the firewall has pinhole router configuration. These are all "security" issues, for which we could find end-runs. The problem I see is that we just don't care. :^( -- John Leslie ------_=_NextPart_001_01C80F53.808F5595 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: The IETF duty for Carbon emissions, energy use = &ct.

So often what appears to be a security issue is simply = failing to account for the security issues in the design.

In this case it is also a failure to understand the internet as a = system.

Sent from my GoodLink Wireless Handheld (www.good.com)

 -----Original Message-----
From:   John Leslie [mailto:john@jlc.net]
Sent:   Monday, October 15, 2007 10:29 AM Pacific Standard = Time
To:     Hallam-Baker, Phillip
Cc:     ietf@ietf.org
Subject:        Re: The IETF duty for = Carbon emissions, energy use &ct.

Hallam-Baker, Phillip <pbaker@verisign.com> wrote:
>
> Whether your objective is to reduce carbon emissions because of
> global warming concerns or reduce dependence on fossil fuels that = are
> increasingly in short supply, there is a real incentive to = reduce
> energy use.
>
> If teleconferencing actually worked the need to hold face to = face
> meetings would be reduced.

   I am constantly surprised how little interest there is = within IETF
for teleconferecing that works well.

> By work I mean really work, not almost, not provided there is no = NAT,
> not provided the firewall has pinhole router configuration.

   These are all "security" issues, for which we = could find end-runs.
The problem I see is that we just don't care. :^(

--
John Leslie <john@jlc.net>

------_=_NextPart_001_01C80F53.808F5595-- --===============0480512253== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0480512253==-- From ietf-bounces@ietf.org Mon Oct 15 14:47:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhUmM-0003RX-R0; Mon, 15 Oct 2007 14:35:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhUmK-0003Mx-P6 for ietf@ietf.org; Mon, 15 Oct 2007 14:35:00 -0400 Received: from harry.mail-abuse.org ([168.61.5.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhUmD-0001PG-Qj for ietf@ietf.org; Mon, 15 Oct 2007 14:34:54 -0400 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id EFEB041461; Mon, 15 Oct 2007 11:34:52 -0700 (PDT) In-Reply-To: References: <2788466ED3E31C418E9ACC5C316615570534E4@mou1wnexmb09.vcorp.ad.vrsn.com><6.2.5.6.2.20071004111028.031d08e0@resistor.net><3D19D707-31B1-4753-8B33-2F9761A5451A@mail-abuse.org><41DFA083-E582-4A09-9C6D-A73EB5E93BA0@mail-abuse.org> <74C293FF-7E90-44F1-B4F0-55E3B10D48D9@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7FC3C2FA-AB7B-406F-8575-5EF4F31A9B81@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Date: Mon, 15 Oct 2007 11:35:03 -0700 To: Frank Ellermann X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: ietf list Subject: Re: TMDA backscatter X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 15, 2007, at 5:51 AM, Frank Ellermann wrote: > Douglas Otis wrote: > >> By using the local-part in a spam campaign, one cached SPF record >> is able to reference an unlimited sequence of MX records. > > In theory IANA could publish one _spf.arpa "v=spf1 mx a aaaa -all" > record, and everybody could use it with "v=spf1 > redirect=_spf.arpa". That one SPF record can (kind of) reference an > unlimited number of MX records doesn't depend on SPF's local-part > macro. This adds perhaps 21 useless DNS transactions for each email received? Do you expect everyone to use inbound servers to send? > And e-mail providers wishing to offer "per user policies" could > also create corresponding subdomains replacing local@domain.example > addresses by say user@local.domain.example addresses. Likewise > attackers trying to cause havoc can use user@local.domain.example > addresses, they don't need SPF's local part macro for this purpose. > > After all in your attack scenario it's the attacker who controls > the MX records pointing to bogus addresses in the zone of the victim. Use of MX records are normally predicated upon the sending of messages. When sending a message, MX records may have a potential DNS traffic amplification of about 10. However, overall amplification is much less when a message triggers an automated response. An automated response is likely to be filtered, and the sender risks being blocked, whether or not the MX record is doing something nefarious. Many situations can achieve this level of network amplification. However, SPF's macros transforms a spam related attack into being completely free without tainting the messages. Sending spam should be considered a given as it represents a large portion of today's traffic. SPF permits an enormous amount of DNS traffic to be directed toward an innocent, uninvolved domain. Once the attack duration exceeds a recipient's negative caching, no additional resources of the attacker are consumed! The attack can come from anywhere, is not easily traced, and, beyond universal banning of SPF records, there is no defence! ACLs on DNS will not help, nor will BCP 38. This attack is likely to continue for a long duration. >> Spammers often send messages continuously. A spam campaign can >> come from any source, purport to be from any domain, and yet >> attack the same innocent victim which can not be identified by >> examining the message. > > Your attack scenario has nothing to with a spam campaign, the goal > of a spam campaign is to send unsolicited mails to receivers. The > goal of your attack scenario is to flood a zone with bogus and huge > A or AAAA queries. And in your scenario the mail cannot purport to > come from any domain, it has to come from domains under the control > of the attacker where he manages his bogus MX records. SPF adds a layer of indirection. SPF allows the local-part of spam to generate DNS transactions without consuming additional resources of attackers once their SPF record has been cached! The attack can then query any MX, A, AAAA, PTR, and TXT records from any domain unrelated to message content. Even the attacking MX record might be unrelated to any domain found within the message. SPF's added indirection provides spammers a complete disguise. Recipients using SPF are to know which messages are staging an attack. This is true even when they do not wish to play a role in a reported ongoing attack. Expect spammers to take advantage of this generous SPF gift. : ( >> Compared to an SPF related attack, most auto-replies will consume >> a greater amount of an attackers resources, identify the source of >> the attack, and not achieve the same level of amplification. > > Backscatter doesn't consume resources of the spammer (apart from > sending the UBE with a forged envelope sender address), and it can > be "mail from" any "plausible" address, not identifying the real > source. That's precisely the problem solved by SPF FAIL and PASS. RFC3464 represents a far better solution as it removes incentives. >> SPF enables a long duration DDoS attack. > > Sorry, from my POV you still arrive at "MX records can be abused", > not limited to SPF (or rather only limited if done using SPF). Of course MX records can be abused. SPF increases the potential level of abuse by a factor of 10 or 20. With SPF macro's, abuse also becomes completely free. >> Block all SPF records? > > At least we won't need a new rfc-ignorant zone to implement this > proposal... ;-) Prevention might require DNS servers be modified to exclude SPF records. Do not expect compliance without some form of blocking imposed. >>> Maybe you should propose some "MX processing limits" for 2821bis. > >> Most systems are fairly careful about where they send messages to >> avoid being blocked, nor would the normal use of MX records >> require all targets be resolved. Timeouts recommended by RFC2821 >> ensure this operation remains fairly safe, unlike that for SPF. >> Even the packet limitation of DNS provides a fairly reasonable limit. > > I'm not sure that "call back verification" schemes follow the > "sending strategy" (4.5.4.1) in RFC 2821, after all they don't send > any DATA. Call back verification is not part of RFC2821? > You could squeeze quite a lot of names in the reply to an MX query, > that's why SPF has an explicit limit 10. SMTP also doesn't specify > size limits for MX queries. > >> DKIM can be processed prior to acceptance > > Yes, but unlike SPF not before DATA. I skip the "anti-phishing" > discussion because it's not directly related to "backscatter". Other solutions are able to prevent the DATA phase for spam. : ) -Doug _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 15 15:02:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhV6C-0000p0-J9; Mon, 15 Oct 2007 14:55:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhV69-0000nB-Uv for ietf@ietf.org; Mon, 15 Oct 2007 14:55:29 -0400 Received: from parsley.amaranth.net ([204.10.1.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhV64-0006tJ-Jk for ietf@ietf.org; Mon, 15 Oct 2007 14:55:29 -0400 Received: from Clary.senie.com ([192.168.8.126]) (authenticated bits=0) by parsley.amaranth.net (8.12.11.20060308/8.12.11) with ESMTP id l9FIshJe022814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Oct 2007 14:54:46 -0400 Message-Id: <200710151854.l9FIshJe022814@parsley.amaranth.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 15 Oct 2007 14:54:26 -0400 To: ietf@ietf.org From: Daniel Senie In-Reply-To: <20071015172939.GP67213@verdi> References: <941D5DCD8C42014FAF70FB7424686DCF01C26BAA@eusrcmw721.eamcs.ericsson.se> <2788466ED3E31C418E9ACC5C31661557084EBF@mou1wnexmb09.vcorp.ad.vrsn.com> <20071015172939.GP67213@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-666D2D0B X-Virus-Scanned: ClamAV 0.91.2/4540/Sat Oct 13 21:43:55 2007 on parsley.amaranth.net X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: Re: The IETF duty for Carbon emissions, energy use &ct. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 01:29 PM 10/15/2007, John Leslie wrote: >Hallam-Baker, Phillip wrote: > > > > Whether your objective is to reduce carbon emissions because of > > global warming concerns or reduce dependence on fossil fuels that are > > increasingly in short supply, there is a real incentive to reduce > > energy use. > > > > If teleconferencing actually worked the need to hold face to face > > meetings would be reduced. > > I am constantly surprised how little interest there is within IETF >for teleconferecing that works well. Indeed. I raised this point over the years. Even offering to pay a "remote attendance fee" if there were in fact the ability to see and hear sessions, and participate. The IETF for many years crowed about the Mbone connectivity as being innovative, but got stuck there, and didn't progress when comercial solutions bypassed that flawed technology. > > By work I mean really work, not almost, not provided there is no NAT, > > not provided the firewall has pinhole router configuration. > > These are all "security" issues, for which we could find end-runs. >The problem I see is that we just don't care. :^( Indeed, we can all use various conferencing methods today, which all work regardless of firewalls, whether incorporating NAT or not. But of course those technologies were not born of the IETF. The marketplace notwithstanding, those approaches are given less credence. Perhaps if the IETF did have to consider its carbon footprint in its meeting planning, those ideas would be given some credence. I rarely get on airplanes any more, and so have not been to an IETF meeting in some time. The "appearance of security" in place to harass the public and make us feel safe as un-screened cargo is loaded into cargo holds below your feet is not worth the aggrivation. My vote is to cut my own carbon footprint by not flying. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 15 15:16:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhVIq-0007U0-Qd; Mon, 15 Oct 2007 15:08:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhVIo-0007RB-7n for ietf@ietf.org; Mon, 15 Oct 2007 15:08:34 -0400 Received: from smtp137.iad.emailsrvr.com ([207.97.245.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhVIm-0002p4-MC for ietf@ietf.org; Mon, 15 Oct 2007 15:08:34 -0400 Received: from relay3.r3.iad.emailsrvr.com (localhost [127.0.0.1]) by relay3.r3.iad.emailsrvr.com (SMTP Server) with ESMTP id 70C0744CB62; Mon, 15 Oct 2007 15:08:32 -0400 (EDT) Received: by relay3.r3.iad.emailsrvr.com (Authenticated sender: rpelletier-AT-isoc.org) with ESMTP id CD94544C184; Mon, 15 Oct 2007 15:08:31 -0400 (EDT) Message-ID: <4713BAFB.1020303@isoc.org> Date: Mon, 15 Oct 2007 15:09:47 -0400 From: Ray Pelletier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, zh, zh-cn, zh-hk, zh-sg, zh-tw, ja MIME-Version: 1.0 To: The IESG , IAB , IAOC , IETF Discussion Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Subject: RFP: IESG I-D Tracker Pythin Conversion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org The IETF Administrative Oversight Committee (IAOC) on behalf of the IETF announces this Request for Proposal for Software Development services. The Internet Society (ISOC) is the contractor. The project is to port an existing Perl-based application, the IESG I-D Tracker to Python with the Django framework. The IAOC shall select from among those submitting proposals those which in its discretion it feels are the most qualified to perform the work. Those making the short list shall receive the code upon which to base its final proposal containing cost and timeline. Bidders will then have 7 days to submit their final proposal. A read-only view of a subset of the information of the current IETF workflow application ("Existing Application") can be inspected at https://datatracker.ietf.org/idtracker/ The Application itself will be provided to those who are selected for the short list by the IAOC. The Replacement Application must be conform to the following requirements. Each Proposal must describe the technical features of the Replacement Application that will be used to implement the following requirements: 1. The Replacement Application should retain the same functionality, database structure and "look and feel" as the Existing Application to the greatest extent possible. Any proposed reduction in functionality must be described in the Final Proposal. 2. The Existing Application maintains metadata about a document, including a state machine and ballot positions from evaluators. There is also an administrative interface, which allows the administrator to record ballot positions that are provided offline and maintain additional data. 3. All actions on a document are logged in a comment log and emailed to a list of interested parties. In addition, certain workflow actions cause a template email to be sent to a wider audience (e.g., IETF Last Call, or document approval messages). 4. The Existing Application is currently implemented in ~6000 lines of perl, which will be provided for reference to those making the short list. A read-only view is already implemented in Django, and it is expected that this view will be reused with edit options for items that the logged-in user is permitted to edit. Django models for many of the relevant database tables already exist, but may have to be augmented for this work. 5. The code must be readable and have adequate comments. Design documentation which enables later developers to understand and continue working with the delivered code must be provided. All software will be delivered in source code, and executable forms if applicable. Timeline 15 October RFP announced 19 October Questions due 26 October Proposals submitted 30 October Vendors on Short List notified 9 November Final Proposals submitted The sole point of contact regarding this RFP is the IETF Administrative Director (IAD). All questions or inquiries must be submitted in writing and must be received no later than midnight ET, October 19, 2007. Questions or inquiries will be accepted by email at rpelletier@isoc.org. Responses to questions and inquiries shall be posted on the IETF Administrative Support Activity (IASA) website, iaoc.ietf.org, no later than October 23, 2007. Ray Pelletier IETF Administrative Director _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 15 16:48:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhWaB-00013a-Mw; Mon, 15 Oct 2007 16:30:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhWa9-0000yf-EP for ietf@ietf.org; Mon, 15 Oct 2007 16:30:33 -0400 Received: from nagasaki.bogus.com ([147.28.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhWa8-0007vx-VE for ietf@ietf.org; Mon, 15 Oct 2007 16:30:33 -0400 Received: from [192.35.166.78] (eth-0-19-d2-5-14-a1.dhcp.nanog.merit.net [192.35.166.78]) (authenticated bits=0) by nagasaki.bogus.com (8.14.1/8.13.8) with ESMTP id l9FKUU2s047886; Mon, 15 Oct 2007 20:30:31 GMT (envelope-from joelja@bogus.com) Message-ID: <4713CDE6.7010603@bogus.com> Date: Mon, 15 Oct 2007 13:30:30 -0700 From: Joel Jaeggli User-Agent: Thunderbird 1.5.0.12 (X11/20070719) MIME-Version: 1.0 To: Daniel Senie References: <941D5DCD8C42014FAF70FB7424686DCF01C26BAA@eusrcmw721.eamcs.ericsson.se> <2788466ED3E31C418E9ACC5C31661557084EBF@mou1wnexmb09.vcorp.ad.vrsn.com> <20071015172939.GP67213@verdi> <200710151854.l9FIshJe022814@parsley.amaranth.net> In-Reply-To: <200710151854.l9FIshJe022814@parsley.amaranth.net> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.1/4540/Sun Oct 14 01:43:55 2007 on nagasaki.bogus.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ietf@ietf.org Subject: Re: The IETF duty for Carbon emissions, energy use &ct. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Daniel Senie wrote: > At 01:29 PM 10/15/2007, John Leslie wrote: > >> Hallam-Baker, Phillip wrote: >> > >> > Whether your objective is to reduce carbon emissions because of >> > global warming concerns or reduce dependence on fossil fuels that are >> > increasingly in short supply, there is a real incentive to reduce >> > energy use. >> > >> > If teleconferencing actually worked the need to hold face to face >> > meetings would be reduced. >> >> I am constantly surprised how little interest there is within IETF >> for teleconferecing that works well. > > Indeed. I raised this point over the years. Even offering to pay a > "remote attendance fee" if there were in fact the ability to see and > hear sessions, and participate. The IETF for many years crowed about the > Mbone connectivity as being innovative, but got stuck there, and didn't > progress when comercial solutions bypassed that flawed technology. I don't recall crowing about multicast. I also don't recall you volunteering to show up and help enable remote participation... The volunteers built a model that was sustainable with a modest amount of capital and time. both jabber and and streaming audio. I respectfully suggest that if you put more in, you might get more out. joelja _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 15 17:38:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhXTY-0000sq-VJ; Mon, 15 Oct 2007 17:27:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhXTW-0000kG-9D for ietf@ietf.org; Mon, 15 Oct 2007 17:27:46 -0400 Received: from parsley.amaranth.net ([204.10.1.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhXTO-0005UH-4V for ietf@ietf.org; Mon, 15 Oct 2007 17:27:44 -0400 Received: from Clary.senie.com ([192.168.8.126]) (authenticated bits=0) by parsley.amaranth.net (8.12.11.20060308/8.12.11) with ESMTP id l9FLR4t4012748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Oct 2007 17:27:05 -0400 Message-Id: <200710152127.l9FLR4t4012748@parsley.amaranth.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 15 Oct 2007 17:09:07 -0400 To: Joel Jaeggli From: Daniel Senie In-Reply-To: <4713CDE6.7010603@bogus.com> References: <941D5DCD8C42014FAF70FB7424686DCF01C26BAA@eusrcmw721.eamcs.ericsson.se> <2788466ED3E31C418E9ACC5C31661557084EBF@mou1wnexmb09.vcorp.ad.vrsn.com> <20071015172939.GP67213@verdi> <200710151854.l9FIshJe022814@parsley.amaranth.net> <4713CDE6.7010603@bogus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-666D2D0B X-Virus-Scanned: ClamAV 0.91.2/4540/Sat Oct 13 21:43:55 2007 on parsley.amaranth.net X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ietf@ietf.org Subject: Re: The IETF duty for Carbon emissions, energy use &ct. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 04:30 PM 10/15/2007, Joel Jaeggli wrote: >Daniel Senie wrote: > > At 01:29 PM 10/15/2007, John Leslie wrote: > > > >> Hallam-Baker, Phillip wrote: > >> > > >> > Whether your objective is to reduce carbon emissions because of > >> > global warming concerns or reduce dependence on fossil fuels that are > >> > increasingly in short supply, there is a real incentive to reduce > >> > energy use. > >> > > >> > If teleconferencing actually worked the need to hold face to face > >> > meetings would be reduced. > >> > >> I am constantly surprised how little interest there is within IETF > >> for teleconferecing that works well. > > > > Indeed. I raised this point over the years. Even offering to pay a > > "remote attendance fee" if there were in fact the ability to see and > > hear sessions, and participate. The IETF for many years crowed about the > > Mbone connectivity as being innovative, but got stuck there, and didn't > > progress when comercial solutions bypassed that flawed technology. > >I don't recall crowing about multicast. > >I also don't recall you volunteering to show up and help enable remote >participation... No. I offered that I would pay a fee and NOT show up. >The volunteers built a model that was sustainable with a modest amount >of capital and time. both jabber and and streaming audio. > >I respectfully suggest that if you put more in, you might get more out. So in order to participate remotely, I needed to show up and run cameras. I'm sorry, but that does not make sense. I'm also sorry if you thought I was criticizing the people who put in the time to broadcast the meetings over Mbone. It was a great effort. Not one I could watch, mind you, since multicast connectivity didn't reach most of the places I've worked, but nice that someone did it nonetheless. What I suggested, at plenaries and such, was that I would have been happy to pay a meeting fee, despite not being there, if the money went toward interactive, remote attendance instead of to cookies, ice cream, pretzels and danish. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 15 20:40:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iha9r-0004pk-BE; Mon, 15 Oct 2007 20:19:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iha9o-0004pY-Vr for ietf@ietf.org; Mon, 15 Oct 2007 20:19:36 -0400 Received: from an-out-0708.google.com ([209.85.132.241]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iha9i-0002O0-Ro for ietf@ietf.org; Mon, 15 Oct 2007 20:19:36 -0400 Received: by an-out-0708.google.com with SMTP id c17so129175anc for ; Mon, 15 Oct 2007 17:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=sy5IKvKl2mKaontos2B6YDR4RNTll4leGN8mmFx4Bf4=; b=M/HfAZikvkIadhbiN6qZe4qhpTBqS0Fh/roS4RyND1vTr8nz+EpSjVFRdP0gHqWGnyvXFcHBgEGJFKd3bqAmOqX5vHMD3wkqLGduxz62FBb9K+33c2/BW6sNWp/B4XgHZVnGG5S2y1VIEosNiSz7+vGxQqWvMSDMqGrkHrIlXPk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=IrB3dtqRLRt/RAHPfVJr1WqVAFz/lybpmKOTkCodRRqymWfl3gK8A2xyG1pn0t29ybrvpEvD7Gar2FhHNe+ynjiY1xNxHA3MbUY6aAhH9Wwnjys5jypk9Yq0TBYkTAVphmw0bxb34dXMbnxZ5VSdNJ0/R9gpPA79yYf2i3CV22Q= Received: by 10.115.17.1 with SMTP id u1mr7654820wai.1192493914433; Mon, 15 Oct 2007 17:18:34 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id m10sm9301891waf.2007.10.15.17.18.31 (version=SSLv3 cipher=RC4-MD5); Mon, 15 Oct 2007 17:18:33 -0700 (PDT) Message-ID: <4714034D.50605@gmail.com> Date: Tue, 16 Oct 2007 13:18:21 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joel Jaeggli References: <941D5DCD8C42014FAF70FB7424686DCF01C26BAA@eusrcmw721.eamcs.ericsson.se> <2788466ED3E31C418E9ACC5C31661557084EBF@mou1wnexmb09.vcorp.ad.vrsn.com> <20071015172939.GP67213@verdi> <200710151854.l9FIshJe022814@parsley.amaranth.net> <4713CDE6.7010603@bogus.com> In-Reply-To: <4713CDE6.7010603@bogus.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ietf@ietf.org Subject: Re: The IETF duty for Carbon emissions, energy use &ct. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Joel, > The volunteers built a model that was sustainable with a modest amount > of capital and time. both jabber and and streaming audio. For which many thanks from many of us, I'm sure. Also, the Secretariat built a tool so that all slides can be uploaded before each session, or even in real time during the session. Of course, it isn't the same thing as telepresence over dedicated bandwidth, but that's in a different financial league. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 15 20:43:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhaRk-0005EG-5T; Mon, 15 Oct 2007 20:38:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhaRi-0005Dh-ES for ietf@ietf.org; Mon, 15 Oct 2007 20:38:06 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhaRh-0002zN-4A for ietf@ietf.org; Mon, 15 Oct 2007 20:38:06 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id 12F6423415; Tue, 16 Oct 2007 09:37:56 +0900 (JST) To: dthaler@microsoft.com, fenner@research.att.com, rcq@ipmulticast.com X-Mailer: Cue version 0.8 (070521-1856/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20071016003757.12F6423415@coconut.itojun.org> Date: Tue, 16 Oct 2007 09:37:56 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: -0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ietf@ietf.org, asaeda@sfc.wide.ad.jp Subject: RFC3678: header incompatibility X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org not sure if it is for ietf@ietf.org. please redirect it to appropriate group if needed. http://www.ietf.org/rfc/rfc3678.txt http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/socket.h.html RFC3678 defines a C structure with "struct sockaddr_storage" inside (for instance, struct group_req in section 5.1), in . however, from POSIX standard, sockaddr_storage is defined in . there is no guarantee that is included prior to , and it is not possible for to blindly include . note: types like sa_family_t are defined in , and they need not be/shall not be from . please update RFC3678 so that it will fit better with POSIX standard. itojun _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 15 20:56:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihad0-0007nj-Vn; Mon, 15 Oct 2007 20:49:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihacy-0007fs-Pj for ietf@ietf.org; Mon, 15 Oct 2007 20:49:44 -0400 Received: from mail-red.research.att.com ([192.20.225.110]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ihacy-0000BC-In for ietf@ietf.org; Mon, 15 Oct 2007 20:49:44 -0400 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id 4B6F8148242; Mon, 15 Oct 2007 20:49:41 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.13.1/8.12.10/Submit) id l9G0nfIe011849; Mon, 15 Oct 2007 20:49:41 -0400 From: Bill Fenner Message-Id: <200710160049.l9G0nfIe011849@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: itojun@itojun.org (Jun-ichiro itojun Hagino) Date: Mon, 15 Oct 2007 20:49:41 -0400 Versions: dmail (linux) 2.7/makemail 2.14 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: rcq@ipmulticast.com, asaeda@sfc.wide.ad.jp, ietf@ietf.org, dthaler@microsoft.com Subject: Re: RFC3678: header incompatibility X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > there is no guarantee that > is included prior to , and it is not > possible for to blindly include . Why not? POSIX seems to anticipate this: >Inclusion of the header may also make visible all symbols >from and . Bill _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 15 21:46:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhbRV-0007az-2d; Mon, 15 Oct 2007 21:41:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhbRS-0007ap-RB for ietf@ietf.org; Mon, 15 Oct 2007 21:41:54 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhbRS-0004y2-D0 for ietf@ietf.org; Mon, 15 Oct 2007 21:41:54 -0400 Received: from coconut.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 3220A23457; Tue, 16 Oct 2007 10:41:46 +0900 (JST) To: Bill Fenner In-reply-to: fenner's message of Mon, 15 Oct 2007 20:49:41 -0400. <200710160049.l9G0nfIe011849@bright.research.att.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino Date: Tue, 16 Oct 2007 10:41:45 +0900 Message-Id: <20071016014146.3220A23457@coconut.itojun.org> X-Spam-Score: -1.4 (-) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: rcq@ipmulticast.com, asaeda@sfc.wide.ad.jp, ietf@ietf.org, dthaler@microsoft.com Subject: Re: RFC3678: header incompatibility X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >> is included prior to , and it is not >> possible for to blindly include . > >Why not? POSIX seems to anticipate this: > >>Inclusion of the header may also make visible all symbols >>from and . i'm aware of that line, but that does not really meet my observations. - freebsd do define sockaddr_storage in and , with #define to avoid duplicate definitions. - opensolaris and other *BSD do not include from , nor define sockaddr_storage in . if the above POSIX line suggests inclusion of from , why freebsd did not do that and defined sockaddr_storage in two places? my guess is that it was a too big change to be accepted (way too much interaction with existing code). http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/in.h.diff?r1=1.99;r2=1.100 itojun _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 15 21:46:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhbOZ-0006iy-9A; Mon, 15 Oct 2007 21:38:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhbOY-0006d4-1U for ietf@ietf.org; Mon, 15 Oct 2007 21:38:54 -0400 Received: from smtp127.iad.emailsrvr.com ([207.97.245.127]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhbOQ-0001Z8-J9 for ietf@ietf.org; Mon, 15 Oct 2007 21:38:46 -0400 Received: from relay2.r2.iad.emailsrvr.com (localhost [127.0.0.1]) by relay2.r2.iad.emailsrvr.com (SMTP Server) with ESMTP id 3ECB1451C67; Mon, 15 Oct 2007 21:38:45 -0400 (EDT) Received: by relay2.r2.iad.emailsrvr.com (Authenticated sender: rpelletier-AT-isoc.org) with ESMTP id 2179B4508A2; Mon, 15 Oct 2007 21:38:45 -0400 (EDT) Message-ID: <47141671.7070603@isoc.org> Date: Mon, 15 Oct 2007 21:40:01 -0400 From: Ray Pelletier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, zh, zh-cn, zh-hk, zh-sg, zh-tw, ja MIME-Version: 1.0 To: IETF Discussion , The IESG , IAOC , IAB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: Vancouver Host & Sponsor Lineup! X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org The IAOC and the Internet Society are pleased to announce the Host and Sponsor lineup for IETF 70 in Vancouver. Co-Hosts for the meeting are long time supporters of the IETF, the Cisco Research Center [www.cisco.com/research] and Microsoft [www.microsoft.com]. The Cisco Research Center has also stepped up as the Welcome Reception Sponsor. Telus [www.telus.com] is returning as a sponsor in Vancouver, having sponsored IETF 64. The newest sponsor to the IETF is long time participant Huawei, [www.huawei.com] We want to thank our benefactors. The IETF cannot support its technical standards efforts, including the Secretariat and RFC Editor, without the generous support of its hosts and sponsors. We look forward to seeing you all in Vancouver starting on December 2nd. Registrations are still open and operators are standing by. [http://www3.ietf.org/meetings/70-IETF.html] Thinking about hosting or sponsoring a future meeting? Here's the meetings calendar through 2013 [www.ietf.org/meetings/0mtg-sites.txt] Just send Terry Monroe an email at monroe@isoc.org and he can walk you through the opportunity. Thanks again - Cisco Research Center, Microsoft, Telus and Huawei! Ray Pelletier IETF Administrative Director _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 15 21:46:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhbHG-0006jB-H9; Mon, 15 Oct 2007 21:31:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhbHF-0006ci-Ac for ietf@ietf.org; Mon, 15 Oct 2007 21:31:21 -0400 Received: from harry.mail-abuse.org ([168.61.5.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhbH9-0001Fy-Tx for ietf@ietf.org; Mon, 15 Oct 2007 21:31:16 -0400 Received: from [10.2.164.130] (SJC-Office-NAT-212.Mail-Abuse.ORG [168.61.10.212]) by harry.mail-abuse.org (Postfix) with ESMTP id 0BD8241657; Mon, 15 Oct 2007 18:31:14 -0700 (PDT) In-Reply-To: <4714034D.50605@gmail.com> References: <941D5DCD8C42014FAF70FB7424686DCF01C26BAA@eusrcmw721.eamcs.ericsson.se> <2788466ED3E31C418E9ACC5C31661557084EBF@mou1wnexmb09.vcorp.ad.vrsn.com> <20071015172939.GP67213@verdi> <200710151854.l9FIshJe022814@parsley.amaranth.net> <4713CDE6.7010603@bogus.com> <4714034D.50605@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Date: Mon, 15 Oct 2007 18:31:25 -0700 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ietf@ietf.org Subject: Re: The IETF duty for Carbon emissions, energy use &ct. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 15, 2007, at 5:18 PM, Brian E Carpenter wrote: > Joel, > >> The volunteers built a model that was sustainable with a modest >> amount of capital and time. both jabber and and streaming audio. > > For which many thanks from many of us, I'm sure. Also, the > Secretariat built a tool so that all slides can be uploaded before > each session, or even in real time during the session. > > Of course, it isn't the same thing as telepresence over dedicated > bandwidth, but that's in a different financial league. IM conversations or debates using text only are difficult, to type the least. Few have the patience needed to wait for others to finish typing before changing the topic. Access to the room microphone remotely would be nice. Perhaps a fee-based vetting might be used to limit access to this expensive resource. Also, those attending would not want to contend with thousands of others queued up on-line to ask their question and then perhaps one follow-up. Many IETF participants already use Skype. Skype runs on Linux, OSX, and Windows. Skype works through many different firewalls as well. It could be interesting to find whether a phone bridge can be easily controlled by the room moderator is available. The cost may not be too great when using network based voice clients and a soft switch? Is there an open-source alternative? -Doug _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 16 01:32:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhemY-0002pt-2O; Tue, 16 Oct 2007 01:15:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhemV-0002ow-CW for ietf@ietf.org; Tue, 16 Oct 2007 01:15:51 -0400 Received: from mail-red.research.att.com ([192.20.225.110]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhemV-0002fy-3P for ietf@ietf.org; Tue, 16 Oct 2007 01:15:51 -0400 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id D00B314825A; Tue, 16 Oct 2007 01:15:40 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.13.1/8.12.10/Submit) id l9G5Fe39014367; Tue, 16 Oct 2007 01:15:40 -0400 From: Bill Fenner Message-Id: <200710160515.l9G5Fe39014367@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Jun-ichiro itojun Hagino Date: Tue, 16 Oct 2007 01:15:40 -0400 Versions: dmail (linux) 2.7/makemail 2.14 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: asaeda@sfc.wide.ad.jp, ietf@ietf.org, dthaler@microsoft.com Subject: Re: RFC3678: header incompatibility X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > i'm aware of that line, but that does not really meet my observations. You asked that we revise the RFC to be compatible with POSIX. I observed that the RFC is not incompatible with POSIX. Now you are asserting that isn't what you were really asking? > if the above POSIX line suggests inclusion of from > , why freebsd did not do that and defined sockaddr_storage > in two places? Because FreeBSD chose a different implementation. Are you suggesting that POSIX is wrong, or that we were wrong to write the spec to be compatible with what POSIX requires? Or are you saying that we should have ignored POSIX and instead written the spec to what FreeBSD, OpenSolaris and *BSD prefer? (I'd note that MacOS X has a simple #include in , so apparently it's not impossible to implement things that way.) Bill _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 16 04:12:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhhLu-0004Tx-Js; Tue, 16 Oct 2007 04:00:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhhLq-0004QV-Cw; Tue, 16 Oct 2007 04:00:30 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhhLp-0000kp-O1; Tue, 16 Oct 2007 04:00:30 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 32399201D4; Tue, 16 Oct 2007 10:00:29 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-26-47146f9dfa7a Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0DD0520504; Tue, 16 Oct 2007 10:00:29 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 10:00:28 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 10:00:28 +0200 Message-ID: <47146F9C.1000301@ericsson.com> Date: Tue, 16 Oct 2007 10:00:28 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian E Carpenter References: <67602DA7-6B73-422C-95D3-7D216E0F388F@g11.org.uk> <47055AA3.40605@gmail.com> In-Reply-To: <47055AA3.40605@gmail.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2007 08:00:28.0856 (UTC) FILETIME=[9DFE5380:01C80FCA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ietf@ietf.org, tsvwg@ietf.org, ken carlberg , Pekka Savola Subject: Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi, My reading of this thread of comments is that there is no reason to change anything regarding the document. I will therefore progress this document towards approval. Regards Magnus Westerlund Brian E Carpenter skrev: > On 2007-10-05 05:38, ken carlberg wrote: >> >>> I don't recall when was the last (Diffserv-based) QoS talk at NANOG >>> or similar operator-rich meeting. (Sure, there is the tutorial, but >>> it doesn't count.) >> >> I would be concerned if outside groups spent time arguing "foo" is >> bad, or if they advocated other positions to the same issue. But I >> tend to feel quite uncomfortable with litmus tests based on inactivity >> of other groups/people. My personal view is that advocates of that >> line of reasoning place a bigger burden on themselves in providing >> specific in-depth arguments. >> >>> Seems like a potential indication that most typical ISPs aren't >>> working on or interested in this, this stuff is so trivial, or that >>> coordination is not necessary. >> >> i appreciate work that is trivial because its generally simple, easy >> to accomplish, and leads to fewer interoperability issues. as for >> ISPs, its fascinating the disparity of how quiet and talkative they >> are depending on what side of the NDA you are on :-) > > In any case, if Pekka is correct, that's *exactly* why this > draft and RFC 4594 are needed - to lay a minimum foundation on which > ISPs can build operational practices and SLAs. > > It's always been clear to me that voice and video would be the main > drivers for uptake of diffserv, and Marshall's comments confirm > that. As that type of traffic grows, ISPs won't have any choice. > Guidnace from the IETF seems entirely appropriate. > > Brian > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 16 06:07:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihj05-0005PZ-KM; Tue, 16 Oct 2007 05:46:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihizw-0005Nc-Sw for ietf@ietf.org; Tue, 16 Oct 2007 05:46:00 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihizn-0003xU-Du for ietf@ietf.org; Tue, 16 Oct 2007 05:46:00 -0400 Received: from [163.117.139.34] (nirrti.it.uc3m.es [163.117.139.34]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l9G9e444026681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Oct 2007 11:40:05 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <2788466ED3E31C418E9ACC5C31661557084EBF@mou1wnexmb09.vcorp.ad.vrsn.com> References: <28109.216.31.249.246.1192213828.squirrel@www.trepanning.net> <941D5DCD8C42014FAF70FB7424686DCF01C26BAA@eusrcmw721.eamcs.ericsson.se> <2788466ED3E31C418E9ACC5C31661557084EBF@mou1wnexmb09.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0E0A7540-9CCE-4EBC-9209-68DC76C9CBB5@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Tue, 16 Oct 2007 11:42:55 +0200 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, score=-2.2 required=3.5 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ietf@ietf.org Subject: Re: The IETF duty for Carbon emissions, energy use &ct. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 15-okt-2007, at 18:28, Hallam-Baker, Phillip wrote: > I think that whole conversation is missing the point. While one > conference with one and a half thousand participants has a > significant carbon footprint the more significant issue is the net > impact of Internet technology. We can do far more by enabling > changes in the behavior of the billion plus Internet users than our > own use. > Good point. So let's see if we can raise the average packet size used on the internet. If the router and switch vendors build their equipment such that they mostly use energy when actually doing stuff (such as routing table lookups) a reduction in the number of packets for the same amount of data would reduce the amount of power used to perform the data transfer. A lot of equipment out there is already capable of using packets larger than 1500 bytes but the protocols are too limited to use this capability where it exists in a manageable way. http://www.ietf.org/internet-drafts/draft-van-beijnum-multi-mtu-01.txt _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 16 07:13:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihk5F-0008WU-QU; Tue, 16 Oct 2007 06:55:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihk5E-0008B9-K2 for ietf@ietf.org; Tue, 16 Oct 2007 06:55:32 -0400 Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihk58-0006AA-Hc for ietf@ietf.org; Tue, 16 Oct 2007 06:55:28 -0400 Received: by coconut.itojun.org (Postfix, from userid 501) id CC11523521; Tue, 16 Oct 2007 19:55:02 +0900 (JST) To: fenner@research.att.com In-Reply-To: Your message of "Tue, 16 Oct 2007 01:15:40 -0400" <200710160515.l9G5Fe39014367@bright.research.att.com> References: <200710160515.l9G5Fe39014367@bright.research.att.com> X-Mailer: Cue version 0.8 (070521-1856/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20071016105502.CC11523521@coconut.itojun.org> Date: Tue, 16 Oct 2007 19:55:02 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: -0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: asaeda@sfc.wide.ad.jp, ietf@ietf.org, dthaler@microsoft.com Subject: Re: RFC3678: header incompatibility X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > > i'm aware of that line, but that does not really meet my observations. > > You asked that we revise the RFC to be compatible with POSIX. > I observed that the RFC is not incompatible with POSIX. Now you > are asserting that isn't what you were really asking? > > > if the above POSIX line suggests inclusion of from > > , why freebsd did not do that and defined sockaddr_storage > > in two places? > > Because FreeBSD chose a different implementation. > > Are you suggesting that POSIX is wrong, or that we were wrong to write > the spec to be compatible with what POSIX requires? Or are you saying > that we should have ignored POSIX and instead written the spec to > what FreeBSD, OpenSolaris and *BSD prefer? > (I'd note that MacOS X has a simple #include in > , so apparently it's not impossible to implement > things that way.) i see. i was not doing enough homework. sorry about that. (yup, this is not a forum to talk about posix, but...) the older version of POSIX specification did not have "may include ". http://www.opengroup.org/onlinepubs/007908799/xns/netinetin.h.html i am under impression that "may include " clause can lead to portability issues in applications - some application writers will include only and it will compile fine on some platforms, and not on some other platforms. do you have any information about when the clause was introduced? was it with the use of sockaddr_storage? itojun _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 16 08:22:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhlA1-0007aK-9l; Tue, 16 Oct 2007 08:04:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihl9x-0007Yf-DK for ietf@ietf.org; Tue, 16 Oct 2007 08:04:29 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihl9o-0000ST-0b for ietf@ietf.org; Tue, 16 Oct 2007 08:04:26 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ihl9Q-00083y-4o for ietf@ietf.org; Tue, 16 Oct 2007 12:03:56 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Oct 2007 12:03:56 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Oct 2007 12:03:56 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: "Frank Ellermann" Date: Tue, 16 Oct 2007 14:00:58 +0200 Lines: 133 Message-ID: References: <2788466ED3E31C418E9ACC5C316615570534E4@mou1wnexmb09.vcorp.ad.vrsn.com><6.2.5.6.2.20071004111028.031d08e0@resistor.net><3D19D707-31B1-4753-8B33-2F9761A5451A@mail-abuse.org><41DFA083-E582-4A09-9C6D-A73EB5E93BA0@mail-abuse.org><74C293FF-7E90-44F1-B4F0-55E3B10D48D9@mail-abuse.org> <7FC3C2FA-AB7B-406F-8575-5EF4F31A9B81@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Subject: Re: TMDA backscatter X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Douglas Otis wrote: >> In theory IANA could publish one _spf.arpa "v=3Dspf1 mx a aaaa -all" = >> record, and everybody could use it with "v=3Dspf1 = redirect=3D_spf.arpa". >> That one SPF record can (kind of) reference an unlimited number of >> MX records doesn't depend on SPF's local-part macro. =20 > This adds perhaps 21 useless DNS transactions for each email =20 > received? No, a "v=3Dspf1 redirect=3D_sp.arpa" would add precisely one transaction in comparison with directly stating "v=3Dspf1 mx a aaaa -all". Don't worry about it, it was only a theoretical example. =20 The SPF policy for xyzzy.claranet.de uses this technique, admittedly unnecessary in this case. Lame apology, the massive abuse of xyzzy- addresses in 2004 forced me to check out SPF before I understood the fine print (here: avoid unnecessary DNS queries). It's not really "my" policy, otherwise I'd get rid of the (in this case) unnecessary DNS transaction for the "redirect=3D" step. > Do you expect everyone to use inbound servers to send? No. Of course I'd expect that mail to to the IP of an MTA talking to an MX I care about works. BTW, it would be nice if only the MXs of the envelope sender address talk to other MXs, we could then scrap SPF in this "inherent RMX" parallel universe. Just decree that everybody has an implicit "v=3Dspf1 mx a aaaa -all" policy, what a dream. Actually SPF is a clumsy approximation of this dream. > Use of MX records are normally predicated upon the sending of =20 > messages. Yes, I proposed a simplification of your DNS attack scenario based on "call back verification" instead of SPF. AFAIK "CBV" works by connecting to an MX of the alleged sender, and trying a RCPT TO the envelope sender address. If that results in "unknown mailbox" the receiver knows that the envelope sender address is dubious at best. Spammers also know this, that's why they forge "plausible" addresses. An SPF FAIL cuts them off at this stage. As long as there are more than enough unprotected "plausible" (=3D surviving CBV) addresses the spammers can carry on as is. > However, overall amplification is much less when a message triggers > an automated response. When I got about 1,000 bogus bounces and other auto-replies per day in 2004 I didn't care about other side effects, my mailbox was almost unusable. > An automated response is likely to be filtered Filtering behind a POP3 modem connection is tricky, after all I still wanted to get "good" bounces, challenges, and other auto-replies. Filtering or rejecting auto-responses before final delivery needs something in the direction of BATV plus good heuristics to identify "non-standard" backscatter (as outlined in RFC 3834). BATV doesn't directly fight forgeries, it only stops backscatter=20 before final delivery (ideally rejecting it at the MX of the alleged originator). It's a nice scheme, use it if you can. But it won't help me (as receiver) to reject forged "mail from" Douglas Otis. =20 > SPF permits an enormous amount of DNS traffic to be directed toward > an innocent, uninvolved domain. Well, I'd try something more direct when I'd wish to attack a domain, your idea is IMO far too convoluted. And your claim that a domain under attack by bogus A or AAAA queries caused by MX records of the attacker, based on CBV, SPF, or what else, has no chance to find out who the attcker is, might be also wrong. The querying hosts can find out why they do this, and at that point one or more name servers of the attacker (where he manages the bogus MX records) are also known. > Once the attack duration exceeds a recipient's negative caching, no > additional resources of the attacker are consumed BTW, who determines the TTL of NXDOMAIN, can a zone under attack tune this ? =20 > Even the attacking MX record might be unrelated to any domain found > within the message. They're referenced by mx-mechanisms in the SPF policy of the envelope sender, i.e. the attacker. And this SPF policy record still exists at least in the DNS cache of the receivers. FWIW, the querying hosts can find out what's going on. > Expect spammers to take advantage of this generous SPF gift. Don't confuse "spammers" and "attackers". This might be the same persons, but the roles are very different. Spammers in their role as spammer might wish to attack successful anti-spammers, but they have no reason to prefer your attack strategy based on SPF where they'd be forced to risk one of their own name servers. I think all attackers prefer to risk more anonymous resources like zombies. > RFC3464 represents a far better solution as it removes incentives. No, that's not true. When my addresses were abused it was the number of bogus DSNs and other auto-replies that bothered me most, not the size of the DSNs. And the incentive isn't to send spam indirectly in the form of a DSN to the forged envelope sender, the incentive is to abuse an unprotected "plausible" address. SPF FAIL offers the protection. > Call back verification is not part of RFC2821? True, but I was talking about abusing CBV for an MX attack instead of SPF's mx-mechanism, and you then hinted that normal RFC 2821 sending strategies won't query for addresses of all names found in the MX records at once. Actually I don't know what real MTAs do if they get NXDOMAIN, do they wait before they try the next name ? >>> DKIM can be processed prior to acceptance >> Yes, but unlike SPF not before DATA. I skip the "anti-phishing" =20 >> discussion because it's not directly related to "backscatter". =20 > Other solutions are able to prevent the DATA phase for spam. : ) Whatever it might be, it didn't work for me back in 2004. Victims of backscatter can't wait for worldwide adoption of MTAMARK, CSV, or "other solutions", they need something working now. SPF works as designed because it's in the best interest of spammers to stay away from FAIL-protected addresses. Frank _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 16 09:50:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhmZA-0006iU-R2; Tue, 16 Oct 2007 09:34:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih09Z-0007ZW-RU for ietf@ietf.org; Sun, 14 Oct 2007 05:52:57 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ih09P-0007gn-4z for ietf@ietf.org; Sun, 14 Oct 2007 05:52:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 14 Oct 2007 11:53:49 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04F960EA@IsrExch01.israel.polycom.com> In-Reply-To: <001501c809b6$a1f9a710$5d00a8c0@Codalogic> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-levin-mmusic-xml-media-control (XML Schema for Media Control) to Informational RFC Thread-Index: AcgJttiXYh+FocjRR8y1vcE7nBfRgAEkOHyg From: "Even, Roni" To: "Pete Cordell" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 X-Mailman-Approved-At: Tue, 16 Oct 2007 09:34:33 -0400 Cc: oritl@microsoft.com, pierre@radvision.com Subject: RE: Last Call: draft-levin-mmusic-xml-media-control (XML Schema for Media Control) to Informational RFC X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Pete, Thanks , we are reviewing to see if the example reflects existing = implementations Roni Even > -----Original Message----- > From: Pete Cordell [mailto:pete@codalogic.com] > Sent: Monday, October 08, 2007 4:22 PM > To: ietf@ietf.org > Cc: oritl@microsoft.com; Even, Roni; pierre@radvision.com > Subject: Re: Last Call: draft-levin-mmusic-xml-media-control (XML = Schema > for Media Control) to Informational RFC >=20 > I quickly looked at this and noticed that the XML instance examples = don't > match the schema because the instance does not make reference to the > namespace. i.e., to match the schema, the example should be: >=20 > >=20 > > > > > >=20 > >=20 > My expectation is that the instance is actually more authorative in = terms > of > what the authors are looking for. If that is the case, the schema = should > be > modified along the lines of: >=20 > xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema"> > ... >=20 > i.e. remove the targetNamespace declarations. >=20 > You may have your reasons not to, but if not, you may want to consider > using > schema's documentation features instead of the XML comments; e.g.: >=20 > > > Video control primitive. > >=20 > > ... >=20 > HTH, >=20 > Pete. > -- > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Pete Cordell > Codalogic > for XML Schema to C++ data binding visit > http://www.codalogic.com/lmx/ > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > ----- Original Message ----- > From: "The IESG" > To: "IETF-Announce" > Sent: Monday, October 08, 2007 2:29 PM > Subject: Last Call: draft-levin-mmusic-xml-media-control (XML Schema = for > Media Control) to Informational RFC >=20 >=20 > > The IESG has received a request from an individual submitter to = consider > > the following document: > > > > - 'XML Schema for Media Control ' > > as an Informational = RFC > > > > The IESG plans to make a decision in the next few weeks, and = solicits > > final comments on this action. Please send substantive comments to = the > > ietf@ietf.org mailing lists by 2007-11-05. Exceptionally, > > comments may be sent to iesg@ietf.org instead. In either case, = please > > retain the beginning of the Subject line to allow automated sorting. > > > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-levin-mmusic-xml-media- > control-11.txt > > > > > > IESG discussion can be tracked via > > > = https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D93 > 91&rfc_flag=3D0 > > > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf-announce > > >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 16 09:50:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhmZB-0006if-Jb; Tue, 16 Oct 2007 09:34:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQNd-0002tM-8h; Mon, 15 Oct 2007 09:53:13 -0400 Received: from mail.ca.certicom.com ([38.113.160.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhQNU-00019m-Af; Mon, 15 Oct 2007 09:53:13 -0400 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 0439810027FE3; Mon, 15 Oct 2007 09:52:52 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm.certicom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKl6U5mdYyX4; Mon, 15 Oct 2007 09:52:45 -0400 (EDT) Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP; Mon, 15 Oct 2007 09:52:45 -0400 (EDT) Received: from [10.24.0.102] ([10.24.0.102]) by domino1.certicom.com (Lotus Domino Release 7.0.2FP2 HF177) with ESMTP id 2007101509523691-87682 ; Mon, 15 Oct 2007 09:52:36 -0400 Message-ID: <47137114.1040906@certicom.com> Date: Mon, 15 Oct 2007 09:54:28 -0400 From: Chinh Nguyen User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 7.0.2FP2 HF177|August 10, 2007) at 10/15/2007 09:52:36 AM, Serialize by Router on Certicom1/Certicom(Release 7.0.2FP2 HF177|August 10, 2007) at 10/15/2007 09:52:37 AM, Serialize complete at 10/15/2007 09:52:37 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Tue, 16 Oct 2007 09:34:33 -0400 Cc: ipsec@ietf.org, kent@bbn.com, paul.hoffman@vpnc.org, mlepinski@bbn.com, ietf@ietf.org Subject: Re: [IPsec] Re: Last call comments for draft-lepinski-dh-groups-01 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Pasi.Eronen@nokia.com wrote: > Paul Hoffman wrote: > >>> 2) For IKEv1/IKEv2, the document should explicitly specify how >>> ECC points are converted to octet strings (for KE payloads >>> and resulting shared secret value). Currently, there are at >>> least three incompatible options (RFC 4753, RFC 2409, and >>> draft-ietf-ipsec-ike-ecc-groups-10 drafts). I'd suggest just >>> saying "the same way as in RFC 4753". >> This bodes really poorly for interoperability. >> draft-lepinski-dh-groups needs to be revised to specify one of the >> methods, and that needs to be discussed on the IPsec mailing list. >> I would not assume that implementers would prefer RFC 4753 over >> draft-ietf-ipsec-ike-ecc-groups. > > I suggested "the same way as in RFC 4753" not because I particularly > prefer that point-to-octet-string conversion method, but because I > would prefer not having three different methods (two is bad enough). > > (Note that the current ecc-groups-10 draft actually tries to > modify the definitions of groups 19/20/21 from RFC 4753: it > reuses the same numbers but with different point-to-octet-string > conversion method.) Note that interoperability issues involve more than the representation of the ECC point (KE payload in IKE). The shared secret is also different between RFC 4753 (x + y) and draft-ietf-ipsec-ike-ecc-groups (x only). This has implications for the generation of the symmetric keys. I believe that the representation in draft-ietf-ipsec-ike-ecc-groups is more widely used including other standards such as SEC, FIPS 186-2, IEEE 1363, and ANSI X9.62. D. Brown at Certicom is writing an update to draft-ietf-ipsec-ike-ecc-groups which attempts to resolve this interoperability issue. In a nutshell, both formats are supported. Practically speaking when it comes to IKE, the responder supports both format and chooses the format based on the one chosen by the initiator. Regards, Chinh -- http://www.certicom.com _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 16 10:05:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhmxC-0003WE-6M; Tue, 16 Oct 2007 09:59:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihmx9-0003Ts-Nv for ietf@ietf.org; Tue, 16 Oct 2007 09:59:23 -0400 Received: from mail-red.research.att.com ([192.20.225.110]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ihmx9-0004he-DM for ietf@ietf.org; Tue, 16 Oct 2007 09:59:23 -0400 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id 1F14B147CDA; Tue, 16 Oct 2007 09:59:08 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.13.1/8.12.10/Submit) id l9GDx73x019296; Tue, 16 Oct 2007 09:59:07 -0400 From: Bill Fenner Message-Id: <200710161359.l9GDx73x019296@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Jun-ichiro itojun Hagino References: <200710160515.l9G5Fe39014367@bright.research.att.com> <20071016105502.CC11523521@coconut.itojun.org> Date: Tue, 16 Oct 2007 09:59:07 -0400 Versions: dmail (linux) 2.7/makemail 2.14 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: asaeda@sfc.wide.ad.jp, ietf@ietf.org, dthaler@microsoft.com Subject: Re: RFC3678: header incompatibility X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > i am under impression that "may include " clause can > lead to portability issues in applications - some application writers > will include only and it will compile fine on some > platforms, and not on some other platforms. Header pollution definitely makes it easier to write nonportable applications. > do you have any > information about when the clause was introduced? was it with > the use of sockaddr_storage? I'd guess so, but I don't know for sure. You can see that the SUSv2 that you pointed to didn't have sockaddr_storage. Starting with a different angle: if there had been a different way to design the API, I think we would have. The use of sockaddr_storage in these structs is incredibly wasteful, since it's usually way bigger than a sockaddr_in6, which is the biggest thing that it has to convey. However, we were aware of no other socket option calls that required copying additional user memory to kernel memory (e.g., because we passed a pointer in the middle of the struct) and didn't want to introduce that requirement for fear of being difficult to implement on some platforms. The best option might have been to introduce a real new API, not just socket options; obviously then we could use similar options to bind()/connect() et al. and just accept a sockaddr * as one of the arguments. But this is a somewhat higher implementation overhead - updating libc, syscall tables, etc - and IPv4 multicast didn't do this - so again it was a matter of trying to reduce barriers to imnplementation. Bill _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 16 14:54:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhrK4-0004SO-Qp; Tue, 16 Oct 2007 14:39:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhrK2-0004S1-QN for ietf@ietf.org; Tue, 16 Oct 2007 14:39:18 -0400 Received: from smtp127.iad.emailsrvr.com ([207.97.245.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhrJw-0008Dr-M4 for ietf@ietf.org; Tue, 16 Oct 2007 14:39:18 -0400 Received: from relay2.r2.iad.emailsrvr.com (localhost [127.0.0.1]) by relay2.r2.iad.emailsrvr.com (SMTP Server) with ESMTP id 7129C4594B7; Tue, 16 Oct 2007 14:38:57 -0400 (EDT) Received: by relay2.r2.iad.emailsrvr.com (Authenticated sender: rpelletier-AT-isoc.org) with ESMTP id 46F2C4594BB; Tue, 16 Oct 2007 14:38:57 -0400 (EDT) Message-ID: <4715058E.4050505@isoc.org> Date: Tue, 16 Oct 2007 14:40:14 -0400 From: Ray Pelletier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, zh, zh-cn, zh-hk, zh-sg, zh-tw, ja MIME-Version: 1.0 To: IETF Discussion , The IESG , IAB , IAOC Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: Host for IETF 73 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org The IAOC and the Internet Society are very pleased to announce the addition of a new Host to the long list of companies and organizations that have supported the IETF for more than 20 years. Google will be tbe the Host for IETF 73 in Minneapolis and has stepped up to be the Welcome Reception Sponsor as well. [www.google.com] Again we want to thank our benefactors. The IETF cannot support its technical standards efforts, including the Secretariat and RFC Editor, without the generous support of its hosts and sponsors. We look forward to seeing you all in Vancouver starting on December 2nd. Registrations are still open and operators are still standing by. [http://www3.ietf.org/meetings/70-IETF.html] Thinking about hosting or sponsoring a future meeting? Here's the meetings calendar through 2013 [www.ietf.org/meetings/0mtg-sites.txt] Just send Terry Monroe an email at monroe@isoc.org and he can walk you through the opportunity. Add your name to the distinguished list of benefactors http://www.ietf.org/meetings/past.meetings.html Thanks again Google! Ray Pelletier IETF Administrative Director _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 16 22:44:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhyYW-0002lx-Hx; Tue, 16 Oct 2007 22:22:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhyYV-0002hW-8y for ietf@ietf.org; Tue, 16 Oct 2007 22:22:43 -0400 Received: from harry.mail-abuse.org ([168.61.5.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhyYI-0002O0-6M for ietf@ietf.org; Tue, 16 Oct 2007 22:22:36 -0400 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 7B36841609; Tue, 16 Oct 2007 19:22:06 -0700 (PDT) In-Reply-To: References: <2788466ED3E31C418E9ACC5C316615570534E4@mou1wnexmb09.vcorp.ad.vrsn.com><6.2.5.6.2.20071004111028.031d08e0@resistor.net><3D19D707-31B1-4753-8B33-2F9761A5451A@mail-abuse.org><41DFA083-E582-4A09-9C6D-A73EB5E93BA0@mail-abuse.org><74C293FF-7E90-44F1-B4F0-55E3B10D48D9@mail-abuse.org> <7FC3C2FA-AB7B-406F-8575-5EF4F31A9B81@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Date: Tue, 16 Oct 2007 19:22:15 -0700 To: Frank Ellermann X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -4.0 (----) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: ietf@ietf.org Subject: Re: TMDA backscatter X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 16, 2007, at 5:00 AM, Frank Ellermann wrote: > Douglas Otis wrote: > >> Do you expect everyone to use inbound servers to send? > > No. Of course I'd expect that mail to to the IP of an > MTA talking to an MX I care about works. BTW, it would be nice if > only the MXs of the envelope sender address talk to other MXs, we > could then scrap SPF in this "inherent RMX" parallel universe. > Just decree that everybody has an implicit "v=spf1 mx a aaaa -all" > policy, what a dream. Actually SPF is a clumsy approximation of > this dream. Requiring MX for discovery eliminates additional transactions needed to assert no policy record or valid email domain. However, the SPF or RMX concept is seriously flawed. Defining valid sources might scale when done "by-name" but never "by- address". By-Name is how MX records declare destinations. PTR record-sets adjacent to an MX record could associate valid client domains. Perhaps special names like "_NONE" or "_ANY" could be defined for PTRs under a _MX-OUT leaf. DNS would then be able to return addresses needed to validate a specific client host-name within a single transaction, but not for all possible host-names. Being able to validate clients within an authorized source domain should safely satisfy your need for a protection mechanism. Fully resolving just one MX record for either IPv4 and IPv6 addresses might necessitate 20 DNS transactions when permitting 10 MX targets. SPF allows 10 MX records, where each may contain 10 targets. Unless IPv6 is excluded, subsequent transactions for both A and AAAA records might be needed where a high level of NXDOMAINs would be ignored. This means 10 x (10 + 10) or 200 DNS transactions satisfy SPF semantics for each email-address checked. However, some suggest using SPF to authorize DKIM domains or PRAs first. When DKIM or PRAs are not authorized, it is common to then check MAIL FROM. Each message might therefore invoke 400 DNS transactions per message. Even after allowing this number of transactions, the resulting list may not encompass the addresses of all valid outbound hosts. >> Use of MX records are normally predicated upon the sending of >> messages. > > Yes, I proposed a simplification of your DNS attack scenario based > on "call back verification" instead of SPF. AFAIK "CBV" works by > connecting to an MX of the alleged sender, and trying a RCPT TO the > envelope sender address. If that results in "unknown mailbox" the > receiver knows that the envelope sender address is dubious at best. > > Spammers also know this, that's why they forge "plausible" > addresses. An SPF FAIL cuts them off at this stage. As long as > there are more than enough unprotected "plausible" (= surviving > CBV) addresses the spammers can carry on as is. See above. >> However, overall amplification is much less when a message >> triggers an automated response. > > When I got about 1,000 bogus bounces and other auto-replies per day > in 2004 I didn't care about other side effects, my mailbox was > almost unusable. See above. >> An automated response is likely to be filtered > > Filtering behind a POP3 modem connection is tricky, after all I > still wanted to get "good" bounces, challenges, and other auto- > replies. > > Filtering or rejecting auto-responses before final delivery needs > something in the direction of BATV plus good heuristics to identify > "non-standard" backscatter (as outlined in RFC 3834). > > BATV doesn't directly fight forgeries, it only stops backscatter > before final delivery (ideally rejecting it at the MX of the > alleged originator). It's a nice scheme, use it if you can. But > it won't help me (as receiver) to reject forged "mail from" Douglas > Otis. See above. >> SPF permits an enormous amount of DNS traffic to be directed >> toward an innocent, uninvolved domain. > > Well, I'd try something more direct when I'd wish to attack a > domain, your idea is IMO far too convoluted. SPF enables a cached record to redirect the subsequent DNS transactions of a recipient. In addition, SPF provides an attacker the means to manage a sequence of MX records independently from what is seen as the originator. > And your claim that a domain under attack by bogus A or AAAA > queries caused by MX records of the attacker, based on CBV, SPF, or > what else, has no chance to find out who the attcker is, might be > also wrong. Logs of the DNS and mail servers may provide clues about which domains appear to have staged the attack, but the domain visible to a mail server is able to transition rapidly which prevents any filter from curtailing an ongoing attack. > The querying hosts can find out why they do this, and at that point > one or more name servers of the attacker (where he manages the > bogus MX records) are also known. Finding one of perhaps hundreds of DNS servers used by an attacker will not offer a meaningful defence. The ability to redirect DNS transactions afforded a cached SPF record ensures an attacker can escape any blocking effort. >> Once the attack duration exceeds a recipient's negative caching, >> no additional resources of the attacker are consumed > > BTW, who determines the TTL of NXDOMAIN, can a zone under attack > tune this? The recipient decides. They may follow RFC2308 recommendations which is the lesser of either the SOA MINIMUM field or the SOA TTL. However some experience problems and truncate the duration. Here is a common tip given to Windows users: "By default these negative entries are cached for 5 mins. But we can tweak the registry to NOT store negative entries at all!" >> Even the attacking MX record might be unrelated to any domain >> found within the message. > > They're referenced by mx-mechanisms in the SPF policy of the > envelope sender, i.e. the attacker. And this SPF policy record > still exists at least in the DNS cache of the receivers. FWIW, the > querying hosts can find out what's going on. How long will these records remain? A single cached SPF record can do untold damage with its ability to redirect recipient transactions. Rapidly changing these records will not consume much of an attackers resources. Attackers are extremely adept at fast- fluxing DNS. It is not 2004 any more. >> Expect spammers to take advantage of this generous SPF gift. > > Don't confuse "spammers" and "attackers". This might be the same > persons, but the roles are very different. Spammers in their role > as spammer might wish to attack successful anti-spammers, but they > have no reason to prefer your attack strategy based on SPF where > they'd be forced to risk one of their own name servers. I think > all attackers prefer to risk more anonymous resources like zombies. Why do you think there is a difference between a zombie and a name server? Why shouldn't a spammer offer an attacking service when it will not impact their spamming service? >> RFC3464 represents a far better solution as it removes incentives. > > No, that's not true. When my addresses were abused it was the > number of bogus DSNs and other auto-replies that bothered me most, > not the size of the DSNs. RFC3464 removes incentives which affords greater protection at much smaller costs. SPF is not the only tool available! > And the incentive isn't to send spam indirectly in the form of a > DSN to the forged envelope sender, the incentive is to abuse an > unprotected "plausible" address. SPF FAIL offers the protection. Despite intentions, SPF creates a far graver danger. >> Call back verification is not part of RFC2821? > > True, but I was talking about abusing CBV for an MX attack instead > of SPF's mx-mechanism, and you then hinted that normal RFC 2821 > sending strategies won't query for addresses of all names found in > the MX records at once. Actually I don't know what real MTAs do if > they get NXDOMAIN, do they wait before they try the next name ? Regardless, it should not happen more than the number of targets contained within a single MX record. This attack would also incur the message and MX record overhead. While a concern, it is not in the same league. >> Other solutions are able to prevent the DATA phase for spam. : ) > > Whatever it might be, it didn't work for me back in 2004. Victims > of backscatter can't wait for worldwide adoption of MTAMARK, CSV, > or "other solutions", they need something working now. SPF works > as designed because it's in the best interest of spammers to stay > away from FAIL-protected addresses. The same could have been said about the use of DDT as a pesticide. This attitude will likely require banning SPF before its use can be irradiated. : ( -Doug _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 17 09:19:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii8YQ-0003f1-8y; Wed, 17 Oct 2007 09:03:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii8YO-0002XN-07 for ietf@ietf.org; Wed, 17 Oct 2007 09:03:16 -0400 Received: from mx2-q.rad.co.il ([80.74.100.144] helo=antivir2.rad.co.il) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ii8XO-0004HA-Q1 for ietf@ietf.org; Wed, 17 Oct 2007 09:02:15 -0400 Received: from exrad3.rad.co.il (HELO exrad3.ad.rad.co.il) ([192.114.24.112]) by antivir2.rad.co.il with ESMTP; 17 Oct 2007 15:02:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 Oct 2007 15:02:09 +0200 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D05511C2B@exrad3.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ITU-T Recommendations Thread-Index: AcgP2RChT0nAM971S2qOd/zQN4YwFAA5K+Og From: "Yaakov Stein" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Subject: FW: ITU-T Recommendations X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0825049571==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============0825049571== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C810BD.ED4126E0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C810BD.ED4126E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This should interest many of you ... =20 Y(J)S ________________________________ From: sales.online@itu.int [mailto:sales.online@itu.int]=20 Sent: Wednesday, October 17, 2007 2:34 PM Subject: ITU-T Recommendations The ITU Sales and Marketing Division would like to inform you that in view of the overall success of the recent trial, the policy of free access to ITU-T recommendations has recently been adopted on a permanent basis by ITU Council 2007. =20 This new policy includes free-to-the-general-public access to in-force and superseded ITU-T Recommendations (posted in .pdf format only). =20 Additionally, contributing ITU Members and Sector members (including Associates) may also access all pre-published ITU-T Recommendations as well as ITU-T Recommendations in other formats not limited to .pdf (via their TIES password only). Non-members would still be required to pay (via an annual Online Subscription or individual pay-per-download) to access pre-published and non-.pdf formats, or otherwise purchase the quarterly-released DVD of ITU-T Recommendations. We should also remind you that this information is relative to ITU-T Recommendations only.=20 For more precise information on this offer, or on ITU Publications in general, please do not hesitate to contact us directly via return email. We trust this information proves useful and thank you for your continued support of ITU Publications. =20 Best Regards,=20 ITU Sales & Marketing=20 sales@itu.int=20 Place des Nations=20 1211 GENEVA SWITZERLAND=20 Fax +41 22 730 5194=20 www.itu.int/publications =20 ------_=_NextPart_001_01C810BD.ED4126E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ITU-T Recommendations
This=20 should interest many of you ...
 
Y(J)S


From: sales.online@itu.int=20 [mailto:sales.online@itu.int]
Sent: Wednesday, October 17, = 2007 2:34=20 PM
Subject: ITU-T Recommendations


The ITU Sales and = Marketing Division=20 would like to inform you that in view of the overall = success of the=20 recent trial, the policy of free access to = ITU-T=20 recommendations has recently been adopted on a permanent basis by = ITU=20 Council 2007.   =20

This new policy includes=20 free-to-the-general-public = access to=20 in-force and superseded ITU-T Recommendations (posted in = .pdf=20 format only).  =

Additionally, = contributing ITU Members and Sector members=20 (including Associates) may also access all pre-published ITU-T Recommendations as well as ITU-T Recommendations in = other formats=20 not limited to .pdf (via their TIES password only).  Non-members would still be required to pay (via an annual = Online=20 Subscription or individual pay-per-download) to = access=20 pre-published and=20 non-.pdf formats, or otherwise purchase the = quarterly-released DVD of ITU-T Recommendations.

We should also remind=20 you that this = information=20 is relative to = ITU-T=20 Recommendations only.

For more precise information on this offer, or on ITU = Publications in=20 general, please do not hesitate to contact us directly via return=20 email.

We trust this information = proves useful=20 and thank you for your continued support of ITU Publications. =20
Best Regards,
ITU Sales & = Marketing
sales@itu.int
Place des=20 Nations
1211 GENEVA = SWITZERLAND=20
Fax +41 22 730 5194
www.itu.int/publications


------_=_NextPart_001_01C810BD.ED4126E0-- --===============0825049571== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0825049571==-- From ietf-bounces@ietf.org Wed Oct 17 10:57:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiA74-0006ex-Ve; Wed, 17 Oct 2007 10:43:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiA71-0006dj-C5; Wed, 17 Oct 2007 10:43:07 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiA6v-0007BH-5V; Wed, 17 Oct 2007 10:43:07 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l9HEpEj6015943; Wed, 17 Oct 2007 09:51:15 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 09:42:47 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 09:42:47 -0500 Message-ID: <47161FE3.2000209@ericsson.com> Date: Wed, 17 Oct 2007 10:44:51 -0400 From: Suresh Krishnan User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: General Area Review Team , dean.willis@softarmor.com, aallen@rim.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2007 14:42:47.0427 (UTC) FILETIME=[FC1DB530:01C810CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: fluffy@cisco.com, sip-chairs@tools.ietf.org, ietf@ietf.org Subject: Gen-ART review of draft-ietf-sip-answermode-06.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I am the assigned Gen-ART reviewer for draft-ietf-sip-answermode-06.txt For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Summary: This draft is ready for publication and the issues I raised with the previous version (-04) of the draft have been resolved. Cheers Suresh _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 17 15:40:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiEWu-0004a9-SR; Wed, 17 Oct 2007 15:26:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiE0L-0005QU-48; Wed, 17 Oct 2007 14:52:29 -0400 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiE0J-0007I1-BO; Wed, 17 Oct 2007 14:52:29 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l9HImRvQ025679; Wed, 17 Oct 2007 14:48:28 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAbuaO9X; Wed, 17 Oct 07 14:47:42 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id A69CF3F423; Wed, 17 Oct 2007 13:55:09 -0400 (EDT) To: beepy@netapp.com, chetnh@earthlink.net, iesg@ietf.org, ietf@ietf.org, lars.eggert@nokia.com, magnus.westerlund@ericsson.com, secdir@mit.edu, spencer.shepler@sun.com, thomas.talpey@netapp.com Message-Id: <20071017175509.A69CF3F423@pecan.tislabs.com> Date: Wed, 17 Oct 2007 13:55:09 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 X-Mailman-Approved-At: Wed, 17 Oct 2007 15:26:06 -0400 Cc: sandy@tislabs.com Subject: review of draft-ietf-nfsv4-nfs-rdma-problem-statement-07.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org This is a review of draft-ietf-nfsv4-nfs-rdma-problem-statement-07.txt I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes the use of NFS (over RPC) over RDMA. Most of the text surveys current literature as to why doing RDMA to avoid data copying would be a good thing. The security considerations section is quite short: The NFS protocol, in conjunction with its layering on RPC, provides a rich and widely interoperable security model to applications and systems. Any layering of NFS over RDMA transports must address the NFS security requirements, and additionally must ensure that no new vulnerabilities are introduced. For RDMA, the integrity, and any privacy, of the data stream are of particular importance. Security Considerations must be addressed by any relevant RDMA transport layering. The protocol described in [RPCRDMA] provides one such approach. I don't think the particularly important aspects of RDMA transfer are limited to integrity and privacy. I think that one of the important security considerations would be the authorization of the source of the RDMA transfer to be reading or writing into whatever memory or data buffers it was writing into. The RPCRDMA draft does not address this question. It discusses the integrity and privacy of the data transferred, as here. The RDDP has a draft which discusses DDP/RDMA security in depth. I think that the draft http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-10.txt is a suitable reference for this draft. It's on the RFC Ed queue according to the I-D tracker. (In particular, it talks about the idea of a protection domain: A correct implementation of a Protection Domain requires that resources which belong to a given Protection Domain can not be used on a resource belonging to another Protection Domain, because Protection Domain membership is checked by the RNIC prior to taking any action involving such a resource. Protection Domains are therefore used to ensure that an STag can only be used to access an associated data buffer on one or more Streams that are associated with the same Protection Domain as the specific STag. I think that settles my question of authorizing the RDMA transfer. The rddp-rdmap-07 draft has a nice summary (sect 8.1) of the security requirements derived from the discussion in the rddp-security draft. There's also a discussion of security services in RFC4296, the DDP and RDMA Architecture. E.g.: Peer connections that do not pass authentication and authorization checks must not be permitted to begin processing in RDMA mode with an inappropriate endpoint. Once associated, peer accesses to buffer regions must be authenticated and made subject to authorization checks in the context of the association and endpoint (socket) on which they are to be performed, prior to any transfer operation or data being accessed. The RDMA protocols must ensure that these region protections be under strict application control. Of course there's the question of relating the authentication and authorization done by RPC_GSSAPI to the protection domain of the RDMA security, and both to the SA of the IPSec if that is used to protect the RDMA transfer. Perhaps this is just one channel binding, perhaps it is channel binding squared, perhaps the CCM referenced in the rpsrdma draft is sufficient for both. I just can't tell. A process question. This draft (and the rpcrdma draft) contain a normative reference called "rfc1831bis", with a title of R. Thurlow, Ed., "RPC: Remote Procedure Call Protocol Specification Version 2", Standards Track RFC That would seem to be a reference to draft-ietf-nfsv4-rfc1831bis-06.txt, but the I-D Tracker has that listed as "Dead". Also. Not my job, but the rpcrdma draft has a reference: [CCM] M. Eisler, N. Williams, "CCM: The Credential Cache GSS Mechanism", Internet Draft Work in Progress, draft-ietf- nfsv4-ccm But on tools.ietf.org (the draft has expired from the internet-drafts list, but at least it is still called "I-D Exists" in the I-D Tracker) the title is: The Channel Conjunction Mechanism (CCM) for GSS draft-ietf-nfsv4-ccm-03 Another not-my-job question. The rpcrdma draft and the rddp-security draft both mention transport over Infiniband, but everything that I've been able to find imply that Infiniband is not an IP protocol. So IPSec would not apply, presumably. Do the discussions of security in the nfsv4 and rddp drafts still work if Infiniband is the RDMA transport? In particular, rddp-security says For RDDP, IPsec is the better choice for a security framework, and hence is mandatory-to-implement (as specified elsewhere in this document). Also, the rddp-security draft seems to assume the reliable, ordered delivery of TCP, and I can not tell if that is provided by Infiniband. --Sandy _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 18 10:04:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiVcY-0007KH-1j; Thu, 18 Oct 2007 09:41:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiVcU-0007HU-Vl; Thu, 18 Oct 2007 09:41:02 -0400 Received: from smtp.aaisp.net.uk ([2001:8b0:0:81::51bb:5133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiVcJ-00028c-MN; Thu, 18 Oct 2007 09:41:02 -0400 Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.62) (envelope-from ) id 1IiVbt-00088g-4d; Thu, 18 Oct 2007 14:40:25 +0100 Message-ID: <471762D3.1020504@dial.pipex.com> Date: Thu, 18 Oct 2007 14:42:43 +0100 From: Elwyn Davies User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: General Area Review Team Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Clear (Version: ClamAV 0.91.2/4545/Wed Oct 17 22:05:57 2007, by smtp.aaisp.net.uk) X-Spam-Score: -93.1 (---------------------------------------------------) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: jani.peltotalo@tut.fi, rmt-chairs@ietf.org, IETF Discussion , Magnus Westerlund , vincent.roca@inrialpes.fr, jerome.lacan@isae.fr, Mary Barnes , sami.peltotalo@tut.fi Subject: Gen-art review of draft-ietf-rmt-bb-fec-rs-04.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-rmt-bb-fec-rs-04.txt Reviewer: Elwyn Davies Review Date: 18 October 2007 IETF LC End Date: 25 October 2007 IESG Telechat date: (if known) - Summary: Almost ready for IESG. I found one very minor issue and a few editorial nits (see below). I think a reference to a theoretical and/or algorithmic treatment of Reed-Solomon codes and their use of Vandermonde matrices would be helpful to assist should anybody be masochistic enough to want to recode the Rizzo codec from scratch. Caveat: I am not skilled in the FEC art and although I have enough maths to understand what is going on I have not been able to check that the descriptions in ss8.1-8.3 are (sufficiently) complete and correct. Comments: I am not an expert in error correcting codes (although I am a mathematician with enough background to understand roughly what is going on), so I haven't checked the exact details of the algorithm descriptions in gory detail - I assume the experts have! More importantly, given that this document sort of assumes that any sane person would use Rizzo's code, we need to be sure that there is enough detail to be able to independently code a protocol/codec without resort to the Rizzo code. I have a reasonably warm fuzzy feeling that this is the case, given that the Reed-Solomon system is well-known and the protocol is pretty much independent of the algorithm details, but it would be good to have (1) assurance from an expert that this is so and (2) a suitable reference to a theoretical description of the algorithms that could help with an independent implementation. s6.1: The units of 'rate' are not specified and I can't find anything relevant in the FLUTE spec (for example). Also affects s6.2. Editorial: General: Using symbolic rather than numeric references is preferred. General: The meaning of the symbols '^^' (exponentiation) and 'log^^n' (preseumably log to the base n) should be explained. Abstract/s1: the terms 'erasure' and 'packet erasure channel' are well known jargon in the FEC art, but they are obscure for general readers. Using a non-jargon term in the abstract would be desirable and pointing at [4] - RFC 3453 - for a definition of terms including erasure would be useful. s1: It would be useful to point more specifically to RFC 5052 for the definition of the terms Fully- and Under-Specified FEC Scheme. s6.1: s/equal than/equal to/, s/associated to/associated with/ s8: An external reference explaining the theory of Reed-Solomon codes and the use of Vandermonde matrices would be useful. s9.2: Acronyms ECC and IPR need expanding - maybe also better to say 'ECC is the subject of proprietary patents' rather than 'protected by IPR'. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 18 10:40:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWOI-0007qf-KX; Thu, 18 Oct 2007 10:30:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWOG-0007SM-AZ for ietf@ietf.org; Thu, 18 Oct 2007 10:30:24 -0400 Received: from yxa.extundo.com ([83.241.177.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiWO4-0004Ko-Ep for ietf@ietf.org; Thu, 18 Oct 2007 10:30:12 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l9IEU5nB022282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Oct 2007 16:30:06 +0200 From: Simon Josefsson To: Tim Polk References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071018:tim.polk@nist.gov::YNeMD2VbJacie0sJ:0y+T X-Hashcash: 1:22:071018:ietf@ietf.org::/wObaRmvHmwQEdHT:By6H Date: Thu, 18 Oct 2007 16:30:05 +0200 In-Reply-To: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> (Tim Polk's message of "Wed, 26 Sep 2007 14:28:25 -0400") Message-ID: <87y7e08phu.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by yxa.extundo.com id l9IEU5nB022282 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ietf@ietf.org Subject: Re: Third Last Call: draft-housley-tls-authz-extns X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Tim Polk writes: >>> The IESG solicits final comments on whether the IETF community has >>> consensus to publish draft-housley-tls-authz-extns as an experimental >>> standard given the IPR claimed. Comments can be sent to ietf@ietf.org >>> or exceptionally to iesg@ietf.org. Comments should be sent by >>> 2007-10-23. >> >> I was negative to publication during the earlier last calls, and I >> continue to be so. The primary reason remains the uncertainty of the >> IPR situation. It is not clear to me that I can implement this >> protocol >> freely without the burden of patent licenses. I'm speaking as a free >> software implementer of this document (see GnuTLS, ). > > As the sponsoring AD, I would like to explain why I support publication > as an Experimental RFC. To quote RFC 2026, =E2=80=9CSuch a specificati= on is > published for the general information of the Internet technical > community > and as an archival record of the work.=E2=80=9D Given the technical mer= its of > the > document and the existence of independent implementations, I believe > it is in the interest of the community to have an archival record of > this work. I believe that is a poor argument, because the only implementation I am aware of is the one I wrote. And I'm opposed to publication of the document. To clarify that the part of the community that I'm a member of is not interested in supporting this technology, we have decided to remove our implementation. See the announcement for GnuTLS in: ** TLS authorization support removed. This technique may be patented in the future, and it is not of crucial importance for the Internet community. After deliberation we have concluded that the best thing we can do in this situation is to encourage society not to adopt this technique. We have decided to lead the way with our own actions. I hope you will reconsider sponsoring the document. /Simon _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 18 11:19:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWwY-0006Vk-Vv; Thu, 18 Oct 2007 11:05:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWwV-0006T3-Un for ietf@ietf.org; Thu, 18 Oct 2007 11:05:47 -0400 Received: from woodstock.binhost.com ([8.8.40.152]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IiWwV-0005UI-LU for ietf@ietf.org; Thu, 18 Oct 2007 11:05:47 -0400 Received: (qmail 4215 invoked by uid 0); 18 Oct 2007 15:05:44 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.231.48.203) by woodstock.binhost.com with SMTP; 18 Oct 2007 15:05:44 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 18 Oct 2007 11:05:38 -0400 To: Simon Josefsson ,Tim Polk From: Russ Housley In-Reply-To: <87y7e08phu.fsf@mocca.josefsson.org> References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ietf@ietf.org Subject: Re: Third Last Call: draft-housley-tls-authz-extns X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Message-Id: Simon: >I believe that is a poor argument, because the only implementation I am >aware of is the one I wrote. And I'm opposed to publication of the >document. I am aware of two others. I do not think it is appropriate for me to indicate the sources of the implementations; their authors should do that ... However, I will say that one comes from a commercial source and the other comes from an academic source. Russ _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 18 13:09:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiYX2-00023M-DU; Thu, 18 Oct 2007 12:47:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiYX0-0001bv-HP for ietf@ietf.org; Thu, 18 Oct 2007 12:47:34 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiYWq-0000py-Sp for ietf@ietf.org; Thu, 18 Oct 2007 12:47:25 -0400 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l9IGhmYQ032697; Thu, 18 Oct 2007 09:43:48 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 09:47:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Oct 2007 09:47:12 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Third Last Call: draft-housley-tls-authz-extns Thread-Index: AcgRlVwx2A7z8rlUTUuKkLgUG0GwcQACbDwg References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> From: "Hallam-Baker, Phillip" To: "Simon Josefsson" , "Tim Polk" X-OriginalArrivalTime: 18 Oct 2007 16:47:12.0966 (UTC) FILETIME=[88564E60:01C811A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: ietf@ietf.org Subject: RE: Third Last Call: draft-housley-tls-authz-extns X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1515930319==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============1515930319== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C811A6.8806B6DD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C811A6.8806B6DD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think we need to be careful when it comes to IPR, if we are not = careful we can allow anyone to exercise a veto on any spec they choose = without being required to substantiate it. =20 There is a balance here between ensuring that a patent holder does not = unjustly enrich themselves by enforcing rights to an inconsequential, = undisclosed, unnecessary or otherwise bogus patent claim on the one hand = and ensuring that a purported patent holder does not exercise undue = influence on the standards process by making a claim that they stand = little or no chance of being able to enforce in a court. =20 We have an IPR committee but I think that is part of the problem, not = the solution. The IETF should not sit down and draft IPR rules. We = should act like a standards body and recognize rules that have already = been established elsewhere. The W3C went through this whole process once = and obtained the agreement of the major IPR stakeholders and the open = source movement. I see no reason at all to duplicate that effort. = Members of W3C staff have informally indicated that they would be = willing to release the document on a creative commons license. =20 I don't think we should be having regular discussions on the details of = IPR policy here on the IETF list as we keep doing. Given the layer in = the stack where the IETF operates it is not practical for us to have a = blanket policy as W3C does that all standards be on completely open IPR = terms. There are some areas where this is simply not possible - PKI in = the era of Public Key Partners for example. We can however adopt rules = similar to those at OASIS that create a strong bias towards open IPR = terms without making open IPR a mandatory criteria.=20 =20 What I would suggest is that new working groups be required to specify = the governing IPR rules in their charter, these would be either that all = IPR must be offered according to an open grant on W3C terms or that the = working group specifies at the outset that RAND terms are acceptable. =20 By making the process all or nothing the bargainng leverage of the IETF = is enhanced. Allowing each WG to negotiate separately weakens their = bargaining power as any agreement that the IPR holder makes will be = applied as binding precedent on them but not on others. Any future = working group will expect to be offered terms at least as generous as = those offered in the past from that particular IPR holder but the IPR = holder cannot expect their competitors to be held to the same standard. ________________________________ From: Simon Josefsson [mailto:simon@josefsson.org] Sent: Thu 18/10/2007 10:30 AM To: Tim Polk Cc: ietf@ietf.org Subject: Re: Third Last Call: draft-housley-tls-authz-extns Tim Polk writes: >>> The IESG solicits final comments on whether the IETF community has >>> consensus to publish draft-housley-tls-authz-extns as an = experimental >>> standard given the IPR claimed. Comments can be sent to = ietf@ietf.org >>> or exceptionally to iesg@ietf.org. Comments should be sent by >>> 2007-10-23. >> >> I was negative to publication during the earlier last calls, and I >> continue to be so. The primary reason remains the uncertainty of the >> IPR situation. It is not clear to me that I can implement this >> protocol >> freely without the burden of patent licenses. I'm speaking as a free >> software implementer of this document (see GnuTLS, ). > > As the sponsoring AD, I would like to explain why I support = publication > as an Experimental RFC. To quote RFC 2026, "Such a specification is > published for the general information of the Internet technical > community > and as an archival record of the work." Given the technical merits of > the > document and the existence of independent implementations, I believe > it is in the interest of the community to have an archival record of > this work. I believe that is a poor argument, because the only implementation I am aware of is the one I wrote. And I'm opposed to publication of the document. To clarify that the part of the community that I'm a member of is not interested in supporting this technology, we have decided to remove our implementation. See the announcement for GnuTLS in: ** TLS authorization support removed. This technique may be patented in the future, and it is not of crucial importance for the Internet community. After deliberation we have concluded that the best thing we can do in this situation is to encourage society not to adopt this technique. We have decided to lead the way with our own actions. I hope you will reconsider sponsoring the document. /Simon _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ------_=_NextPart_001_01C811A6.8806B6DD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Third Last Call: = draft-housley-tls-authz-extns=0A= =0A= =0A= =0A=
=0A=
I think we = need to be careful when it comes to IPR, if we are not careful we can = allow anyone to exercise a veto on any spec they choose without being = required to substantiate it.
=0A=
 
=0A=
There is a balance here = between ensuring that a patent holder does not unjustly enrich = themselves by enforcing rights to an inconsequential, undisclosed, = unnecessary or otherwise bogus patent claim on the one hand and ensuring = that a purported patent holder does not exercise undue influence on = the standards process by making a claim that they stand little or no = chance of being able to enforce in a court.
=0A=
 
=0A=
We have an IPR committee but = I think that is part of the problem, not the solution. The IETF should = not sit down and draft IPR rules. We should act like a standards body = and recognize rules that have already been established elsewhere. The = W3C went through this whole process once and obtained the agreement of = the major IPR stakeholders and the open source movement. I see no reason = at all to duplicate that effort. Members of W3C staff have informally = indicated that they would be willing to release the document on a = creative commons license.
=0A=
 
=0A=
I don't think we should be = having regular discussions on the details of IPR policy here on the IETF = list as we keep doing. Given the layer in the stack where the IETF = operates it is not practical for us to have a blanket policy as W3C does = that all standards be on completely open IPR terms. There are some areas = where this is simply not possible - PKI in the era of Public Key = Partners for example. We can however adopt rules similar to those at = OASIS that create a strong bias towards open IPR terms without making = open IPR a mandatory criteria.
=0A=
 
=0A=
What I would suggest is that = new working groups be required to specify the governing IPR rules in = their charter, these would be either that all IPR must be offered = according to an open grant on W3C terms or that the working group = specifies at the outset that RAND terms are acceptable.
=0A=
 
=0A=
By making the process all or = nothing the bargainng leverage of the IETF is enhanced. Allowing each WG = to negotiate separately weakens their bargaining power as any agreement = that the IPR holder makes will be applied as binding precedent on them = but not on others. Any future working group will expect to be offered = terms at least as generous as those offered in the past from that = particular IPR holder but the IPR holder cannot expect their competitors = to be held to the same standard.
=0A=

=0A=
=0A= From: Simon Josefsson = [mailto:simon@josefsson.org]
Sent: Thu 18/10/2007 10:30 = AM
To: Tim Polk
Cc: ietf@ietf.org
Subject: = Re: Third Last Call: draft-housley-tls-authz-extns

=0A=
=0A=

Tim Polk <tim.polk@nist.gov> = writes:

>>> The IESG solicits final comments on whether = the IETF community has
>>> consensus to publish = draft-housley-tls-authz-extns as an experimental
>>> = standard given the IPR claimed. Comments can be sent to = ietf@ietf.org
>>> or exceptionally to iesg@ietf.org. = Comments should be sent by
>>> = 2007-10-23.
>>
>> I was negative to publication during = the earlier last calls, and I
>> continue to be so.  The = primary reason remains the uncertainty of the
>> IPR = situation.  It is not clear to me that I can implement = this
>> protocol
>> freely without the burden of = patent licenses.  I'm speaking as a free
>> software = implementer of this document (see GnuTLS, = <www.gnutls.org>).
>
> As the sponsoring AD, I would = like to explain why I support publication
> as an Experimental = RFC.  To quote RFC 2026, “Such a specification is
> = published for the general information of the Internet technical
> = community
> and as an archival record of the work.” Given = the technical merits of
> the
> document and the existence = of independent implementations, I believe
> it is in the interest = of the community to have an archival record of
> this = work.

I believe that is a poor argument, because the only = implementation I am
aware of is the one I wrote.  And I'm = opposed to publication of the
document.

To clarify that the = part of the community that I'm a member of is not
interested in = supporting this technology, we have decided to remove = our
implementation.  See the announcement for GnuTLS = in:

  ** TLS authorization support removed.
  This = technique may be patented in the future, and it is not of = crucial
  importance for the Internet community.  After = deliberation we have
  concluded that the best thing we can do = in this situation is to
  encourage society not to adopt this = technique.  We have decided to
  lead the way with our own = actions.
  <http= ://permalink.gmane.org/gmane.network.gnutls.general/955>

I = hope you will reconsider sponsoring the = document.

/Simon

__________________________________________= _____
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.or= g/mailman/listinfo/ietf

------_=_NextPart_001_01C811A6.8806B6DD-- --===============1515930319== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============1515930319==-- From ietf-bounces@ietf.org Thu Oct 18 17:45:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iicu4-0001hn-5d; Thu, 18 Oct 2007 17:27:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iicu1-0001Zm-Ek for ietf@ietf.org; Thu, 18 Oct 2007 17:27:37 -0400 Received: from rv-out-0910.google.com ([209.85.198.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IictZ-0001VO-Ep for ietf@ietf.org; Thu, 18 Oct 2007 17:27:37 -0400 Received: by rv-out-0910.google.com with SMTP id l15so237408rvb for ; Thu, 18 Oct 2007 14:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=l0OnwYd0jEj/iMcNwZwm3Ov2J8ItjcNdPFYVe8K9NDw=; b=tmd+S5K0ls4cjW/qN9u54Fwmk0d33lpH1MCY2dpC5yT7/x/NOc+o9406Ca9w8R2+LQas0cca4pSxFzP+rrgBW9yPusvoQhHv5srFvuLehYpuG9vfc944GK1URHJdToPk8CeYSLwyJHD+JyylBt9RNjSenydqGj8/q3alOGGkVRs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=NEqJn5scGTEhkeiLP3pFfs1CnbVn+7BXlDfAgVNWdKt8cXuAmbsmwdMvZb49T4TNDJYu1gs60lrVVR5561y5dt/ajDJjjFEUOylePXyuh5OskmVGUuPQw0hEbBRN/UwkITifr+NYM0ULl6zB5tiNMyMrXNwYAkWoC7lFkTy/tVY= Received: by 10.114.196.1 with SMTP id t1mr1154120waf.1192742802806; Thu, 18 Oct 2007 14:26:42 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id j6sm2417695wah.2007.10.18.14.26.37 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Oct 2007 14:26:39 -0700 (PDT) Message-ID: <4717CF89.5070206@gmail.com> Date: Fri, 19 Oct 2007 10:26:33 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Simon Josefsson References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> In-Reply-To: <87y7e08phu.fsf@mocca.josefsson.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Tim Polk , ietf@ietf.org Subject: Re: Third Last Call: draft-housley-tls-authz-extns X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-19 03:30, Simon Josefsson wrote: ... > To clarify that the part of the community that I'm a member of is not > interested in supporting this technology, we have decided to remove our > implementation. See the announcement for GnuTLS in: > > ** TLS authorization support removed. > This technique may be patented in the future, and it is not of crucial > importance for the Internet community. After deliberation we have > concluded that the best thing we can do in this situation is to > encourage society not to adopt this technique. We have decided to > lead the way with our own actions. > I don't consider that a good argument for censoring the document. We might consider publishing it as Informational, like other RFCs that are published "for the record" . This means deciding between guidelines 3 and 4 in http://www.ietf.org/u/ietfchair/info-exp.html. (BTW, should that be an ION?) Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 18 17:45:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iicxq-0000gd-Ly; Thu, 18 Oct 2007 17:31:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iicxp-0000gX-Aq for ietf@ietf.org; Thu, 18 Oct 2007 17:31:33 -0400 Received: from wa-out-1112.google.com ([209.85.146.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iicxj-0001dh-5N for ietf@ietf.org; Thu, 18 Oct 2007 17:31:33 -0400 Received: by wa-out-1112.google.com with SMTP id k40so502195wah for ; Thu, 18 Oct 2007 14:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=ycbaXkODLG5pP2SgxM2SdeMMdiKMunevIqMEGzNTYYY=; b=IIBKz3j8XlNlI6GRNNVSkpKGE4fblHkJjzlH5HG32LYk/Y+mFeokObZY44NXRu/t++XdfcOUb+2IsfwZPJFikXH6Np79gSp4GHA+ftocKOjLr27sLdYJbk+Z4cnnhbU/rjjbmHAQBzmXYLSeVdRKzu0YuYFC7jW+bDYkV5kjdU0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=r/CtQ3ZCkpaHq1QRfyCFaSU1fBsegOYzgv3Zz+AM3E7jbYgR49UaxSLDpc2acrU4jRMh139LqCxwaJiop8nDrzLlBa4YreYYituDIfu9Iv55hYMgjx7aPxRYWTw7ZubXgQQuMpc8W2uGpRJpEEc7ORkl2qxhK142cHtB5YhXcMc= Received: by 10.115.107.1 with SMTP id j1mr1170133wam.1192743067119; Thu, 18 Oct 2007 14:31:07 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id n37sm2418562wag.2007.10.18.14.31.02 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Oct 2007 14:31:05 -0700 (PDT) Message-ID: <4717D090.1000908@gmail.com> Date: Fri, 19 Oct 2007 10:30:56 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Simon Josefsson , ietf@ietf.org, Tim Polk Subject: A priori IPR choices [Re: Third Last Call: draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-19 05:47, Hallam-Baker, Phillip wrote: ... > What I would suggest is that new working groups be required to specify the governing IPR rules in their charter, these would be either that all IPR must be offered according to an open grant on W3C terms or that the working group specifies at the outset that RAND terms are acceptable. Violent disagreement. That would make all kinds of a priori processes kick in for employees of patent-conscious companies, and generally inhibit free discussion of initial ideas. Although it's messier to confront patent issues later in the process, I believe that is much better than constraining participation at the beginning. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 18 18:23:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iidbe-0002jq-TY; Thu, 18 Oct 2007 18:12:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iidbd-0002gy-CG for ietf@ietf.org; Thu, 18 Oct 2007 18:12:41 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IidbR-0003VT-TX for ietf@ietf.org; Thu, 18 Oct 2007 18:12:37 -0400 X-IronPort-AV: E=Sophos;i="4.21,297,1188802800"; d="scan'208";a="239469518" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 18 Oct 2007 15:12:24 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l9IMCObH020190; Thu, 18 Oct 2007 15:12:24 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9IMCNx7014198; Thu, 18 Oct 2007 22:12:23 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 18:12:23 -0400 Received: from swbmbp.local.employees.org ([10.86.240.212]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 18:12:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18199.55877.791858.498365@swbmbp.local> Date: Thu, 18 Oct 2007 18:12:21 -0400 From: Scott Brim To: Brian E Carpenter In-Reply-To: <4717D090.1000908@gmail.com> References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> X-Mailer: VM 8.0.3-495 under Emacs 22.1.1 (i386-apple-darwin8.10.1) X-OriginalArrivalTime: 18 Oct 2007 22:12:23.0061 (UTC) FILETIME=[F5428C50:01C811D3] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15490.002 X-TM-AS-Result: No--15.165800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Authentication-Results: sj-dkim-4; header.From=swb@employees.org; dkim=neutral X-Spam-Score: -4.0 (----) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Simon Josefsson , ietf@ietf.org, Tim Polk Subject: A priori IPR choices [Re: Third Last Call: draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 19 Oct 2007 at 10:30 +1300, Brian E Carpenter allegedly wrote: > On 2007-10-19 05:47, Hallam-Baker, Phillip wrote: > > What I would suggest is that new working groups be required to > > specify the governing IPR rules in their charter, these would be > > either that all IPR must be offered according to an open grant on > > W3C terms or that the working group specifies at the outset that > > RAND terms are acceptable. > > Violent disagreement. That would make all kinds of a priori > processes kick in for employees of patent-conscious companies, and > generally inhibit free discussion of initial ideas. Although it's > messier to confront patent issues later in the process, I believe > that is much better than constraining participation at the > beginning. +1 Otherwise you get into battles over theory and ideology without any of the information you need to make a decision. You will still be able to take your stance once the technical tradeoffs are worked out. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 18 18:46:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IidwG-0002Ea-1O; Thu, 18 Oct 2007 18:34:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IidwD-0002D1-Un for ietf@ietf.org; Thu, 18 Oct 2007 18:33:57 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IidwD-0004Lf-HV for ietf@ietf.org; Thu, 18 Oct 2007 18:33:57 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 0B9BD33C21; Thu, 18 Oct 2007 15:29:40 -0700 (PDT) Date: Thu, 18 Oct 2007 15:29:40 -0700 From: Eric Rescorla To: Brian E Carpenter In-Reply-To: <4717CF89.5070206@gmail.com> References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <4717CF89.5070206@gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071018222941.0B9BD33C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Simon Josefsson , ietf@ietf.org, Tim Polk Subject: Re: Third Last Call: draft-housley-tls-authz-extns X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At Fri, 19 Oct 2007 10:26:33 +1300, Brian E Carpenter wrote: > > On 2007-10-19 03:30, Simon Josefsson wrote: > > ... > > > To clarify that the part of the community that I'm a member of is not > > interested in supporting this technology, we have decided to remove our > > implementation. See the announcement for GnuTLS in: > > > > ** TLS authorization support removed. > > This technique may be patented in the future, and it is not of crucial > > importance for the Internet community. After deliberation we have > > concluded that the best thing we can do in this situation is to > > encourage society not to adopt this technique. We have decided to > > lead the way with our own actions. > > > > I don't consider that a good argument for censoring the document. > > We might consider publishing it as Informational, like other RFCs > that are published "for the record" . This means deciding between > guidelines 3 and 4 in http://www.ietf.org/u/ietfchair/info-exp.html. > > (BTW, should that be an ION?) Brian, I don't really have a strong opinion about whether this document should be published as Experimental, Informational, or not at all, but I don't really understand your argument here: 1. I don't see how this is an issue of censorship. It's not like the authors couldn't publish the document on their Web site or wherever. 2. The issue isn't so much document publication as the code point assignment that goes with it. -Ekr _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 18 18:55:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iie9j-0007Py-5a; Thu, 18 Oct 2007 18:47:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iie9g-0007O2-5a for ietf@ietf.org; Thu, 18 Oct 2007 18:47:52 -0400 Received: from rv-out-0910.google.com ([209.85.198.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iie9U-0004YS-TV for ietf@ietf.org; Thu, 18 Oct 2007 18:47:52 -0400 Received: by rv-out-0910.google.com with SMTP id l15so251178rvb for ; Thu, 18 Oct 2007 15:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=HXKLNiRTQzw5TGBgf/pc1vTK9XrEdvDvC4VF4H262WE=; b=MGnM6pKSWJGRlovzOE2ZyKwPxEHkSHymKINC5bs1854S0/bv4qBOC3hHpiRiOvX1IAfJpiR/3E+dv7HrSVYvRY/12jbvEG1AM2kdZBe/pZbfGmUPt0stOQTPZHDee1hpK/izjTNs1lmqRfn0cOeeobKkkYono+Kj4mDNfQSVrG0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=OdzjM/8/zxWqrBA8o95vixjN3grF08mQd+d3baQUI/d4dT/EF5B+qqY3Fr47rPsZDSoy1nzyU7Ak3MRVwJH9hrbmLlqYVIUBJAw1k1mjI3OA37LHsFSpz3zgDHO6IlGdhQP5H20RTCRIjUW/MWQg+WjgkrDQD7u0zDHIVE84jVs= Received: by 10.140.136.6 with SMTP id j6mr643043rvd.1192747641355; Thu, 18 Oct 2007 15:47:21 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id 2sm2624224rvi.2007.10.18.15.47.19 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Oct 2007 15:47:20 -0700 (PDT) Message-ID: <4717E26C.2050003@gmail.com> Date: Fri, 19 Oct 2007 11:47:08 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eric Rescorla References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <4717CF89.5070206@gmail.com> <20071018222941.0B9BD33C21@delta.rtfm.com> In-Reply-To: <20071018222941.0B9BD33C21@delta.rtfm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Simon Josefsson , ietf@ietf.org, Tim Polk Subject: Re: Third Last Call: draft-housley-tls-authz-extns X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-19 11:29, Eric Rescorla wrote: > At Fri, 19 Oct 2007 10:26:33 +1300, > Brian E Carpenter wrote: >> On 2007-10-19 03:30, Simon Josefsson wrote: >> >> ... >> >>> To clarify that the part of the community that I'm a member of is not >>> interested in supporting this technology, we have decided to remove our >>> implementation. See the announcement for GnuTLS in: >>> >>> ** TLS authorization support removed. >>> This technique may be patented in the future, and it is not of crucial >>> importance for the Internet community. After deliberation we have >>> concluded that the best thing we can do in this situation is to >>> encourage society not to adopt this technique. We have decided to >>> lead the way with our own actions. >>> >> I don't consider that a good argument for censoring the document. >> >> We might consider publishing it as Informational, like other RFCs >> that are published "for the record" . This means deciding between >> guidelines 3 and 4 in http://www.ietf.org/u/ietfchair/info-exp.html. >> >> (BTW, should that be an ION?) > > Brian, > > I don't really have a strong opinion about whether this document > should be published as Experimental, Informational, or not at > all, but I don't really understand your argument here: > > 1. I don't see how this is an issue of censorship. It's not like > the authors couldn't publish the document on their Web site > or wherever. > 2. The issue isn't so much document publication as the code > point assignment that goes with it. I guess I was over-reacting to Simon's style of argument. A more reasoned comment is that I don't see a categorical difference between this and many other proposals that have been published as RFCs in the past, after failing to make it onto the standards track, but are known to have been implemented. As far as a code point goes, that's a question of whether the appropriate IANA Considerations are met, and you know a lot more about that for TLS than I do. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 18 19:20:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IieWr-0004qx-BO; Thu, 18 Oct 2007 19:11:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IieWo-0004ZC-V3 for ietf@ietf.org; Thu, 18 Oct 2007 19:11:46 -0400 Received: from mail26j.sbc-webhosting.com ([216.173.236.231]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IieWd-0005HM-FV for ietf@ietf.org; Thu, 18 Oct 2007 19:11:41 -0400 Received: from mx30.stngva01.us.mxservers.net (204.202.242.41) by mail26j.sbc-webhosting.com (RS ver 1.0.95vs) with SMTP id 3-0486739083 for ; Thu, 18 Oct 2007 19:11:24 -0400 (EDT) Received: from mmm2630.sbc-webhosting.com [216.173.237.89] (EHLO mmm2630.sbc-webhosting.com) by mx30.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id b18e7174.6674.262.mx30.stngva01.us.mxservers.net; Thu, 18 Oct 2007 19:11:23 -0400 (EDT) Received: (qmail 18249 invoked from network); 18 Oct 2007 23:11:21 -0000 Received: from unknown (HELO LROSENTOSHIBA) (lrosen@208.106.45.202) by with ESMTPA; 18 Oct 2007 23:11:21 -0000 From: "Lawrence Rosen" To: References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov><87y7e08phu.fsf@mocca.josefsson.org><2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com><4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> Date: Thu, 18 Oct 2007 16:10:01 -0700 Organization: Rosenlaw & Einschlag Message-ID: <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <18199.55877.791858.498365@swbmbp.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgR1idL8mDjoxEdRRWp3fwJVbJrvQAA+50g X-Spam: [F=0.0100000000; heur=0.500(-26100); stat=0.010; spamtraq-heur=0.500(2007082706)] X-MAIL-FROM: X-SOURCE-IP: [216.173.237.89] X-SF-Loop: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: RE: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lrosen@rosenlaw.com List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org [I stripped cc's from this reply] Brian Carpenter wrote: > > Violent disagreement. That would make all kinds of a priori > > processes kick in for employees of patent-conscious companies, and > > generally inhibit free discussion of initial ideas. Although it's > > messier to confront patent issues later in the process, I believe > > that is much better than constraining participation at the > > beginning. Scott Brim responded: > +1 > Otherwise you get into battles over theory and ideology without any of > the information you need to make a decision. You will still be able > to take your stance once the technical tradeoffs are worked out. > Strong -1 to Brian's and Scott's comments. Isn't it preferable to get into early battles over IP rules--and make sure those rules are clear to WG participants--before we have wasted our time and resources developing specifications that half the world (or more) can't implement? Has anyone ever suggested that we inhibit "free discussion of initial ideas"? Please don't raise silly arguments like that. Among the most exciting discussions of ideas are those that come from having to design around a patent that isn't available for free. /Larry Rosen > -----Original Message----- > From: Scott Brim [mailto:swb@employees.org] > Sent: Thursday, October 18, 2007 3:12 PM > To: Brian E Carpenter > Cc: Simon Josefsson; ietf@ietf.org; Tim Polk > Subject: A priori IPR choices [Re: Third Last Call:draft-housley-tls- > authz-extns] > > On 19 Oct 2007 at 10:30 +1300, Brian E Carpenter allegedly wrote: > > On 2007-10-19 05:47, Hallam-Baker, Phillip wrote: > > > What I would suggest is that new working groups be required to > > > specify the governing IPR rules in their charter, these would be > > > either that all IPR must be offered according to an open grant on > > > W3C terms or that the working group specifies at the outset that > > > RAND terms are acceptable. > > > > Violent disagreement. That would make all kinds of a priori > > processes kick in for employees of patent-conscious companies, and > > generally inhibit free discussion of initial ideas. Although it's > > messier to confront patent issues later in the process, I believe > > that is much better than constraining participation at the > > beginning. > > +1 > > Otherwise you get into battles over theory and ideology without any of > the information you need to make a decision. You will still be able > to take your stance once the technical tradeoffs are worked out. > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 18 20:05:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iif5Q-0001je-Oy; Thu, 18 Oct 2007 19:47:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iif5P-0001br-8L for ietf@ietf.org; Thu, 18 Oct 2007 19:47:31 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iif3f-0006KI-22 for ietf@ietf.org; Thu, 18 Oct 2007 19:47:21 -0400 Received: by wa-out-1112.google.com with SMTP id k40so541237wah for ; Thu, 18 Oct 2007 16:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=lG1QOJjqy2iilqOxc2B8l3zCmWXKe8h1PM57KXrwpKg=; b=UB+sy4Df3R2y1EGsXTezvFusw/4nEs9FICfraYPzfAmt+42X7AoGaA/8zXbTEHSaEkY2awr3hUd/OgyCzVFR8wjcmCvsbxaFPqlE4YWan3gmoxiifBGHR2Zy2FjfflV0VYQLS0lXrFng3fLbRQrwftifUGvELUV43+dMEptDMH4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Ynoex20j9WIjeLvow3dB/GxRFlbSBQHWc3KjqRyPTuguosT6ehyOsBv0GA+e4BULunbW1swvDXMyk39jFK/kvoyD262zMmjDF9Mcqkis5LBQEbH4TnTeX2n63h0TPJXwgHdvcv8JcFYI9J8o8HSTyBnL20AIMHSTTmZ6ZN+ndvY= Received: by 10.114.156.1 with SMTP id d1mr1295700wae.1192751116769; Thu, 18 Oct 2007 16:45:16 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id n37sm2629333wag.2007.10.18.16.45.15 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Oct 2007 16:45:16 -0700 (PDT) Message-ID: <4717F00A.8040504@gmail.com> Date: Fri, 19 Oct 2007 12:45:14 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: lrosen@rosenlaw.com References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov><87y7e08phu.fsf@mocca.josefsson.org><2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com><4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> In-Reply-To: <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-19 12:10, Lawrence Rosen wrote: > [I stripped cc's from this reply] > > Brian Carpenter wrote: >>> Violent disagreement. That would make all kinds of a priori >>> processes kick in for employees of patent-conscious companies, and >>> generally inhibit free discussion of initial ideas. Although it's >>> messier to confront patent issues later in the process, I believe >>> that is much better than constraining participation at the >>> beginning. > > Scott Brim responded: >> +1 >> Otherwise you get into battles over theory and ideology without any of >> the information you need to make a decision. You will still be able >> to take your stance once the technical tradeoffs are worked out. >> > > Strong -1 to Brian's and Scott's comments. > > Isn't it preferable to get into early battles over IP rules--and make sure > those rules are clear to WG participants--before we have wasted our time and > resources developing specifications that half the world (or more) can't > implement? > > Has anyone ever suggested that we inhibit "free discussion of initial > ideas"? If you work for a large company with a managed approach to innovation and IPR handling, you simply aren't allowed to discuss freely in an SDO unless the SDO's IPR regime has been approved by the company. If you have a different IPR regime for every WG, the stage that in the current IETF is a wide and open discussion (including a BOF), when innovative ideas are put on the table, would be replaced by a careful dance among elephants about hypothetical IPR covering hypothetical technology. That does indeed inhibit free discussion of technical ideas. I don't think we want that, which is why I believe the IETF's IPR regime is just fine as it is. Brian > Please don't raise silly arguments like that. Among the most > exciting discussions of ideas are those that come from having to design > around a patent that isn't available for free. > > /Larry Rosen > > >> -----Original Message----- >> From: Scott Brim [mailto:swb@employees.org] >> Sent: Thursday, October 18, 2007 3:12 PM >> To: Brian E Carpenter >> Cc: Simon Josefsson; ietf@ietf.org; Tim Polk >> Subject: A priori IPR choices [Re: Third Last Call:draft-housley-tls- >> authz-extns] >> >> On 19 Oct 2007 at 10:30 +1300, Brian E Carpenter allegedly wrote: >>> On 2007-10-19 05:47, Hallam-Baker, Phillip wrote: >>>> What I would suggest is that new working groups be required to >>>> specify the governing IPR rules in their charter, these would be >>>> either that all IPR must be offered according to an open grant on >>>> W3C terms or that the working group specifies at the outset that >>>> RAND terms are acceptable. >>> Violent disagreement. That would make all kinds of a priori >>> processes kick in for employees of patent-conscious companies, and >>> generally inhibit free discussion of initial ideas. Although it's >>> messier to confront patent issues later in the process, I believe >>> that is much better than constraining participation at the >>> beginning. >> +1 >> >> Otherwise you get into battles over theory and ideology without any of >> the information you need to make a decision. You will still be able >> to take your stance once the technical tradeoffs are worked out. >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www1.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 18 22:43:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IihVc-0007RZ-5w; Thu, 18 Oct 2007 22:22:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IihVY-0007Mz-91 for ietf@ietf.org; Thu, 18 Oct 2007 22:22:40 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IihVK-0002v1-19 for ietf@ietf.org; Thu, 18 Oct 2007 22:22:35 -0400 Received: from [165.227.249.203] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9J2M3XO028540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Oct 2007 19:22:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> References: <2FCE85A0-6C57-4205-B716-1B371FC3987C @nist.gov><87y7e08phu.fsf@mocca.josefsson.org><2788466ED3E31C418E9ACC5C316 61557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com><4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> Date: Thu, 18 Oct 2007 19:21:55 -0700 To: lrosen@rosenlaw.com From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ietf@ietf.org Subject: RE: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 4:10 PM -0700 10/18/07, Lawrence Rosen wrote: >Isn't it preferable to get into early battles over IP rules--and make sure >those rules are clear to WG participants--before we have wasted our time and >resources developing specifications that half the world (or more) can't >implement? I don't know which of the IETF WGs you have been involved with, but that hasn't been the case for any of the ones I have dealt with. Could you give an example of an WG in which this would have been preferable? My experience has been that IPR issues are much, much more common for work that appears later in a WG's deliverables, not in the initial work. >Has anyone ever suggested that we inhibit "free discussion of initial >ideas"? Please don't raise silly arguments like that. It is not a silly argument. Yes, there are a few engineers in the IETF who like to play armchair lawyer and would love to spend the initial time of WG formation pontificating about IPR, but they are in the small minority. Such a discussion would be of no interest to the folks who want to do good technical work. >Among the most >exciting discussions of ideas are those that come from having to design >around a patent that isn't available for free. Your view of excitement might differ from the large majority of active IETFers. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 18 22:51:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IihrG-0004yp-VQ; Thu, 18 Oct 2007 22:45:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IihrF-0004ui-6O for ietf@ietf.org; Thu, 18 Oct 2007 22:45:05 -0400 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IihrA-0002N6-OK for ietf@ietf.org; Thu, 18 Oct 2007 22:45:01 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l9J2im1L012323; Thu, 18 Oct 2007 22:44:49 -0400 (EDT) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l9J2ij3F028963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Oct 2007 22:44:46 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id l9J2ijkv013416; Thu, 18 Oct 2007 22:44:45 -0400 (EDT) To: secdir@mit.edu, ietf@ietf.org, bsd@cisco.com, bob.briscoe@bt.com, tsvwg-chairs@tools.ietf.org From: Tom Yu Date: Thu, 18 Oct 2007 22:44:45 -0400 Message-ID: Lines: 40 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: secdir review of draft-ietf-tsvwg-ecn-mpls-02.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org This is a review of draft-ietf-tsvwg-ecn-mpls-02.txt. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I am not very familiar with MPLS or Diffserv, but I did read some of the cited MPLS and ECN references in order to understand this document. I mostly agree with the claim in the Security Considerations that this proposal introduces no additional vulnerabilities. However, although this document indicates that using a RFC3540 ECN nonce to detect misbehaving receivers continues to work under this proposal, a RFC3540 nonce can also be used to detect disruption of the end-to-end continuity of ECN signaling. This proposal can compromise the detection of disruptions of end-to-end ECN signaling continuity which occur within a given MPLS domain. I lack the context to determine whether this is a serious problem. The procedure described in RFC3540 relies on the existence of two distinct ECT indications to convey a single bit's worth of nonce data to the receiving transport endpoint. This proposal functionally uses only a single bit to indicate a CM state. If a malicious or malfunctioning element within the MPLS domain clears a CM state set by some LSR, the egress LSR will not set the CE state in the unencapsulated IP packet. Consequently, the receiving transport endpoint acts as if the packet did not have a CE state marked at all, and the sending transport endpoint receives no indication that a problem exists with end-to-end ECN signaling. In effect, the MPLS domain behaves as a single black box router from the perspective of RFC3540, masking any ECN signaling anomalies internal to the MPLS domain. This may be an acceptable consequence of this proposal, but it would be useful to know whether this consequence has been considered. ---Tom _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 19 01:05:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iijri-0000dU-3S; Fri, 19 Oct 2007 00:53:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iijrg-0000Yb-Gx for ietf@ietf.org; Fri, 19 Oct 2007 00:53:40 -0400 Received: from e35.co.us.ibm.com ([32.97.110.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IijrR-0006ib-J0 for ietf@ietf.org; Fri, 19 Oct 2007 00:53:31 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l9J4r58N027346 for ; Fri, 19 Oct 2007 00:53:05 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9J4r4cm351468 for ; Thu, 18 Oct 2007 22:53:04 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l9J4r4WX015682 for ; Thu, 18 Oct 2007 22:53:04 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l9J4r4vq015622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 Oct 2007 22:53:04 -0600 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.14.1/8.12.5) with ESMTP id l9J4r1NX016428 for ; Fri, 19 Oct 2007 00:53:01 -0400 Received: (from narten@localhost) by rotala.raleigh.ibm.com (8.14.1/8.14.1/Submit) id l9J4r1Jo016421 for ietf@ietf.org; Fri, 19 Oct 2007 00:53:01 -0400 Date: Fri, 19 Oct 2007 00:53:01 -0400 From: Thomas Narten Message-Id: <200710190453.l9J4r1Jo016421@rotala.raleigh.ibm.com> To: ietf@ietf.org X-Spam-Score: -4.0 (----) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: Weekly posting summary for ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Total of 83 messages in the last 7 days. script run at: Fri Oct 19 00:53:01 EDT 2007 Messages | Bytes | Who --------+------+--------+----------+------------------------ 7.23% | 6 | 6.99% | 36457 | brian.e.carpenter@gmail.com 3.61% | 3 | 6.91% | 36059 | pbaker@verisign.com 3.61% | 3 | 6.29% | 32821 | dharkins@lounge.org 3.61% | 3 | 5.24% | 27329 | dotis@mail-abuse.org 4.82% | 4 | 3.25% | 16968 | itojun@itojun.org 2.41% | 2 | 4.35% | 22677 | tme@multicasttech.com 3.61% | 3 | 3.11% | 16232 | rpelletier@isoc.org 3.61% | 3 | 2.48% | 12961 | fenner@research.att.com 3.61% | 3 | 2.33% | 12146 | jari.arkko@piuha.net 2.41% | 2 | 3.36% | 17556 | nobody@xyzzy.claranet.de 2.41% | 2 | 3.19% | 16645 | fred@cisco.com 2.41% | 2 | 2.71% | 14124 | hannes.tschofenig@gmx.net 2.41% | 2 | 2.24% | 11706 | tli@cisco.com 2.41% | 2 | 2.16% | 11264 | dts@senie.com 2.41% | 2 | 1.98% | 10338 | iljitsch@muada.com 2.41% | 2 | 1.95% | 10159 | moore@cs.utk.edu 2.41% | 2 | 1.74% | 9098 | eburger@bea.com 2.41% | 2 | 1.62% | 8442 | dhc2@dcrocker.net 1.20% | 1 | 2.11% | 11021 | yaakov_s@rad.com 1.20% | 1 | 1.69% | 8821 | sandy@tislabs.com 1.20% | 1 | 1.50% | 7826 | jmpolk@cisco.com 1.20% | 1 | 1.47% | 7685 | eric.gray@ericsson.com 1.20% | 1 | 1.37% | 7155 | narten@us.ibm.com 1.20% | 1 | 1.35% | 7063 | clint.chaplin@gmail.com 1.20% | 1 | 1.33% | 6941 | lrosen@rosenlaw.com 1.20% | 1 | 1.32% | 6901 | roni.even@polycom.co.il 1.20% | 1 | 1.28% | 6704 | magnus.westerlund@ericsson.com 1.20% | 1 | 1.26% | 6572 | elwynd@dial.pipex.com 1.20% | 1 | 1.21% | 6318 | cnguyen@certicom.com 1.20% | 1 | 1.17% | 6126 | hkaplan@acmepacket.com 1.20% | 1 | 1.17% | 6096 | simon@josefsson.org 1.20% | 1 | 1.16% | 6029 | aboba@internaut.com 1.20% | 1 | 1.10% | 5747 | tlyu@mit.edu 1.20% | 1 | 1.10% | 5714 | mshore@cisco.com 1.20% | 1 | 1.07% | 5571 | swb@employees.org 1.20% | 1 | 0.96% | 5011 | ekr@networkresonance.com 1.20% | 1 | 0.96% | 4997 | smb@cs.columbia.edu 1.20% | 1 | 0.96% | 4985 | paul.hoffman@vpnc.org 1.20% | 1 | 0.95% | 4960 | ldondeti@qualcomm.com 1.20% | 1 | 0.95% | 4955 | joelja@bogus.com 1.20% | 1 | 0.94% | 4928 | pekkas@netcore.fi 1.20% | 1 | 0.91% | 4771 | donald.eastlake@motorola.com 1.20% | 1 | 0.89% | 4670 | lear@cisco.com 1.20% | 1 | 0.87% | 4525 | stbryant@cisco.com 1.20% | 1 | 0.85% | 4422 | mlarson@verisign.com 1.20% | 1 | 0.84% | 4362 | michael.dillon@bt.com 1.20% | 1 | 0.83% | 4323 | jcurran@mail.com 1.20% | 1 | 0.79% | 4139 | weiler@tislabs.com 1.20% | 1 | 0.79% | 4119 | suresh.krishnan@ericsson.com 1.20% | 1 | 0.78% | 4067 | john@jlc.net 1.20% | 1 | 0.74% | 3880 | dassa@dhs.org 1.20% | 1 | 0.73% | 3832 | housley@vigilsec.com 1.20% | 1 | 0.69% | 3592 | jnc@mercury.lcs.mit.edu --------+------+--------+----------+------------------------ 100.00% | 83 |100.00% | 521810 | Total _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 19 05:10:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IinVK-0005Eq-UQ; Fri, 19 Oct 2007 04:46:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IinVI-0004aS-Gx for ietf@ietf.org; Fri, 19 Oct 2007 04:46:48 -0400 Received: from yxa.extundo.com ([83.241.177.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IinV2-0001c9-FW for ietf@ietf.org; Fri, 19 Oct 2007 04:46:32 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l9J8kIAn032646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2007 10:46:22 +0200 From: Simon Josefsson To: Paul Hoffman References: <2FCE85A0-6C57-4205-B716-1B371FC3987C @nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C316 61557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071019:lrosen@rosenlaw.com::Aq6xaAqKJ6vCzp/M:9jbX X-Hashcash: 1:22:071019:ietf@ietf.org::f5KsnwZCkir3gj8Y:PfzV X-Hashcash: 1:22:071019:paul.hoffman@vpnc.org::qMfbwVP3YgEekFLs:GMhw Date: Fri, 19 Oct 2007 10:46:18 +0200 In-Reply-To: (Paul Hoffman's message of "Thu\, 18 Oct 2007 19\:21\:55 -0700") Message-ID: <877iljv6ed.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Paul Hoffman writes: > At 4:10 PM -0700 10/18/07, Lawrence Rosen wrote: >>Isn't it preferable to get into early battles over IP rules--and make sure >>those rules are clear to WG participants--before we have wasted our time and >>resources developing specifications that half the world (or more) can't >>implement? > > I don't know which of the IETF WGs you have been involved with, but > that hasn't been the case for any of the ones I have dealt with. Could > you give an example of an WG in which this would have been preferable? The DNSEXT WG is a good example where patented technology has been presented and time has been spent on discussing what to do with it. Some time later the working group drafted a requirements document (RFC 4986) which contained the following requirement '5.2. No Known Intellectual Property Encumbrance'. The inclination to standardize only non-patented technology in DNSEXT is fairly strong. If the WG had made the policy explicit early on, the discussions related to the patented ideas could have been more easily dismissed. Time could be spent on more productive work. I think there are other examples, e.g., SRP in SASL WG. >>Has anyone ever suggested that we inhibit "free discussion of initial >>ideas"? Please don't raise silly arguments like that. > > It is not a silly argument. Yes, there are a few engineers in the IETF > who like to play armchair lawyer and would love to spend the initial > time of WG formation pontificating about IPR, but they are in the > small minority. Such a discussion would be of no interest to the folks > who want to do good technical work. In today's world you can't do good technical work on a commercial basis without considering patents. /Simon _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 19 10:51:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iisnk-0003T4-3S; Fri, 19 Oct 2007 10:26:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iisni-0003RU-86 for ietf@ietf.org; Fri, 19 Oct 2007 10:26:10 -0400 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iisnh-0005mP-Qr for ietf@ietf.org; Fri, 19 Oct 2007 10:26:10 -0400 Received: from [192.168.0.2] (adsl-67-127-191-101.dsl.pltn13.pacbell.net [67.127.191.101]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l9JEPcIR023810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 19 Oct 2007 07:25:47 -0700 Message-ID: <4718BE5A.1030103@dcrocker.net> Date: Fri, 19 Oct 2007 07:25:30 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ietf@ietf.org References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> In-Reply-To: <18199.55877.791858.498365@swbmbp.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: Re: A priori IPR choices [Re: Third Last Call: draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Scott Brim wrote: > On 19 Oct 2007 at 10:30 +1300, Brian E Carpenter allegedly wrote: >> On 2007-10-19 05:47, Hallam-Baker, Phillip wrote: >>> What I would suggest is that new working groups be required to >>> specify the governing IPR rules in their charter ... >> Violent disagreement. That would make all kinds of a priori >> processes kick in for employees of patent-conscious companies, ... > > +1 > > Otherwise you get into battles over theory and ideology without any of > the information you need to make a decision. +1 -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 19 10:59:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IitCN-0000im-Uc; Fri, 19 Oct 2007 10:51:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IitCL-0000Zx-B9 for ietf@ietf.org; Fri, 19 Oct 2007 10:51:37 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IitC8-0002Dv-Vh for ietf@ietf.org; Fri, 19 Oct 2007 10:51:31 -0400 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l9JElHqH003200; Fri, 19 Oct 2007 07:47:20 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Oct 2007 07:50:43 -0700 MIME-Version: 1.0 Date: Fri, 19 Oct 2007 07:50:43 -0700 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <2788466ED3E31C418E9ACC5C31661557084EDA@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A priori IPR choices [Re: Third Last Call: draft-housley-tls-authz-extns] Thread-Index: AcgRziymJDX9hEQrRzi3o4VDSaQy6QAj0Oif References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> From: "Hallam-Baker, Phillip" To: "Brian E Carpenter" X-OriginalArrivalTime: 19 Oct 2007 14:50:43.0474 (UTC) FILETIME=[6CB03720:01C8125F] X-Spam-Score: -2.2 (--) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Simon Josefsson , ietf@ietf.org, Tim Polk Subject: RE: A priori IPR choices [Re: Third Last Call: draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1060155006==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============1060155006== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8125F.6C717D83" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C8125F.6C717D83 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The large organizations do not seem to have any problem participating in = OASIS where this is the rule. Admittedly there does seem to be an issue = in W3C with one company but that seems to be due to internal politics. =20 The only obligation that arises out of the OASIS system is that if you = have IPR that you know to cover implementation of a specification you = have to declare it.=20 =20 I know that there are companies with vast stockpiles of IPR that they = think they will be unable to sort through. But as with the pearl in the = junk room: if you don't know you have it you might was well throw it out = anyway. If the lawyers don't know what the IPR portfolio contains and = what it applies then how are you going to make money from it? The days = when people looked at patents to find out if their invention might = infringe and alert the owner are long gone, if the owner can't work out = the applicability then why would anyone else? =20 If folk can't get their act together when a WG starts then why should we = expect them to be able to do so at the end when we are trying to close = the work? ________________________________ From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] Sent: Thu 18/10/2007 5:30 PM To: Hallam-Baker, Phillip Cc: Simon Josefsson; Tim Polk; ietf@ietf.org Subject: A priori IPR choices [Re: Third Last Call: = draft-housley-tls-authz-extns] On 2007-10-19 05:47, Hallam-Baker, Phillip wrote: ... > What I would suggest is that new working groups be required to specify = the governing IPR rules in their charter, these would be either that all = IPR must be offered according to an open grant on W3C terms or that the = working group specifies at the outset that RAND terms are acceptable. Violent disagreement. That would make all kinds of a priori processes kick in for employees of patent-conscious companies, and generally inhibit free discussion of initial ideas. Although it's messier to confront patent issues later in the process, I believe that is much better than constraining participation at the beginning. Brian ------_=_NextPart_001_01C8125F.6C717D83 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A priori IPR choices [Re: Third Last Call: = draft-housley-tls-authz-extns]=0A= =0A= =0A= =0A=
=0A=
The large = organizations do not seem to have any problem participating in OASIS = where this is the rule. Admittedly there does seem to be an issue in W3C = with one company but that seems to be due to internal = politics.
=0A=
 
=0A=
The only obligation that = arises out of the OASIS system is that if you have IPR that you know to = cover implementation of a specification you have to declare it. =
=0A=
 
=0A=
I know that there are = companies with vast stockpiles of IPR that they think they will be = unable to sort through. But as with the pearl in the junk room: if you = don't know you have it you might was well throw it out anyway. If the = lawyers don't know what the IPR portfolio contains and what it applies = then how are you going to make money from it? The days when people = looked at patents to find out if their invention might infringe and = alert the owner are long gone, if the owner can't work out the = applicability then why would anyone else?
=0A=
 
=0A=
If folk can't get their act together when a WG starts = then why should we expect them to be able to do so at the end when we = are trying to close the work?
=0A=

=0A=
=0A= From: Brian E Carpenter = [mailto:brian.e.carpenter@gmail.com]
Sent: Thu 18/10/2007 5:30 = PM
To: Hallam-Baker, Phillip
Cc: Simon Josefsson; = Tim Polk; ietf@ietf.org
Subject: A priori IPR choices [Re: = Third Last Call: draft-housley-tls-authz-extns]

=0A=
=0A=

On 2007-10-19 05:47, Hallam-Baker, Phillip = wrote:
...
> What I would suggest is that new working groups be = required to specify the governing IPR rules in their charter, these = would be either that all IPR must be offered according to an open grant = on W3C terms or that the working group specifies at the outset that RAND = terms are acceptable.

Violent disagreement. That would make all = kinds of a priori processes
kick in for employees of patent-conscious = companies, and generally
inhibit free discussion of initial ideas. = Although it's messier to
confront patent issues later in the process, = I believe that is
much better than constraining participation at the = beginning.

     = Brian

------_=_NextPart_001_01C8125F.6C717D83-- --===============1060155006== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============1060155006==-- From ietf-bounces@ietf.org Fri Oct 19 12:00:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iitzy-0001FL-Ga; Fri, 19 Oct 2007 11:42:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iitzw-0001Dz-1W for ietf@ietf.org; Fri, 19 Oct 2007 11:42:52 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iitzu-0004jn-Mx for ietf@ietf.org; Fri, 19 Oct 2007 11:42:52 -0400 Received: from [10.20.30.150] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9JFgmGr096533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2007 08:42:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <877iljv6ed.fsf@mocca.josefsson.org> References: <2FCE85A0-6C57-4205-B716-1B371FC3987C @nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C316 61557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> Date: Fri, 19 Oct 2007 08:42:39 -0700 To: Simon Josefsson From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 10:46 AM +0200 10/19/07, Simon Josefsson wrote: >Paul Hoffman writes: > >> At 4:10 PM -0700 10/18/07, Lawrence Rosen wrote: >>>Isn't it preferable to get into early battles over IP rules--and make sure >>>those rules are clear to WG participants--before we have wasted our time and >>>resources developing specifications that half the world (or more) can't >>>implement? >> >> I don't know which of the IETF WGs you have been involved with, but >> that hasn't been the case for any of the ones I have dealt with. Could >> you give an example of an WG in which this would have been preferable? > >The DNSEXT WG is a good example where patented technology has been >presented and time has been spent on discussing what to do with it. >Some time later the working group drafted a requirements document (RFC >4986) which contained the following requirement '5.2. No Known >Intellectual Property Encumbrance'. This is a good example of how Lawrence's proposal would not have worked. The technology you are talking about came up years after the WG was formed. >The inclination to standardize only non-patented technology in DNSEXT is >fairly strong. If the WG had made the policy explicit early on, the >discussions related to the patented ideas could have been more easily >dismissed. Time could be spent on more productive work. "Early on" is much different than "when the WG is formed". It is reasonable to talk about IPR desired *on a particular technology* when that technology begins to be discussed in the WG. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 19 13:11:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiv7J-00017x-Pc; Fri, 19 Oct 2007 12:54:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiv7H-000154-2k for ietf@ietf.org; Fri, 19 Oct 2007 12:54:31 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iiv78-0007vS-Rh for ietf@ietf.org; Fri, 19 Oct 2007 12:54:31 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9JGs9Z4030399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 19 Oct 2007 09:54:09 -0700 Received: from [98.207.5.180] (carbuncle.qualcomm.com [129.46.226.27]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9JGs7qu002159; Fri, 19 Oct 2007 09:54:08 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <2FCE85A0-6C57-4205-B716-1B371FC3987C @nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C316 61557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> Date: Fri, 19 Oct 2007 09:54:19 -0700 To: Paul Hoffman , Simon Josefsson From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 8:42 AM -0700 10/19/07, Paul Hoffman wrote: >>The inclination to standardize only non-patented technology in DNSEXT is >>fairly strong. If the WG had made the policy explicit early on, the >>discussions related to the patented ideas could have been more easily >>dismissed. Time could be spent on more productive work. > >"Early on" is much different than "when the WG is formed". It is reasonable to talk about IPR desired *on a particular technology* when that technology begins to be discussed in the WG. I think this is a critical point. The IETF has historically decided whether to deal with licenses when it is faced with a specific technology. That has the real advantage that the contributors can consider the trade-offs (way X is known to be encumbered, with a license required; way Y is not known to be encumbered, but involves new code paths that will likely be slower). For some working groups, we start out with a technology under consideration and "early on in discussion of a technology" and "when the working group starts" may be pretty similar from the point of view of considering that trade-off. For other working groups (DNSEXT is one example, DHC is another), the long-lived nature of their charters and the continual emergence of newly related technologies means that "early on in discussion of a technology" may be years later than "when the working group starts". Speaking personally, I believe the ability to consider that trade-off is a very good thing, and I would hate to lose it. I also think that making that decision in the working group is the best way, despite it being very messy in many cases, because we get the strongest participation from the community of developers and deployers there. regards, Ted _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 19 13:59:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiw3C-00025o-Es; Fri, 19 Oct 2007 13:54:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiw3A-00024f-Gz for ietf@ietf.org; Fri, 19 Oct 2007 13:54:20 -0400 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iiw32-0002Ka-OK for ietf@ietf.org; Fri, 19 Oct 2007 13:54:20 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l9JHrheN026958 for ; Fri, 19 Oct 2007 13:53:43 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9JHrhMH085180 for ; Fri, 19 Oct 2007 13:53:43 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l9JHrg6W023332 for ; Fri, 19 Oct 2007 13:53:42 -0400 Received: from cichlid.raleigh.ibm.com (wecm-9-67-183-176.wecm.ibm.com [9.67.183.176]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l9JHreKe022527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2007 13:53:42 -0400 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.1/8.12.5) with ESMTP id l9JHrOQO032514; Fri, 19 Oct 2007 13:53:24 -0400 Message-Id: <200710191753.l9JHrOQO032514@cichlid.raleigh.ibm.com> To: Simon Josefsson In-reply-to: <877iljv6ed.fsf@mocca.josefsson.org> References: <2FCE85A0-6C57-4205-B716-1B371FC3987C @nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C316 61557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> Comments: In-reply-to Simon Josefsson message dated "Fri, 19 Oct 2007 10:46:18 +0200." Date: Fri, 19 Oct 2007 13:53:24 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Paul Hoffman , ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > The DNSEXT WG is a good example where patented technology has been > presented and time has been spent on discussing what to do with it. > Some time later the working group drafted a requirements document (RFC > 4986) which contained the following requirement '5.2. No Known > Intellectual Property Encumbrance'. And is the text you quote specific to all DNS technology? Or just that one that is the subject of the document you cite? (To be clear, it is the latter.) > The inclination to standardize only non-patented technology in DNSEXT is > fairly strong. Yes, but the discussion still works best on a technology-by-technology basis, not on the broad "all DNS technology" swath that would be implied if the decision had to be made at WG formation time. Thomas _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 19 13:59:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iivz4-00073A-LJ; Fri, 19 Oct 2007 13:50:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iivz2-0006s1-7o for ietf@ietf.org; Fri, 19 Oct 2007 13:50:04 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iivyt-0005tE-Ta for ietf@ietf.org; Fri, 19 Oct 2007 13:49:57 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l9JHkD7D009860; Fri, 19 Oct 2007 10:46:13 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Oct 2007 10:49:39 -0700 MIME-Version: 1.0 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 19 Oct 2007 10:49:39 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557084EDB@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] Thread-Index: AcgR0/JJn4I7o2HUTuuIYKZaP2JJSAAi5CqX References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov><87y7e08phu.fsf@mocca.josefsson.org><2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com><4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> From: "Hallam-Baker, Phillip" To: "Scott Brim" , "Brian E Carpenter" X-OriginalArrivalTime: 19 Oct 2007 17:49:39.0443 (UTC) FILETIME=[6BD31430:01C81278] X-Spam-Score: 1.8 (+) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: Simon Josefsson , ietf@ietf.org, Tim Polk Subject: RE: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2054717476==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============2054717476== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81278.6B970933" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C81278.6B970933 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would expect RAND charters to be issued rarely if at all. I would only = expect a RAND charter to issue if there was some overwhelmingly = compelling IPR that everyone agreed is simply indispensible. =20 The only case I can remember where this was the case in the past was = public key cryptography. The only current area of networking where I see = a compelling set of IPR is in the content rights management space, and I = don't think the patent issues would be the only barrier to working on = that problem in the IETF. =20 We already have a notice requirement. I would certainly like to see Note = Well being made much more prominent, in particular I think that there = should be mandatory Note Well notices presented in the registration = process for every IETF WG mailing list. I would also like to see all = lists managed by the IETF directly and a comprehensive archive kept with = digitally notorized records of all subscriptions, posts, = unsubscriptions, drafts, etc. =20 The only thing that would change here is that when a company does = declare IPR it knows that there are only three possible outcomes: =20 1) The WG works around the IPR claim, either changing the specification = to avoid the claim or if the claim is obviouly spurious rejecting it = (i.e. if someone claims that their patent on a new method of swinging = covers HTTP it can probably be simply noted). =20 2) The IPR holder makes an irrevocable pledge to grant a RANDZ license = to any party implementing the specification that agrees not to enforce = its own IPR claims with respect to the specification on the IPR holder. =20 3) The WG droes not proceed with the work item in question. The only way = to proceed at this point is to either charter a new WG under RAND terms, = to submit the work as a personal submission on RAND terms, to proceed in = another venue with different IPR terms or to not proceed at all. =20 There is absolutely no change in the preconditions. Note Well applies = today and will under the new rules. The only difference is that we have = eliminated a fourth option that exists today: =20 4) Argue for the work continuing in the WG on terms that are not RANDZ, = are not compatible with open source licensing, commercial use, contain = viral poison pills, or otherwise objectionable. =20 The decision of which of the three outcomes to choose cannot be made = till the end of the process for the simple reason that we don't know = what the spec will be like until then. A concern of mine is always the = last minute change that pushes a spec into IPR hell. =20 =20 I have very rarely seen IPR issues with the core of a standards based = protocol. If you have a strong hold on the IPR then the topic has to be = pretty huge to make the overhead of standards work worthwhile. If you = have cast iron IPR and a compelling value proposition you can set the = standards yourself unilaterally. And why should the rest of the = community give their time to create the technology if thewy are going to = pass through your toll booth? =20 What is much more common is the optional extension that is patent = encumbered. I have a few patent applications of that type. But I don't = go smurfing them here or anywhere else. ________________________________ From: Scott Brim [mailto:swb@employees.org] Sent: Thu 18/10/2007 6:12 PM To: Brian E Carpenter Cc: Hallam-Baker, Phillip; Simon Josefsson; ietf@ietf.org; Tim Polk Subject: A priori IPR choices [Re: Third Last = Call:draft-housley-tls-authz-extns] On 19 Oct 2007 at 10:30 +1300, Brian E Carpenter allegedly wrote: > On 2007-10-19 05:47, Hallam-Baker, Phillip wrote: > > What I would suggest is that new working groups be required to > > specify the governing IPR rules in their charter, these would be > > either that all IPR must be offered according to an open grant on > > W3C terms or that the working group specifies at the outset that > > RAND terms are acceptable. > > Violent disagreement. That would make all kinds of a priori > processes kick in for employees of patent-conscious companies, and > generally inhibit free discussion of initial ideas. Although it's > messier to confront patent issues later in the process, I believe > that is much better than constraining participation at the > beginning. +1 Otherwise you get into battles over theory and ideology without any of the information you need to make a decision. You will still be able to take your stance once the technical tradeoffs are worked out. ------_=_NextPart_001_01C81278.6B970933 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A priori IPR choices [Re: Third Last = Call:draft-housley-tls-authz-extns]=0A= =0A= =0A= =0A=
=0A=
I would = expect RAND charters to be issued rarely if at all. I would only expect = a RAND charter to issue if there was some overwhelmingly compelling IPR = that everyone agreed is simply indispensible.
=0A=
 
=0A=
The only case I can remember = where this was the case in the past was public key cryptography. The = only current area of networking where I see a compelling set of IPR is = in the content rights management space, and I don't think the patent = issues would be the only barrier to working on that problem in the = IETF.
=0A=
 
=0A=
We already have a notice = requirement. I would certainly like to see Note Well being made much = more prominent, in particular I think that there should be mandatory = Note Well notices presented in the registration process for every IETF = WG mailing list. I would also like to see all lists managed by the IETF = directly and a comprehensive archive kept with digitally notorized = records of all subscriptions, posts, unsubscriptions, drafts, = etc.
=0A=
 
=0A=
The only thing that would = change here is that when a company does declare IPR it knows that there = are only three possible outcomes:
=0A=
 
=0A=
1) The WG works around the = IPR claim, either changing the specification to avoid the claim or if = the claim is obviouly spurious rejecting it (i.e. if someone claims that = their patent on a new method of swinging covers HTTP it can probably be = simply noted).
=0A=
 
=0A=
2) The IPR holder makes an = irrevocable pledge to grant a RANDZ license to any party implementing = the specification that agrees not to enforce its own IPR claims with = respect to the specification on the IPR holder.
=0A=
 
=0A=
3) The WG droes not proceed = with the work item in question. The only way to proceed at this point is = to either charter a new WG under RAND terms, to submit the work as a = personal submission on RAND terms, to proceed in another venue with = different IPR terms or to not proceed at all.
=0A=
 
=0A=
There is absolutely no change = in the preconditions. Note Well applies today and will under the new = rules. The only difference is that we have eliminated a fourth option = that exists today:
=0A=
 
=0A=
4) Argue for the work = continuing in the WG on terms that are not RANDZ, are not compatible = with open source licensing, commercial use, contain viral poison pills, = or otherwise objectionable.
=0A=
 
=0A=
The decision of which of the = three outcomes to choose cannot be made till the end of the process for = the simple reason that we don't know what the spec will be like until = then. A concern of mine is always the last minute change that pushes a = spec into IPR hell.
=0A=
 
=0A=
 
=0A=
I have very rarely seen = IPR issues with the core of a standards based protocol. If you have = a strong hold on the IPR then the topic has to be pretty huge to make = the overhead of standards work worthwhile. If you have cast iron IPR and = a compelling value proposition you can set the standards yourself = unilaterally. And why should the rest of the community give their time = to create the technology if thewy are going to pass through your toll = booth?
=0A=
 
=0A=
What is much more common is = the optional extension that is patent encumbered. I have a few patent = applications of that type. But I don't go smurfing them here or anywhere = else.
=0A=

=0A=
=0A= From: Scott Brim = [mailto:swb@employees.org]
Sent: Thu 18/10/2007 6:12 = PM
To: Brian E Carpenter
Cc: Hallam-Baker, Phillip; = Simon Josefsson; ietf@ietf.org; Tim Polk
Subject: A priori IPR = choices [Re: Third Last = Call:draft-housley-tls-authz-extns]

=0A=
=0A=

On 19 Oct 2007 at 10:30 +1300, Brian E Carpenter = allegedly wrote:
> On 2007-10-19 05:47, Hallam-Baker, Phillip = wrote:
> > What I would suggest is that new working groups be = required to
> > specify the governing IPR rules in their = charter, these would be
> > either that all IPR must be offered = according to an open grant on
> > W3C terms or that the working = group specifies at the outset that
> > RAND terms are = acceptable.
>
> Violent disagreement. That would make all = kinds of a priori
> processes kick in for employees of = patent-conscious companies, and
> generally inhibit free = discussion of initial ideas. Although it's
> messier to confront = patent issues later in the process, I believe
> that is much = better than constraining participation at the
> = beginning.

+1

Otherwise you get into battles over theory = and ideology without any of
the information you need to make a = decision.  You will still be able
to take your stance once the = technical tradeoffs are worked out.

------_=_NextPart_001_01C81278.6B970933-- --===============2054717476== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============2054717476==-- From ietf-bounces@ietf.org Fri Oct 19 15:58:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iixf5-0007cx-2i; Fri, 19 Oct 2007 15:37:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iixf3-0007YB-GX for ietf@ietf.org; Fri, 19 Oct 2007 15:37:33 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iixf3-0001yM-6Q for ietf@ietf.org; Fri, 19 Oct 2007 15:37:33 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 70C22240824; Fri, 19 Oct 2007 20:37:19 +0200 (CEST) Received: by horcrux (Postfix, from userid 1000) id 39F521579EF; Fri, 19 Oct 2007 19:19:49 +0200 (CEST) Date: Fri, 19 Oct 2007 17:19:49 +0000 From: Stephane Bortzmeyer To: Paul Hoffman Message-ID: <20071019171949.GA2419@laperouse.bortzmeyer.org> References: <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 7.04 (feisty) User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Thu, Oct 18, 2007 at 07:21:55PM -0700, Paul Hoffman wrote a message of 35 lines which said: > Could you give an example of an WG in which this would have been > preferable? MARID, certainly. > Yes, there are a few engineers in the IETF who like to play armchair > lawyer and would love to spend the initial time of WG formation > pontificating about IPR, but they are in the small minority. Such a > discussion would be of no interest to the folks who want to do good > technical work. You mean that everyone who disagrees with the current IPR policy of IETF is not wanting to do good technical work? And that people genuinely interested in a better IPR policy are just "armchair lawyers"? Seems quite despising. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 19 16:07:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiy0y-0006Q5-Bk; Fri, 19 Oct 2007 16:00:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiy0v-00062v-Qy for ietf@ietf.org; Fri, 19 Oct 2007 16:00:09 -0400 Received: from mail26i.sbc-webhosting.com ([216.173.236.230]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iiy0q-0003VI-4d for ietf@ietf.org; Fri, 19 Oct 2007 16:00:04 -0400 Received: from mx16.stngva01.us.mxservers.net (204.202.242.6) by mail26i.sbc-webhosting.com (RS ver 1.0.95vs) with SMTP id 2-0193384002 for ; Fri, 19 Oct 2007 16:00:03 -0400 (EDT) Received: from mmm2630.sbc-webhosting.com [216.173.237.89] (EHLO mmm2630.sbc-webhosting.com) by mx16.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id 2cc09174.29079.098.mx16.stngva01.us.mxservers.net; Fri, 19 Oct 2007 16:00:02 -0400 (EDT) Received: (qmail 35245 invoked from network); 19 Oct 2007 20:00:01 -0000 Received: from unknown (HELO LROSENTOSHIBA) (lrosen@208.106.45.202) by with ESMTPA; 19 Oct 2007 20:00:01 -0000 From: "Lawrence Rosen" To: References: <2FCE85A0-6C57-4205-B716-1B371FC3987C @nist.gov><87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com><18199.55877.791858.498365@swbmbp.local><03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA><877iljv6ed.fsf@mocca.josefsson.org> Date: Fri, 19 Oct 2007 12:58:15 -0700 Organization: Rosenlaw & Einschlag Message-ID: <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgSaTf5tJ94Y0kRRGqCtikUVNbMZQAAFy9A X-Spam: [F=0.0043103448; heur=0.500(-19500); stat=0.010; spamtraq-heur=0.300(2007101727)] X-MAIL-FROM: X-SOURCE-IP: [216.173.237.89] X-SF-Loop: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: "'Contreras, Jorge'" Subject: RE: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lrosen@rosenlaw.com List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Paul Hoffman wrote: > "Early on" is much different than "when the WG is formed". It is > reasonable to talk about IPR desired *on a particular technology* > when that technology begins to be discussed in the WG. And so, if our reasonable policy is that the "IPR desired" on IETF's standardized Internet technologies shall ab initio be free (in several senses of the word "free" to be defined later), then we must deal with patents "early on." Like now.... You probably mean a narrower definition of "technology" than I intend, which includes *all* of IETF's Internet specifications. I'm after a resolution of IETF policy regarding patent-encumbered IETF specifications wherever they appear, not some rule that requires each WG to look for and compare patents to technology. I never suggested that each WG start or end its standardization process by looking for patents. What a waste that would be! Even the companies that own those patents refuse to take the time to do that before their employees join a WG. I agree with you that IETF should only address specific patents in the context of a specific technology (or set of technologies) when the patent landscape becomes clearer during WG activities. That may happen early on or later, as ideas ferment and as patents become known. Several of you are twisting my recommendations about policy into a threat to the independent creativity of each WG. I DON'T want each WG to worry about patents unless non-free patents actually are discovered. I DO want IETF to adopt policies concerning the disclosure of patents when known by WG participants, and the mandatory licensing of those patents for free by those patent owners who actually participate in and contribute to a specification, or alternatively the withdrawal of that specification as an IETF standard. Otherwise, to speak freely here, patent-encumbered specifications that we waste our time creating are useless for open source and many proprietary implementations. But I go beyond where we are already. The policy we need should not be debated here yet. This is too big a list for that discussion. What I request is that we charter the IETF IPR-WG to propose policies and procedures, consistent with the worldwide mission of IETF, which will result in IETF specifications unencumbered by restrictive, non-free patents. That's a simple charter for the IPR-WG. Not so simple perhaps to guarantee consensus even on definitions, and perhaps it won't result in a single formal proposal, but it needs to be addressed. The IPR-WG is an appropriate place for that activity. /Larry Rosen > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Friday, October 19, 2007 8:43 AM > To: Simon Josefsson > Cc: ietf@ietf.org > Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls- > authz-extns] > > At 10:46 AM +0200 10/19/07, Simon Josefsson wrote: > >Paul Hoffman writes: > > > >> At 4:10 PM -0700 10/18/07, Lawrence Rosen wrote: > >>>Isn't it preferable to get into early battles over IP rules--and make > sure > >>>those rules are clear to WG participants--before we have wasted our > time and > >>>resources developing specifications that half the world (or more) can't > >>>implement? > >> > >> I don't know which of the IETF WGs you have been involved with, but > >> that hasn't been the case for any of the ones I have dealt with. Could > >> you give an example of an WG in which this would have been preferable? > > > >The DNSEXT WG is a good example where patented technology has been > >presented and time has been spent on discussing what to do with it. > >Some time later the working group drafted a requirements document (RFC > >4986) which contained the following requirement '5.2. No Known > >Intellectual Property Encumbrance'. > > This is a good example of how Lawrence's proposal would not have > worked. The technology you are talking about came up years after the > WG was formed. > > >The inclination to standardize only non-patented technology in DNSEXT is > >fairly strong. If the WG had made the policy explicit early on, the > >discussions related to the patented ideas could have been more easily > >dismissed. Time could be spent on more productive work. > > "Early on" is much different than "when the WG is formed". It is > reasonable to talk about IPR desired *on a particular technology* > when that technology begins to be discussed in the WG. > > --Paul Hoffman, Director > --VPN Consortium > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 19 16:44:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiyYu-0005LJ-D5; Fri, 19 Oct 2007 16:35:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiyYt-0005KF-0x for ietf@ietf.org; Fri, 19 Oct 2007 16:35:15 -0400 Received: from rv-out-0910.google.com ([209.85.198.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiyYn-0001NP-Pi for ietf@ietf.org; Fri, 19 Oct 2007 16:35:15 -0400 Received: by rv-out-0910.google.com with SMTP id l15so485166rvb for ; Fri, 19 Oct 2007 13:34:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=iL6GfgIhL9ajaHo6gBMgz2x0kpfy27dfhOyitk37H3U=; b=Uxbcpqzrxu4lf3BP6i5LrpMYGkP+KB5Mc4QehCKbBNnPlfFurTkkPq9eUioAT6pVj2lhLs0qZuUq+q2WOzYoE3Hfw6btZ9sZC+dKTgZOmJ2HJosyCNSCOxiORCwo9GAy2PqsxyiK/svnXJ1GXrhRLQF+x0NqD6idLlmcyDFPdXE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=cAtHbSbXOv92dE4LIong0+RzhJvm4i3QDHFGOw3KlJB0owLSq9+8AVnUIp7crwgXfYhagDffVFbO25ztltzMpHu9uGBvCQOKhzVsfFmbcCL+ItGk0RCVYIJkJKvfoEd7kSeYqYkMDRo+POesAXSmDaxNWb9BYo6DqdW5Osqnu3Y= Received: by 10.140.147.5 with SMTP id u5mr1224526rvd.1192826097836; Fri, 19 Oct 2007 13:34:57 -0700 (PDT) Received: from ?10.1.1.7? ( [222.153.14.113]) by mx.google.com with ESMTPS id g22sm4265210rvb.2007.10.19.13.34.54 (version=SSLv3 cipher=RC4-MD5); Fri, 19 Oct 2007 13:34:56 -0700 (PDT) Message-ID: <471914E9.8030303@gmail.com> Date: Sat, 20 Oct 2007 09:34:49 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <2788466ED3E31C418E9ACC5C31661557084EDA@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <2788466ED3E31C418E9ACC5C31661557084EDA@mou1wnexmb09.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Simon Josefsson , ietf@ietf.org, Tim Polk Subject: Re: A priori IPR choices [Re: Third Last Call: draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Phill, > If folk can't get their act together when a WG starts then why should we expect them to be able to do so at the end when we are trying to close the work? Because of the difference between known unknowns and unknown unknowns. At the beginning, you're asking an entirely hypothetical question about potential patents on undesigned technology. At the end, you're asking a precise question about applied-for or granted patents on specific technology. There's a world of difference, especially since the IETF only requires disclosure of patents reasonably and personally known to the individual contributor. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 19 17:10:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiyvT-00059j-3L; Fri, 19 Oct 2007 16:58:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiyvR-00056J-69 for ietf@ietf.org; Fri, 19 Oct 2007 16:58:33 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiyvK-0002JH-UE for ietf@ietf.org; Fri, 19 Oct 2007 16:58:33 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9JKwDwg019397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 19 Oct 2007 13:58:13 -0700 Received: from [98.207.5.180] (carbuncle.qualcomm.com [129.46.226.27]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9JKwBsR000706; Fri, 19 Oct 2007 13:58:12 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> References: <2FCE85A0-6C57-4205-B716-1B371FC3987C @nist.gov><87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com><18199.55877.791858.498365@swbmbp.local><03d50 1c811dc$031404a0$6401a8c0@LROSENTOSHIBA><877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> Date: Fri, 19 Oct 2007 13:58:23 -0700 To: lrosen@rosenlaw.com, From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -4.0 (----) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: "'Contreras, Jorge'" Subject: RE: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > I DO want IETF to >adopt policies concerning the disclosure of patents when known by WG >participants, and the mandatory licensing of those patents for free by those >patent owners who actually participate in and contribute to a specification, >or alternatively the withdrawal of that specification as an IETF standard. The IETF already has policies about disclosures of patents when known by working group participants, as you well know. This sounds like you want the IETF as whole to make this decision prior to any work of a working group, and without any working group consideration of whether the benefits of a licensed technology support its selection for a particular context. >Otherwise, to speak freely here, patent-encumbered specifications that we >waste our time creating are useless for open source and many proprietary >implementations. "waste our time" is a pretty loaded phrase. "open source" also covers a wide variety of licenses, and it's only when the open source developer actually sees the patent and the offered license that this determination can be made. Cisco has probably disclosed the most patents in an IETF context (163 disclosures in any case; I'm having trouble getting the tool to give me comparisons), but its licenses don't seem to have allowed both open source and proprietary implementations. Yet they clearly are encumbered. Patent-encumbered specification that *we choose to develop with the knowledge of those patents* may be in the best interests of the Internet, at least as well as an open process can determine. We'll never have perfect knowledge, obviously, as someone not participating may end up claiming patent coverage. But ruling it out without letting a working group balance technology and license is worse than where we are now, at least in my view. >But I go beyond where we are already. The policy we need should not be >debated here yet. This is too big a list for that discussion. Funny, you objected that it should be here the last time I suggested that the IPR working group list was the best place for this discussion. You said it was strangled in committee the last time the community debated it there. >What I request is that we charter the IETF IPR-WG to propose policies and >procedures, consistent with the worldwide mission of IETF, which will result >in IETF specifications unencumbered by restrictive, non-free patents. Ah, I see why you appear to have changed your position. You actually want the result you're arguing for built into the charter of the IPR working group, beforehand without letting the community actually discuss it. Thanks for re-affirming my faith in your consistency. >That's a simple charter for the IPR-WG. Not so simple perhaps to guarantee >consensus even on definitions, and perhaps it won't result in a single >formal proposal, but it needs to be addressed. The IPR-WG is an appropriate >place for that activity. > If you want to argue for a change in the charter of the IPR working group, you can certainly do it on that list. But, please, do realize you have to get the community to agree on the charter goals first. No one in the IETF, including the IESG, has the right to change the goals of a working group without community input and agreement. The ability to review and comment on that kind of thing is something a lot of people value around here. Speaking only for myself, Ted Hardie _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 19 17:42:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IizSn-0003Xg-O9; Fri, 19 Oct 2007 17:33:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IizSl-0003Wc-1s for ietf@ietf.org; Fri, 19 Oct 2007 17:32:59 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IizSe-0004CM-QJ for ietf@ietf.org; Fri, 19 Oct 2007 17:32:59 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9JLWf4p030953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 19 Oct 2007 14:32:41 -0700 Received: from [98.207.5.180] (carbuncle.qualcomm.com [129.46.226.27]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9JLWdPM016975; Fri, 19 Oct 2007 14:32:40 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <2FCE85A0-6C57-4205-B716-1B371FC3987C @nist.gov><87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com><18199.55877.791858.498365@swbmbp.local><03d50 1c811dc$031404a0$6401a8c0@LROSENTOSHIBA><877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> Date: Fri, 19 Oct 2007 14:32:50 -0700 To: lrosen@rosenlaw.com, From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -4.0 (----) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: "'Contreras, Jorge'" Subject: RE: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 1:58 PM -0700 10/19/07, Ted Hardie wrote: >Cisco has probably disclosed the most patents in an >IETF context (163 disclosures in any case; I'm having trouble getting the >tool to give me comparisons), but its licenses don't seem to have allowed >both open source and proprietary implementations. My apologies for the major typo. I meant "don't seem to have prevented". Sorry for the goof, Ted _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 19 19:06:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij0di-0005Kh-AW; Fri, 19 Oct 2007 18:48:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij0df-0005CR-2k for ietf@ietf.org; Fri, 19 Oct 2007 18:48:19 -0400 Received: from mail26i.sbc-webhosting.com ([216.173.236.230]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ij0dU-0006TA-Sv for ietf@ietf.org; Fri, 19 Oct 2007 18:48:15 -0400 Received: from mx86.stngva01.us.mxservers.net (198.173.112.3) by mail26i.sbc-webhosting.com (RS ver 1.0.95vs) with SMTP id 2-0816774077 for ; Fri, 19 Oct 2007 18:47:58 -0400 (EDT) Received: from mmm2630.sbc-webhosting.com [216.173.237.89] (EHLO mmm2630.sbc-webhosting.com) by mx86.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id 9f239174.2435.157.mx86.stngva01.us.mxservers.net; Fri, 19 Oct 2007 18:43:05 -0400 (EDT) Received: (qmail 77174 invoked from network); 19 Oct 2007 22:47:52 -0000 Received: from unknown (HELO LROSENTOSHIBA) (lrosen@208.106.45.202) by with ESMTPA; 19 Oct 2007 22:47:52 -0000 From: "Lawrence Rosen" To: References: <2FCE85A0-6C57-4205-B716-1B371FC3987C @nist.gov><87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com><18199.55877.791858.498365@swbmbp.local><03d50 1c811dc$031404a0$6401a8c0@LROSENTOSHIBA><877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> Date: Fri, 19 Oct 2007 15:45:53 -0700 Organization: Rosenlaw & Einschlag Message-ID: <043201c812a1$cef4e650$6401a8c0@LROSENTOSHIBA> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgSk4m2kf7L2dkLTNa+/xalGbNf8wADDOew X-Spam: [F=0.0127147600; heur=0.500(-19500); stat=0.012; spamtraq-heur=0.500(2007101727)] X-MAIL-FROM: X-SOURCE-IP: [216.173.237.89] X-SF-Loop: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: RE: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lrosen@rosenlaw.com List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Ted Hardie wrote: > Ah, I see why you appear to have changed your position. You actually > want the result you're arguing for built into the charter of > the IPR working group, beforehand without letting the community actually > discuss it. Thanks for re-affirming my faith in your consistency. You're welcome. To state it more fairly, I want the result I'm arguing for to be built into the charter so that the WG can examine fairly what it will take to reach that goal. The WG cannot adopt a policy for IETF, only propose one. But the WG's work should be goal-directed. By the way, that's not such a change of tactic for that particular IPR-WG. You previously argued in committee that the current IETF patent policy is NOT a problem, and in that spirit the IPR-WG previously buried every counter-proposal we made as "off-charter"! So let's play the charter game fairly, please, by the same rules you played them. Let's charter the IPR-WG to develop a proposal that achieves a specific goal to fix a perceived patent problem. You can always argue against it in committee or vote against it if a serious proposal toward that goal gets before the IETF as a whole. /Larry Rosen _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 19 19:55:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij1Wc-0007L1-1B; Fri, 19 Oct 2007 19:45:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij1Wa-0007KQ-6l for ietf@ietf.org; Fri, 19 Oct 2007 19:45:04 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ij1WP-0007qa-G8 for ietf@ietf.org; Fri, 19 Oct 2007 19:45:02 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9JNicFl009110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 19 Oct 2007 16:44:39 -0700 Received: from [98.207.5.180] (carbuncle.qualcomm.com [129.46.226.27]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9JNib7a022480; Fri, 19 Oct 2007 16:44:38 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <043201c812a1$cef4e650$6401a8c0@LROSENTOSHIBA> References: <2FCE85A0-6C57-4205-B716-1B371FC3987C @nist.gov><87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com><18199.55877.791858.498365@swbmbp.local><03d50 1c811dc$031404a0$6401a8c0@LROSENTOSHIBA><877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <043201c812a1$cef4e650$6401a8c0@LROSENTOSHIBA> Date: Fri, 19 Oct 2007 16:44:49 -0700 To: lrosen@rosenlaw.com, From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -4.0 (----) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Subject: RE: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 3:45 PM -0700 10/19/07, Lawrence Rosen wrote: >Ted Hardie wrote: >> Ah, I see why you appear to have changed your position. You actually >> want the result you're arguing for built into the charter of >> the IPR working group, beforehand without letting the community actually >> discuss it. Thanks for re-affirming my faith in your consistency. > >You're welcome. To state it more fairly, I want the result I'm arguing for >to be built into the charter so that the WG can examine fairly what it will >take to reach that goal. The WG cannot adopt a policy for IETF, only propose >one. But the WG's work should be goal-directed. What you seem to be missing is a step where the WG agrees that this is the goal. The steps we've taken in the past are: Check to see if we have agreement to open the current policies for change. If we have that agreement, develop proposals for what that change would be. Agree on the set of changes in broad scope. Write documents that set out the new policies. Get community consensus on the documents which lay out the changes and the resulting policies. You don't have step one done yet, and you are jumping to the end of 3, where you are pre-supposing what the result of the agreed set of changes would be. > >By the way, that's not such a change of tactic for that particular IPR-WG. >You previously argued in committee that the current IETF patent policy is >NOT a problem, and in that spirit the IPR-WG previously buried every >counter-proposal we made as "off-charter"! I'm not sure what you mean by "in committee" above. I have certainly made comments on the IPR working group mailing list. It has open archives, and I encourage folks who are considering opening up the charter to consider changes to it actually read them, along with the documents it has produced. I also note above the nice shift in subject, from "you previously argued" to "in that spirit the IPR-WG previously buried". Let me rephrase this: "After discussion that included comments by you (Ted Hardie), the IPR working group came to consensus not to reconsider the patent policy. After that decision, proposals to change it were ruled off charter." I had a heck of lot less to do with it than that makes it appear since I have never chaired the group, written any of its documents, or been its AD; I have my opinions, but I never buried anything. >So let's play the charter game >fairly, please, by the same rules you played them. Let's run the charter process fairly indeed. We can start by not pretending it's a win/loss game, and agree that it is a process of getting the community to agree on what work it is willing to take on, without artificially starting with a "specific goal" that presupposes an agreement that has not been demonstrated. Have a lovely weekend Larry, Ted >/Larry Rosen > > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 19 20:49:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij2JT-0005Y0-44; Fri, 19 Oct 2007 20:35:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij2JQ-0005Jk-P1 for ietf@ietf.org; Fri, 19 Oct 2007 20:35:32 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ij2JL-0003Yn-7H for ietf@ietf.org; Fri, 19 Oct 2007 20:35:27 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l9K0VijQ023202; Fri, 19 Oct 2007 17:31:46 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Oct 2007 17:35:10 -0700 MIME-Version: 1.0 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 19 Oct 2007 17:33:04 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557084EE7@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A priori IPR choices [Re: Third Last Call: draft-housley-tls-authz-extns] Thread-Index: AcgSj4EIgOmDYbOyRPabGX7LgSywOQAIUXoG References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <2788466ED3E31C418E9ACC5C31661557084EDA@mou1wnexmb09.vcorp.ad.vrsn.com> <471914E9.8030303@gmail.com> From: "Hallam-Baker, Phillip" To: "Brian E Carpenter" X-OriginalArrivalTime: 20 Oct 2007 00:35:10.0363 (UTC) FILETIME=[122ED6B0:01C812B1] X-Spam-Score: 1.8 (+) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Simon Josefsson , ietf@ietf.org, Tim Polk Subject: RE: A priori IPR choices [Re: Third Last Call: draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0013496228==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============0013496228== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C812B1.11E808FF" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C812B1.11E808FF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, =20 I agree that nobody can know in advance if they will have IPR issues at = the end. What I am arguing for is that the set of possible end points is = known in advance.=20 ________________________________ From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] Sent: Fri 19/10/2007 4:34 PM To: Hallam-Baker, Phillip Cc: Simon Josefsson; Tim Polk; ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third Last Call: = draft-housley-tls-authz-extns] Phill, > If folk can't get their act together when a WG starts then why should = we expect them to be able to do so at the end when we are trying to = close the work? Because of the difference between known unknowns and unknown unknowns. At the beginning, you're asking an entirely hypothetical question about = potential patents on undesigned technology. At the end, you're asking a precise question about applied-for or = granted patents on specific technology. There's a world of difference, especially since the IETF only requires = disclosure of patents reasonably and personally known to the individual contributor. Brian ------_=_NextPart_001_01C812B1.11E808FF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: A priori IPR choices [Re: Third Last = Call: draft-housley-tls-authz-extns]=0A= =0A= =0A= =0A=
=0A=
Brian,
=0A=
 
=0A=
I agree that nobody can know = in advance if they will have IPR issues at the end. What I am arguing = for is that the set of possible end points is known in advance. =
=0A=

=0A=
=0A= From: Brian E Carpenter = [mailto:brian.e.carpenter@gmail.com]
Sent: Fri 19/10/2007 4:34 = PM
To: Hallam-Baker, Phillip
Cc: Simon Josefsson; = Tim Polk; ietf@ietf.org
Subject: Re: A priori IPR choices [Re: = Third Last Call: draft-housley-tls-authz-extns]

=0A=
=0A=

Phill,

> If folk can't get their act = together when a WG starts then why should we expect them to be able to = do so at the end when we are trying to close the work?

Because of = the difference between known unknowns and unknown unknowns.

At = the beginning, you're asking an entirely hypothetical question about = potential patents on undesigned technology.

At the end, you're = asking a precise question about applied-for or granted patents on = specific technology.

There's a world of difference, especially = since the IETF only requires disclosure of patents reasonably and = personally known to
the individual = contributor.

    = Brian

------_=_NextPart_001_01C812B1.11E808FF-- --===============0013496228== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0013496228==-- From ietf-bounces@ietf.org Fri Oct 19 20:49:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij2DW-0004TM-Lc; Fri, 19 Oct 2007 20:29:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij2DU-0004Pp-4m for ietf@ietf.org; Fri, 19 Oct 2007 20:29:24 -0400 Received: from bender-mail.tigertech.net ([64.62.209.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ij2DN-0000WS-SR for ietf@ietf.org; Fri, 19 Oct 2007 20:29:24 -0400 Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id 228247E15 for ; Fri, 19 Oct 2007 17:28:55 -0700 (PDT) Received: from JMHLap3.joelhalpern.com (pool-162-84-109-161.culp.east.verizon.net [162.84.109.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id D0B977DB5 for ; Fri, 19 Oct 2007 17:28:53 -0700 (PDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 19 Oct 2007 20:28:50 -0400 To: From: "Joel M. Halpern" In-Reply-To: <043201c812a1$cef4e650$6401a8c0@LROSENTOSHIBA> References: <2FCE85A0-6C57-4205-B716-1B371FC3987C @nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d50 1c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <043201c812a1$cef4e650$6401a8c0@LROSENTOSHIBA> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20071020002853.D0B977DB5@bender.tigertech.net> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on bender.tigertech.net X-Spam-Status: No, hits=2.3 tagged_above=-999.0 required=7.0 tests=MSGID_FROM_MTA_ID, SPF_NEUTRAL X-Spam-Level: ** X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: RE: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Actually, I saw the quesiton of whether the charter should be extended into re-visiting the patent rules fairly discussed in the working group. (Which is the usual place to decide if we even want to do the work.) You were aware of and involved in the discussion. The rough consensus of the working group was that there was not a need to revisit the existing IETF patent policy. So the chairs did not ask the IESG to consider making such a change. Yours, Joel M. Halpern At 06:45 PM 10/19/2007, Lawrence Rosen wrote: >Ted Hardie wrote: > > Ah, I see why you appear to have changed your position. You actually > > want the result you're arguing for built into the charter of > > the IPR working group, beforehand without letting the community actually > > discuss it. Thanks for re-affirming my faith in your consistency. > >You're welcome. To state it more fairly, I want the result I'm arguing for >to be built into the charter so that the WG can examine fairly what it will >take to reach that goal. The WG cannot adopt a policy for IETF, only propose >one. But the WG's work should be goal-directed. > >By the way, that's not such a change of tactic for that particular IPR-WG. >You previously argued in committee that the current IETF patent policy is >NOT a problem, and in that spirit the IPR-WG previously buried every >counter-proposal we made as "off-charter"! So let's play the charter game >fairly, please, by the same rules you played them. Let's charter the IPR-WG >to develop a proposal that achieves a specific goal to fix a perceived >patent problem. You can always argue against it in committee or vote against >it if a serious proposal toward that goal gets before the IETF as a whole. > >/Larry Rosen > > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 19 20:55:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij2VK-0003rE-6G; Fri, 19 Oct 2007 20:47:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij2VI-0003d1-3D for ietf@ietf.org; Fri, 19 Oct 2007 20:47:48 -0400 Received: from robin.verisign.com ([65.205.251.75]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ij2V7-0003n1-As for ietf@ietf.org; Fri, 19 Oct 2007 20:47:38 -0400 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l9K0iQvs029292; Fri, 19 Oct 2007 17:44:26 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 20 Oct 2007 01:47:23 +0100 MIME-Version: 1.0 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 19 Oct 2007 17:47:17 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] Thread-Index: AcgSmTU/Vh/jPjRKQ5i7b0w6SI3kegAGDhYw References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov><87y7e08phu.fsf@mocca.josefsson.org><2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com><4717D090.1000908@gmail.com><18199.55877.791858.498365@swbmbp.local><03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA><877iljv6ed.fsf@mocca.josefsson.org><042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> From: "Hallam-Baker, Phillip" To: "Ted Hardie" , , X-OriginalArrivalTime: 20 Oct 2007 00:47:23.0359 (UTC) FILETIME=[C71526F0:01C812B2] X-Spam-Score: 1.8 (+) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: "Contreras, Jorge" Subject: RE: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1293898566==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============1293898566== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C812B2.C3A5CD8D" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C812B2.C3A5CD8D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The question is whether in the light of the SCO vs IBM case the = reciprocity clauses actually have the intended effect. =20 Having been involved in the license issues surrounding WS-* I do not = beleive that it is possible to construct an open license that is = compatible with open source practices and is reliably effective in = preventing litigation from parties that are using the technology without = reciprocation. =20 Fortunately it turns out that this is not a requirement. Open Source = projects do not want a license, and the IPR holder don't actually want = to have to issue one. All that everyone wants in this is to not get = sued. So the Microsoft Open Promise type approach is definitely the one = that we should be looking to adopt going forward. =20 What would be useful is if we had a small number of standard legal = deeds/licenses/contracts/whatever released under a creative commons type = license for this type of arrangement.=20 =20 =20 If there were in addition some standard non disclosure contracts, = standard contracts for holding pre-standards meeting and the like the = result could be turned into a book which most managers in the valley = would probably end up buying.=20 ________________________________ From: Ted Hardie [mailto:hardie@qualcomm.com] Sent: Fri 19/10/2007 5:32 PM To: lrosen@rosenlaw.com; ietf@ietf.org Cc: 'Contreras, Jorge' Subject: RE: A priori IPR choices [Re: Third Last = Call:draft-housley-tls-authz-extns] At 1:58 PM -0700 10/19/07, Ted Hardie wrote: >Cisco has probably disclosed the most patents in an >IETF context (163 disclosures in any case; I'm having trouble getting = the >tool to give me comparisons), but its licenses don't seem to have = allowed >both open source and proprietary implementations. My apologies for the major typo. I meant "don't seem to have = prevented". Sorry for the goof, Ted _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ------_=_NextPart_001_01C812B2.C3A5CD8D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: A priori IPR choices [Re: Third Last = Call:draft-housley-tls-authz-extns]=0A= =0A= =0A= =0A=
=0A=
The question = is whether in the light of the SCO vs IBM case the reciprocity clauses = actually have the intended effect.
=0A=
 
=0A=
Having been involved in the = license issues surrounding WS-* I do not beleive that it is possible to = construct an open license that is compatible with open source practices = and is reliably effective in preventing litigation from parties that are = using the technology without reciprocation.
=0A=
 
=0A=
Fortunately it turns out that = this is not a requirement. Open Source projects do not want a license, = and the IPR holder don't actually want to have to issue one. All that = everyone wants in this is to not get sued. So the Microsoft Open Promise = type approach is definitely the one that we should be looking to adopt = going forward.
=0A=
 
=0A=
What would be useful is if we = had a small number of standard legal deeds/licenses/contracts/whatever = released under a creative commons type license for this type of = arrangement.
=0A=
 
=0A=
 
=0A=
If there were in addition = some standard non disclosure contracts, standard contracts for holding = pre-standards meeting and the like the result could be turned = into a book which most managers in the valley would probably = end up buying.
=0A=

=0A=
=0A= From: Ted Hardie = [mailto:hardie@qualcomm.com]
Sent: Fri 19/10/2007 5:32 = PM
To: lrosen@rosenlaw.com; ietf@ietf.org
Cc: = 'Contreras, Jorge'
Subject: RE: A priori IPR choices [Re: = Third Last Call:draft-housley-tls-authz-extns]

=0A=
=0A=

At 1:58 PM -0700 10/19/07, Ted Hardie = wrote:
>Cisco has probably disclosed the most patents in = an
>IETF context (163 disclosures in any case; I'm having trouble = getting the
>tool to give me comparisons), but its licenses don't = seem to have allowed
>both open source and proprietary = implementations.

My apologies for the major typo.  I meant = "don't seem to have prevented".
Sorry for the = goof,
        =         =         =         = Ted

_______________________________________________
Ietf = mailing list
Ietf@ietf.org
https://www1.ietf.or= g/mailman/listinfo/ietf

------_=_NextPart_001_01C812B2.C3A5CD8D-- --===============1293898566== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============1293898566==-- From ietf-bounces@ietf.org Sat Oct 20 15:53:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjJyo-0002yV-N2; Sat, 20 Oct 2007 15:27:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjJyl-0002qG-TK for ietf@ietf.org; Sat, 20 Oct 2007 15:27:24 -0400 Received: from rv-out-0910.google.com ([209.85.198.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjJyb-0006et-N4 for ietf@ietf.org; Sat, 20 Oct 2007 15:27:19 -0400 Received: by rv-out-0910.google.com with SMTP id l15so683128rvb for ; Sat, 20 Oct 2007 12:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=o1RN4yrjjLKNpyLLBZsKyNBGp9uFNVwSuCp8IpB53uI=; b=P6jOOOeY8egDx8VT88X5vxPN+gNc3DmRlGsesbdXyZ4e66iicz8SIp2GdQmip8Ouo0IIlptB7ElXwb24CbapXUnLrcYJV/YmMy9WD2R7O+uZoLTK5swPIPhEUVTXtgKulnUlR83JaVl3nK22HJ5hI6FsUNJUTpS1LGGpd2L5exc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=kZv1v2uFaO+QkOISgDYqcBoP9WF/MKBR0oVJesu/xyNwm5wJezYq+b4MHILgbbEZlFZS9JQq7GRJSZycwU/9+M179v43OjnQEZ3Gwvk5STIXdVBK+0rA0/gn0iXvqEFljcCHF1R5LwWQ78bv3uTjqM2YxhCNjru7v3cofDbSj7c= Received: by 10.141.159.13 with SMTP id l13mr1621366rvo.1192908398008; Sat, 20 Oct 2007 12:26:38 -0700 (PDT) Received: from ?10.1.1.7? ( [222.153.14.113]) by mx.google.com with ESMTPS id b39sm6220120rvf.2007.10.20.12.26.35 (version=SSLv3 cipher=RC4-MD5); Sat, 20 Oct 2007 12:26:37 -0700 (PDT) Message-ID: <471A5668.8060505@gmail.com> Date: Sun, 21 Oct 2007 08:26:32 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov><87y7e08phu.fsf@mocca.josefsson.org><2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com><4717D090.1000908@gmail.com><18199.55877.791858.498365@swbmbp.local><03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA><877iljv6ed.fsf@mocca.josefsson.org><042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Ted Hardie , "Contreras, Jorge" , ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Phill, > If there were in addition some standard non disclosure contracts, standard contracts for holding pre-standards meeting and the like the result could be turned into a book which most managers in the valley would probably end up buying. Most of them, and those in Armonk that I used to work for, bought Section 10 of RFC 2026 and its successors. Certainly, open source was less of a factor when that regime was designed, but Linux still supports TCP/IP as far as I know. So I think the experimental evidence supports the arguments you're hearing from me, Ted and others. Don't confuse that with a liking for standards encumbered by patents with expensive licensing conditions. It's simply a matter of finding a pragmatic compromise in a world where software patents are granted, and often upheld by the courts, so that the goal of 100% unencumbered standards is unrealistic. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 20 22:41:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjQO7-0001qq-4b; Sat, 20 Oct 2007 22:17:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjQO5-0001qk-TJ for ietf@ietf.org; Sat, 20 Oct 2007 22:17:57 -0400 Received: from mail26f.sbc-webhosting.com ([216.173.237.180]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IjQO2-0005gn-A2 for ietf@ietf.org; Sat, 20 Oct 2007 22:17:54 -0400 Received: from mx98.stngva01.us.mxservers.net (198.173.112.35) by mail26f.sbc-webhosting.com (RS ver 1.0.95vs) with SMTP id 2-0413383072 for ; Sat, 20 Oct 2007 22:17:53 -0400 (EDT) Received: from mmm2630.sbc-webhosting.com [216.173.237.89] (EHLO mmm2630.sbc-webhosting.com) by mx98.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id e75ba174.12674.122.mx98.stngva01.us.mxservers.net; Sat, 20 Oct 2007 22:12:14 -0400 (EDT) Received: (qmail 32017 invoked from network); 21 Oct 2007 02:17:52 -0000 Received: from unknown (HELO LROSENTOSHIBA) (lrosen@208.106.45.202) by with ESMTPA; 21 Oct 2007 02:17:52 -0000 From: "Lawrence Rosen" To: References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov><87y7e08phu.fsf@mocca.josefsson.org><2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com><4717D090.1000908@gmail.com><18199.55877.791858.498365@swbmbp.local><03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA><877iljv6ed.fsf@mocca.josefsson.org><042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> Date: Sat, 20 Oct 2007 19:15:58 -0700 Organization: Rosenlaw & Einschlag Message-ID: <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <471A5668.8060505@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgTTyL2K6Hy0a/DTUyXl62PEFXz3wAABRLw X-Spam: [F=0.0273326528; heur=0.500(-26100); stat=0.061; spamtraq-heur=0.300(2007101727)] X-MAIL-FROM: X-SOURCE-IP: [216.173.237.89] X-SF-Loop: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: RE: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lrosen@rosenlaw.com List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Brian Carpenter wrote: > ... so that the > goal of 100% unencumbered standards is unrealistic. That's almost certainly true. The world is full of encumbered standards, including in products I buy and use every day. I agree with you that THAT goal is unrealistic. No Don Quixote here! In fact, most IP attorneys like me support the freedom of individuals and companies to seek patents on their inventive technology and to profit - alone or in legal combination with their business partners - with products that implement those patents. But we're talking here about IETF standards, specifications that are prepared cooperatively and for free by talented individuals, companies and countries around the world. These specifications are intended for implementation everywhere to facilitate communications among us all. None of us want patent surprises when we implement IETF specifications. Everyone expects IETF to take reasonable steps, consistent with its fundamental technical mission, to de-mine the patent landscape so that anyone can implement our worldwide specifications in products of all types. I'm not proposing unrealistic goals, but instead proposing this more limited IETF-centric goal of free standards for IETF specifications. That is why I suggested that as a charter for the IPR-WG to review and propose how to make it happen here. As for those other non-IETF patent-encumbered standards: They can probably survive without IETF's free help. /Larry > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Saturday, October 20, 2007 12:27 PM > To: Hallam-Baker, Phillip > Cc: Ted Hardie; lrosen@rosenlaw.com; ietf@ietf.org; Contreras, Jorge > Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls- > authz-extns] > > Phill, > > > If there were in addition some standard non disclosure contracts, > standard contracts for holding pre-standards meeting and the like the > result could be turned into a book which most managers in the valley would > probably end up buying. > > Most of them, and those in Armonk that I used to work for, bought Section > 10 of RFC 2026 and its successors. Certainly, open > source was less of a factor when that regime was designed, but Linux still > supports TCP/IP as far as I know. So I think the > experimental evidence supports the arguments you're hearing from me, Ted > and others. > > Don't confuse that with a liking for standards encumbered by patents with > expensive licensing conditions. It's simply a matter > of finding a pragmatic compromise in a world where software patents are > granted, and often upheld by the courts, so that the > goal of 100% unencumbered standards is unrealistic. > > Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Oct 21 05:12:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjWUn-0005Tj-UE; Sun, 21 Oct 2007 04:49:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjWUm-0005TM-1r for ietf@ietf.org; Sun, 21 Oct 2007 04:49:16 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjWUf-0008WO-Rs for ietf@ietf.org; Sun, 21 Oct 2007 04:49:16 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id DAFCE24080E; Sun, 21 Oct 2007 09:48:37 +0200 (CEST) Received: by horcrux (Postfix, from userid 1000) id 0C4DC1579EF; Sun, 21 Oct 2007 08:47:15 +0000 (GMT) Date: Sun, 21 Oct 2007 08:47:15 +0000 From: Stephane Bortzmeyer To: ietf@ietf.org Message-ID: <20071021084715.GA12511@laperouse.bortzmeyer.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 7.04 (feisty) User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: Re: Last Call: draft-klensin-unicode-escapes (ASCII Escaping of Unicode Characters) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Thu, Oct 18, 2007 at 02:44:02PM -0400, The IESG wrote a message of 24 lines which said: > The IESG has received a request from an individual submitter to consider > the following document: > > - 'ASCII Escaping of Unicode Characters ' > as a BCP For those unfamiliar with the issues, do note that the document has a small applicability realm. Most IETF protocols can handle Unicode in one of its main encodings such as UTF-8. And discussing Unicode in texts intended for human consumption is already done with the U+nnnn standard notation. What this document covers is the needs of some protocols / formats who cannot handle a standard Unicode encoding. They are not many. A typical example is RFC 4646 for its registry. (4646bis, under work, will no longer need it.) So, no need for lengthy flames :-) This is a proposal to handle the last few non-fully-Unicode corners of the Internet world. As so, I support this document, I find it useful, I've reviewed it and and I find it reaches a reasonable balance between being too normative (forcing one and only one ASCII escape method) and being not enough normative (just documenting different methods, without giving indications to protocol / format authors about the best choices). _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Oct 21 06:49:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjY5q-0002RI-O8; Sun, 21 Oct 2007 06:31:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjY5p-0002RA-DR for ietf@ietf.org; Sun, 21 Oct 2007 06:31:37 -0400 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjY5k-0005Qv-6h for ietf@ietf.org; Sun, 21 Oct 2007 06:31:37 -0400 Received: from harrington73653 (unknown[61.48.39.185]) by comcast.net (sccrmhc15) with SMTP id <2007102110311701500g956fe>; Sun, 21 Oct 2007 10:31:19 +0000 From: "David Harrington" To: , References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov><87y7e08phu.fsf@mocca.josefsson.org><2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com><4717D090.1000908@gmail.com><18199.55877.791858.498365@swbmbp.local><03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA><877iljv6ed.fsf@mocca.josefsson.org><042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com><471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> Date: Sun, 21 Oct 2007 18:31:00 +0800 Message-ID: <019c01c813cd$7b30fa90$b927303d@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> Thread-Index: AcgTTyL2K6Hy0a/DTUyXl62PEFXz3wAABRLwAB7/t0A= X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Subject: RE: A priori IPR choices [Re: Third LastCall:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > -----Original Message----- > From: Lawrence Rosen [mailto:lrosen@rosenlaw.com] > Sent: Sunday, October 21, 2007 10:16 AM > To: ietf@ietf.org > Subject: RE: A priori IPR choices [Re: Third > LastCall:draft-housley-tls-authz-extns] > > [...] Everyone > expects IETF to take reasonable steps, consistent with its fundamental > technical mission, to de-mine the patent landscape so that anyone can > implement our worldwide specifications in products of all types. > I don't presume to speak for everyone. I expect the IETF to take reasonable steps to de-mine the patent landscape related to our own policies, so that anyone can implement our worldwide specifications in products of all types. I expect those reasonable steps to include IPR disclosure by participants in the process, and where IPR has been disclosed, the IETF should discuss the tradeoffs and make a decision about whether IPR-encumbrance is acceptable. I do NOT expect those reasonable steps to include declaring that all companies contributing to a standard must give away associated IPR for free, to suit the open source community. I think it is an unreasonable demand from the open source community, and it is the licensing terms of open source implementations that place limitations on implementing our worldwide specifications in products of all types. David Harrington dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Oct 21 06:49:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjY5s-0002Ro-GV; Sun, 21 Oct 2007 06:31:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjY5r-0002RO-HY for ietf@ietf.org; Sun, 21 Oct 2007 06:31:39 -0400 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjY5q-0005Qv-DW for ietf@ietf.org; Sun, 21 Oct 2007 06:31:39 -0400 Received: from harrington73653 (unknown[61.48.39.185]) by comcast.net (sccrmhc15) with SMTP id <2007102110312001500g956ge>; Sun, 21 Oct 2007 10:31:21 +0000 From: "David Harrington" To: , References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov><87y7e08phu.fsf@mocca.josefsson.org><2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com><4717D090.1000908@gmail.com><18199.55877.791858.498365@swbmbp.local><03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA><877iljv6ed.fsf@mocca.josefsson.org><042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <043201c812a1$cef4e650$6401a8c0@LROSENTOSHIBA> Date: Sun, 21 Oct 2007 18:31:00 +0800 Message-ID: <019d01c813cd$7be15ed0$b927303d@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <043201c812a1$cef4e650$6401a8c0@LROSENTOSHIBA> Thread-Index: AcgSk4m2kf7L2dkLTNa+/xalGbNf8wADDOewAEqge4A= X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Subject: RE: A priori IPR choices [Re: Third LastCall:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi, I do not think there is consensus that what you want is what the IETF wants. David Harrington dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Lawrence Rosen [mailto:lrosen@rosenlaw.com] > Sent: Saturday, October 20, 2007 6:46 AM > To: ietf@ietf.org > Subject: RE: A priori IPR choices [Re: Third > LastCall:draft-housley-tls-authz-extns] > > Ted Hardie wrote: > > Ah, I see why you appear to have changed your position. > You actually > > want the result you're arguing for built into the charter of > > the IPR working group, beforehand without letting the > community actually > > discuss it. Thanks for re-affirming my faith in your > consistency. > > You're welcome. To state it more fairly, I want the result > I'm arguing for > to be built into the charter so that the WG can examine > fairly what it will > take to reach that goal. The WG cannot adopt a policy for > IETF, only propose > one. But the WG's work should be goal-directed. > > By the way, that's not such a change of tactic for that > particular IPR-WG. > You previously argued in committee that the current IETF > patent policy is > NOT a problem, and in that spirit the IPR-WG previously buried every > counter-proposal we made as "off-charter"! So let's play the > charter game > fairly, please, by the same rules you played them. Let's > charter the IPR-WG > to develop a proposal that achieves a specific goal to fix a perceived > patent problem. You can always argue against it in committee > or vote against > it if a serious proposal toward that goal gets before the > IETF as a whole. > > /Larry Rosen > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Oct 21 08:32:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjZhP-0002uf-Ee; Sun, 21 Oct 2007 08:14:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjZhK-0002jO-9e for ietf@ietf.org; Sun, 21 Oct 2007 08:14:26 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjZh9-0002ir-1r for ietf@ietf.org; Sun, 21 Oct 2007 08:14:21 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IjZgn-00079K-Bd for ietf@ietf.org; Sun, 21 Oct 2007 12:13:53 +0000 Received: from 1cust221.tnt1.hbg2.deu.da.uu.net ([149.225.10.221]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 21 Oct 2007 12:13:53 +0000 Received: from nobody by 1cust221.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 21 Oct 2007 12:13:53 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: "Frank Ellermann" Date: Sun, 21 Oct 2007 14:13:37 +0200 Organization: http://purl.net/xyzzy Lines: 18 Message-ID: References: <20071021084715.GA12511@laperouse.bortzmeyer.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 1cust221.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: Re: Last Call: draft-klensin-unicode-escapes (ASCII Escaping ofUnicode Characters) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Stephane Bortzmeyer wrote: > A typical example is RFC 4646 for its registry. (4646bis, under > work, will no longer need it.) s/will/might/ until the Chairs dare claim "rough consensus"... > So, no need for lengthy flames :-) ...I kept it short ;-) For another example see the EAI DSN draft. > I support this document, I find it useful, I've reviewed it and=20 > and I find it reaches a reasonable balance [...] +1 Frank _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Oct 21 20:47:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijl6W-000220-4V; Sun, 21 Oct 2007 20:25:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijl6S-0001oE-Cg for ietf@ietf.org; Sun, 21 Oct 2007 20:25:08 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ijl6K-0001VW-O6 for ietf@ietf.org; Sun, 21 Oct 2007 20:25:01 -0400 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l9M0LCr9007706; Sun, 21 Oct 2007 17:21:12 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Oct 2007 17:24:40 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 21 Oct 2007 17:24:39 -0700 Message-ID: <2788466ED3E31C418E9ACC5C316615570462C6@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] Thread-Index: AcgTTx8Ya6ZnijQhT7u2cdGhxrBP/AA8tBbM From: "Hallam-Baker, Phillip" To: "Brian E Carpenter" X-OriginalArrivalTime: 22 Oct 2007 00:24:40.0349 (UTC) FILETIME=[EF7DD4D0:01C81441] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Ted Hardie , "Contreras, Jorge" , ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0159328552==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============0159328552== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81441.EF480155" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81441.EF480155 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Different era. Today we have had several companies burnes for up to half a billion = dollars with piffle patents. When tcpip was being written the patent office had not become a profit = center, the seven nos were still an issue. Sent from my GoodLink Wireless Handheld (www.good.com) -----Original Message----- From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] Sent: Saturday, October 20, 2007 12:26 PM Pacific Standard Time To: Hallam-Baker, Phillip Cc: Ted Hardie; lrosen@rosenlaw.com; ietf@ietf.org; Contreras, Jorge Subject: Re: A priori IPR choices [Re: Third Last = Call:draft-housley-tls-authz-extns] Phill, > If there were in addition some standard non disclosure contracts, = standard contracts for holding pre-standards meeting and the like the = result could be turned into a book which most managers in the valley = would probably end up buying.=20 Most of them, and those in Armonk that I used to work for, bought = Section 10 of RFC 2026 and its successors. Certainly, open=20 source was less of a factor when that regime was designed, but Linux = still supports TCP/IP as far as I know. So I think the=20 experimental evidence supports the arguments you're hearing from me, Ted = and others. Don't confuse that with a liking for standards encumbered by patents = with expensive licensing conditions. It's simply a matter=20 of finding a pragmatic compromise in a world where software patents are = granted, and often upheld by the courts, so that the=20 goal of 100% unencumbered standards is unrealistic. Brian ------_=_NextPart_001_01C81441.EF480155 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: A priori IPR choices [Re: Third Last = Call:draft-housley-tls-authz-extns]

Different era.

Today we have had several companies burnes for up to half a billion = dollars with piffle patents.

When tcpip was being written the patent office had not become a profit = center, the seven nos were still an issue.


Sent from my GoodLink Wireless Handheld (www.good.com)

 -----Original Message-----
From:   Brian E Carpenter [mailto:brian.e.carpenter@gmai= l.com]
Sent:   Saturday, October 20, 2007 12:26 PM Pacific Standard = Time
To:     Hallam-Baker, Phillip
Cc:     Ted Hardie; lrosen@rosenlaw.com; = ietf@ietf.org; Contreras, Jorge
Subject:        Re: A priori IPR = choices [Re: Third Last Call:draft-housley-tls-authz-extns]

Phill,

> If there were in addition some standard non disclosure contracts, = standard contracts for holding pre-standards meeting and the like the = result could be turned into a book which most managers in the valley = would probably end up buying.

Most of them, and those in Armonk that I used to work for, bought = Section 10 of RFC 2026 and its successors. Certainly, open
source was less of a factor when that regime was designed, but Linux = still supports TCP/IP as far as I know. So I think the
experimental evidence supports the arguments you're hearing from me, Ted = and others.

Don't confuse that with a liking for standards encumbered by patents = with expensive licensing conditions. It's simply a matter
of finding a pragmatic compromise in a world where software patents are = granted, and often upheld by the courts, so that the
goal of 100% unencumbered standards is unrealistic.

    Brian

------_=_NextPart_001_01C81441.EF480155-- --===============0159328552== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0159328552==-- From ietf-bounces@ietf.org Sun Oct 21 20:47:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijl6q-0002hJ-B2; Sun, 21 Oct 2007 20:25:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijl6n-0002c3-EU for ietf@ietf.org; Sun, 21 Oct 2007 20:25:29 -0400 Received: from email.xpasc.com ([65.85.17.142]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ijl6m-0001WE-KB for ietf@ietf.org; Sun, 21 Oct 2007 20:25:29 -0400 Received: from bslepgate.xpasc.com (localhost.localdomain [127.0.0.1]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id EA28C100585 for ; Sun, 21 Oct 2007 17:24:36 -0700 (PDT) X-Propel-Return-Path: Received: from email.xpasc.com ([10.1.2.88]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 2.1.7.8167-src $Rev: 8148 $) id iz6Ur7am0oA0; Sun, 21 Oct 2007 17:24:36 -0700 Received: from xpasc.com (egate.xpasc.com [10.1.2.49]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id 49381100584 for ; Sun, 21 Oct 2007 17:24:36 -0700 (PDT) Received: from egate.xpasc.com (egate.xpasc.com [10.1.2.49]) by xpasc.com (8.11.2/8.11.2) with ESMTP id l9M0OZ711845 for ; Sun, 21 Oct 2007 17:24:35 -0700 Date: Sun, 21 Oct 2007 17:24:34 -0700 (PDT) From: David Morris cc: In-Reply-To: <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Propel-ID: iz6Ur7am0oA0 X-Spam-Score: 3.2 (+++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: RE: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Sat, 20 Oct 2007, Lawrence Rosen wrote: > Brian Carpenter wrote: > > ... so that the > > goal of 100% unencumbered standards is unrealistic. >... > But we're talking here about IETF standards, specifications that are > prepared cooperatively and for free by talented individuals, companies and For 'free' ??? I expect you'll find that that for the majority of IETF partcipants, participation is part of what they do for their employers. Meeting fees and expenses are re-imbursed, etc. That is merely informed self interest. > countries around the world. These specifications are intended for > implementation everywhere to facilitate communications among us all. None of > us want patent surprises when we implement IETF specifications. Everyone > expects IETF to take reasonable steps, consistent with its fundamental > technical mission, to de-mine the patent landscape so that anyone can > implement our worldwide specifications in products of all types. Actually, there is GREAT value in having a widely used protocol well documented, even if it is encumbered by IPR restrictions. I personally have no objection to having the IETF publish RFCs which depend in whole or part on encumbered technologies as long as those restrictions are documented in the RFC. As a matter of courtesy, the existance of such encumberances should be revealed when known to an individual associated with the process of submitting the information to any group associated with the IETF. We need to be careful however to make any IPR decisions based the merits of the technical issues and NOT based on our frustration that notification wasn't timely. I consider it a given that the best the IETF can achieve is to recognize IPR known to participants in the IETF process. Given the nature of patent and copyright processes, there is no way to insure that a seemingly new idea conceived by an IETF working group isn't already encumbered. It is my observation that the IETF tends to operate in two modes: a. Documenting or revising the documentation of existing protocols b. Designing protocols (or improvements) to solve previously unresolved problems In mode 'a', documenation may be independant submissions as well as organized activities of the IETF community. To publish an independant submission requires some attention from the community, the RFC editor, etc. The question is whether publication will contribute to the community. Knowning how a totally encumbered protocol works, may facilitate the design of related protocols or simply help network engineers keep their portion of the Internet operational. If so, the publication effort is probably justified. The remaining mode 'a' activity, as the organized work product of the IETF, likely a WG, should have IPR handled as in mode 'b'. The addition of IPR encumbered technology to a protocol should be a decision based on technical merits. It makes no sense to determine before specific technology has been identified for consideration that encumbered technology can't be considered. I have seen enough disagreements within the IETF as to what is the best technology that I know that comparison of techologies won't be easy when there is no known encumberance. But I would hope that a good technical design will prevale. In the end, the Internet wide operating cost associated with using less than optimal technology shouldn't exceed the expected costs associated with use of encumbered technology. It should be clear that all known encumberances MUST be documented in an RFC which utilizes the technology. A participant in the IETF process should never bring technology to the IETF they know or believe to be encumbered without revealing those encumberances. Furthermore, they should never advocate adoption of technology from which they will directly or indirectly benefit in come tangible way. If an individual is aware of technology encumberances which they can't reveal, they should drop out of the related working groups or other IETF organized discussions. It really isn't socially acceptable to entrap IETF participants with enticing techology whose encumberances aren't revealed. David Morris _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 22 01:21:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjpML-0003tJ-MM; Mon, 22 Oct 2007 00:57:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjpMJ-0003t8-Pg for ietf@ietf.org; Mon, 22 Oct 2007 00:57:47 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjpMJ-0006Lr-5e for ietf@ietf.org; Mon, 22 Oct 2007 00:57:47 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.177.2; Sun, 21 Oct 2007 21:57:46 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by TK5-EXHUB-C101.redmond.corp.microsoft.com ([157.54.70.76]) with mapi; Sun, 21 Oct 2007 21:57:46 -0700 From: Peter Constable To: "ietf@ietf.org" Date: Sun, 21 Oct 2007 21:57:37 -0700 Thread-Topic: Last Call: draft-klensin-unicode-escapes (ASCII Escaping ofUnicode Characters) to BCP Thread-Index: AcgUCEqi2OypWGDCQZeZV8tB9o5cLgAXvtog Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -8.0 (--------) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Subject: Re: Last Call: draft-klensin-unicode-escapes (ASCII Escaping ofUnicode Characters) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I have a terminological objection to this draft, mainly in section 2. I hav= e other comments regarding section 2 I'll mention. First, terminology: the heading for section 2 has "...Table Position...", a= nd the body refers to "code point position in the table". While the term "c= ode table" could have been used in the Unicode Standard to refer to the enc= oded entities and their encoding, it is not. The Unicode Standard uses these terms: - It uses "character set" and "character repertoire" for the collection of = elements being encoded, and "coded character set" for the set of pairs of s= uch elements and their encoded representations. - It uses "codespace" to refer to a range of numeric values used as encoded= representations, and specifically "Unicode codespace" for the range 0 to 1= 0FFFF (hex). - It uses "code point" or "code position" (synonyms) for values in the Unic= ode codespace. Thus, the appropriate term here is simply "code point" or "code position". = "Table position" and "position in the table" are not appropriate since the = Standard never uses "table" in this regard. And "code point position" is re= dundant. Perhaps the wording was attempting to differentiate between code p= oints and various encoded representations of code points. But the latter ar= e not code points per se, so there isn't really any ambiguity. A possible refinement might be to use "Unicode Scalar Value": this refers t= o code points other than surrogate code points. By definition in the Standa= rd, encoded characters can only be assigned to a Unicode Scalar Value. I do= n't see this as a necessary change in the draft, however. Now for other comments on section 2. The draft has: "However, when information about characters is to be processed by people, information about the Unicode code point is preferable to a further encoding of the encoded form of the character." Information about the code point? (The code point of that character is nume= ric / is an integer / is non-negative / is in the range 0 to 10FFFF / is ev= en / is divisible by 17 / is the same value as the number of days the song = "Hey Jude" was on the Top 40 list.) I think it is the code point itself tha= t is to be preferred, not information about it. Also, "a further encoding of the encoding form" isn't going to be clear to = readers. (I'm not sure myself what these words mean themselves; I can guess= at what the author meant, though am not positive.) Thus, I'd change this text to: "However, when information about characters is to be processed by people, reference to the Unicode code point is preferable to encoded representations of the code point." Now, section 2 is talking about alternate representations of an encoded cha= racter, but the flow is a bit mixed up, IMO. The first paragraph says that = there are different equivalent representations but that the Unicode code po= int is preferred. Then the next paragraph revisits the same thing in more d= etail. The sentence from the first paragraph discussed above, once revised = so that it makes a clear statement, already says what paragraph two says in= greater detail. Whether a more succinct or more detailed statement is pref= erred, just say it once. Of course, if the more detailed paragraph two is kept, "code point position= in the table" should be changed to "code point". Also from paragraph two: "the UTF-8 encoding or some other short-form encoding" The term "short-form encoding" isn't explained here and may not be understo= od. I can only guess what is meant. If the intended meaning is what I think= (a reference to shortest-form versus non-shortest-form UTF-8), then I don'= t think it's really relevant. Either way, I'd change the wording to: "the UTF-8 encoding or some other encoding form" (Encoding form is a term defined in the Unicode Standard.) Also: "the other encodes the octets of" I don't think octets are encoded; they are simply referenced using some not= ational system. Thus, change to: "the other uses the octets of ... in some representation." (This gives parallel wording for the two kinds of reference.) Finally: "the Unicode code point forms" Drop "forms": "the Unicode code points" Peter Constable _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 22 07:41:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjvK8-00071Y-SQ; Mon, 22 Oct 2007 07:19:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjvK5-00070T-Qs for ietf@ietf.org; Mon, 22 Oct 2007 07:19:53 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjvJz-0002op-Jv for ietf@ietf.org; Mon, 22 Oct 2007 07:19:53 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 76C9124080E; Mon, 22 Oct 2007 12:19:15 +0200 (CEST) Received: by horcrux (Postfix, from userid 1000) id D6EFF1579EF; Mon, 22 Oct 2007 11:02:57 +0000 (GMT) Date: Mon, 22 Oct 2007 11:02:57 +0000 From: Stephane Bortzmeyer To: Peter Constable Message-ID: <20071022110257.GA11503@laperouse.bortzmeyer.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 7.04 (feisty) User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: "ietf@ietf.org" Subject: Re: Last Call: draft-klensin-unicode-escapes (ASCII Escaping ofUnicode Characters) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Sun, Oct 21, 2007 at 09:57:37PM -0700, Peter Constable wrote a message of 80 lines which said: > Also, "a further encoding of the encoding form" isn't going to be > clear to readers. It is a reference to a bad practice (used in URLs, for instance) to encode twice (for instance in UTF-8, then in %xx escapes of the bytes). > "However, when information about characters is to be processed by > people, reference to the Unicode code point is preferable to > encoded representations of the code point." That's not more clear to me. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 22 11:14:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijytr-0006WX-Is; Mon, 22 Oct 2007 11:09:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijytp-0006VU-6S for ietf@ietf.org; Mon, 22 Oct 2007 11:09:01 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ijyto-0006as-Qm for ietf@ietf.org; Mon, 22 Oct 2007 11:09:01 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.177.2; Mon, 22 Oct 2007 08:08:59 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by TK5-EXHUB-C101.redmond.corp.microsoft.com ([157.54.70.76]) with mapi; Mon, 22 Oct 2007 08:08:59 -0700 From: Peter Constable To: "ietf@ietf.org" Date: Mon, 22 Oct 2007 08:08:51 -0700 Thread-Topic: Last Call: draft-klensin-unicode-escapes (ASCII Escaping ofUnicode Characters) to BCP Thread-Index: AcgUnWpZATr3c2JRTTS2PmGUQnsdRQAHsumg Message-ID: References: <20071022110257.GA11503@laperouse.bortzmeyer.org> In-Reply-To: <20071022110257.GA11503@laperouse.bortzmeyer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: RE: Last Call: draft-klensin-unicode-escapes (ASCII Escaping ofUnicode Characters) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] Sent: Monday, October 22, 2007 4:03 AM >> Also, "a further encoding of the encoding form" isn't going to be >> clear to readers. > > It is a reference to a bad practice (used in URLs, for instance) to > encode twice (for instance in UTF-8, then in %xx escapes of the > bytes). The discussion in that section is about references to characters in general= human-readable content, not in URLs. If that is what the wording is referr= ing to, it's extremely opaque. If that's really what the authors intend to = talk about, it should be explained -- and the section should be organized b= etter so that it makes sense why that particular thing is being discussed. >> "However, when information about characters is to be processed by >> people, reference to the Unicode code point is preferable to >> encoded representations of the code point." > > That's not more clear to me. How can it not be clear? Human-readable content is discussing a Unicode cha= racter and needs to refer to the character in some way. The whole point of = this document is about how to refer. Since Unicode character identity is es= tablished by the name, the code point and the reference glyph, reference ca= n be made using one of those three things. It appears to me that this docum= ent focuses on references based in some way on the code point: is not the k= ey distinction between the code point itself and some encoded representatio= n of the code point? Peter Constable _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 22 11:14:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjypS-00007v-SM; Mon, 22 Oct 2007 11:04:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjypQ-0008Si-Ix for ietf@ietf.org; Mon, 22 Oct 2007 11:04:28 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjypO-0006JP-3W for ietf@ietf.org; Mon, 22 Oct 2007 11:04:26 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D06D74A45; Mon, 22 Oct 2007 11:04:23 -0400 (EDT) From: Sam Hartman To: John C Klensin References: <9712782B6C5C89F23D11EEAD@p3.JCK.COM> <64ECC96122232BBA8ED1FABF@p3.JCK.COM> Date: Mon, 22 Oct 2007 11:04:23 -0400 In-Reply-To: <64ECC96122232BBA8ED1FABF@p3.JCK.COM> (John C. Klensin's message of "Thu, 11 Oct 2007 10:48:26 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ietf@ietf.org Subject: Re: Third Last Call: draft-housley-tls-authz-extns X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>>>> "John" == John C Klensin writes: John> --On Thursday, 11 October, 2007 17:05 +0300 John> Pasi.Eronen@nokia.com wrote: >> John C Klensin wrote: >>> Assuming that this logic is reasonable (and, personally, I >>> do), the question remains as to why the document deserves the >>> special treatment of IESG sponsorship, rather than turning it >>> over to the tender mercies and independent review of the >>> independent submission process. If nothing else, handling it >>> as an independent submission would remove any suspicion that >>> it was being given special treatment because one of its >>> authors was IETF Chair. >>> >>> I'm not strongly advocating that approach, just asking. >> The IANA rules in this case require a document approved by the >> IESG; otherwise, independent submission would indeed be >> preferable. John> Strictly speaking, at least as I understand it, the IANA John> rules (actually, the IETF rules imposed on the IANA) require John> IESG approval of the registration, not IESG John> approval/publication of the document. If independent John> submission would be preferable, nothing would prohibit John> making that submission. Then, assuming that the RFC Editor John> tentatively agreed to publish, the document would be John> submitted for RFC 3932 review and the IESG could sign off on John> IANA registration at that point. I do not believe the IESG should approve this IANA registration unless there is community support to do so. I think the argument that we should publish this document as-is for the record makes no sense to me. If we want to document an approach so that it can be preserved as an archival record, then remove the IANA registration, note the document specifies no code point and note that it is being published to document an approach that did not achieve consensus. We should publish this document if we believe that it is reasonable for people to use this protocol on the Internet and wish to enable that. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 22 11:23:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijz0p-0000p0-BB; Mon, 22 Oct 2007 11:16:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijz0m-0000kv-Dw for ietf@ietf.org; Mon, 22 Oct 2007 11:16:12 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ijz0d-0007AU-KW for ietf@ietf.org; Mon, 22 Oct 2007 11:16:12 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Ijz0V-000LVL-O7; Mon, 22 Oct 2007 11:15:55 -0400 Date: Mon, 22 Oct 2007 11:15:54 -0400 From: John C Klensin To: Sam Hartman Message-ID: <130C61EA2A25E7CF933AFC1C@p3.JCK.COM> In-Reply-To: References: <9712782B6C5C89F23D11EEAD@p3.JCK.COM> <64ECC96122232BBA8ED1FABF@p3.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ietf@ietf.org Subject: Re: Third Last Call: draft-housley-tls-authz-extns X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org --On Monday, 22 October, 2007 11:04 -0400 Sam Hartman wrote: >... > I do not believe the IESG should approve this IANA > registration unless there is community support to do so. > I think the argument that we should publish this document > as-is for the record makes no sense to me. If we want to > document an approach so that it can be preserved as an > archival record, then remove the IANA registration, note the > document specifies no code point and note that it is being > published to document an approach that did not achieve > consensus. > > We should publish this document if we believe that it is > reasonable for people to use this protocol on the Internet and > wish to enable that. Given that this is a protocol document, and that there appears to be no substantive experiment to be performed, I believe that this is an argument for Proposed Standard --possibly with a comment about the IPR situation in an appendix to the RFC -- or no publication at all. Even publication as Informational in order to inform, and perhaps warn, people about something that is being used does not meet the test of "believe that it is reasonable for people to use ... and wish to enable that. I don't know what position that would lead me to as to whether or not it should be published, but that simple choice does appear to me to be the logical conclusion. john _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 22 14:28:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik1o4-0003rn-Ad; Mon, 22 Oct 2007 14:15:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik1o2-0003nu-8X for ietf@ietf.org; Mon, 22 Oct 2007 14:15:14 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik1o1-00072F-OR for ietf@ietf.org; Mon, 22 Oct 2007 14:15:14 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Ik1o0-0000ag-C1; Mon, 22 Oct 2007 14:15:12 -0400 Date: Mon, 22 Oct 2007 14:15:11 -0400 From: John C Klensin To: lrosen@rosenlaw.com, ietf@ietf.org Message-ID: In-Reply-To: <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: RE: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org --On Saturday, 20 October, 2007 19:15 -0700 Lawrence Rosen wrote: >... > But we're talking here about IETF standards, specifications > that are prepared cooperatively and for free by talented > individuals, companies and countries around the world. These > specifications are intended for implementation everywhere to > facilitate communications among us all. >... Larry, with all due respect, if you substitute "ISO/IEC JTC1" or "IEEE" (at least in the computer and communications areas for both) in the above statements, they will still be true. The IETF is not particularly special in this regard. To me, the question is simply one of whether trying to insist on an unencumbered regime (whether for technical, economic, or moral/ religious reasons) is important enough to justify rejecting, a priori, any encumbered technology. The IETF has decided, repeatedly, that the answer is "no" and "we want to look at these things on a case-by-case basis and evaluate the tradeoffs". While the part that follows the "no" differs, that is the same conclusion reached by ISO, IEC, IEEE, and others. If you want to pursue this further, I think it would be helpful if you started supplying arguments that we haven't heard, repeatedly, before. Neither repeating those arguments, nor making the assumption that the IETF agrees with your goals and priorities, seems to be causing progress in this area. What it does accomplish is to get people to stop reading threads on this subject, which further lowers the odds of getting IETF consensus on a change in position. Just my opinion, of course. john _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 22 16:06:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik3MH-00055H-A3; Mon, 22 Oct 2007 15:54:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik3ME-00052X-91 for ietf@ietf.org; Mon, 22 Oct 2007 15:54:38 -0400 Received: from tarsus.bollow.ch ([82.195.230.222]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik3MD-0006Bu-NV for ietf@ietf.org; Mon, 22 Oct 2007 15:54:38 -0400 Received: from tarsus.bollow.ch (localhost [127.0.0.1]) by tarsus.bollow.ch (Postfix) with ESMTP id CB87EB2806E for ; Mon, 22 Oct 2007 22:30:25 +0200 (CEST) Authentication-Results: tarsus.bollow.ch from=nb@bollow.ch; domainkey=neutral (no signature; no policy for bollow.ch) Received: from quill.bollow.ch (69-42.203-62.cust.bluewin.ch [62.203.42.69]) by tarsus.bollow.ch (Postfix) with ESMTP for ; Mon, 22 Oct 2007 22:30:25 +0200 (CEST) Received: by quill.bollow.ch (Postfix, from userid 1000) id 4D9A22202DA; Mon, 22 Oct 2007 21:57:23 +0200 (CEST) From: Norbert Bollow Organization: Bollow Software Economics Research MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=iso-8859-1 To: ietf@ietf.org In-reply-to: (message from John C Klensin on Mon, 22 Oct 2007 14:15:11 -0400) References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> Message-Id: <20071022195723.4D9A22202DA@quill.bollow.ch> Date: Mon, 22 Oct 2007 21:57:23 +0200 (CEST) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org John C Klensin wrote: > > But we're talking here about IETF standards, specifications > > that are prepared cooperatively and for free by talented > > individuals, companies and countries around the world. These > > specifications are intended for implementation everywhere to > > facilitate communications among us all.=20 > >... >=20 > Larry, with all due respect, if you substitute "ISO/IEC JTC1" or > "IEEE" (at least in the computer and communications areas for > both) in the above statements, they will still be true. The > IETF is not particularly special in this regard. I agree. There are very good reasons to insist in all fora where standards for protocols and data formats are developed that such standards must not be patent-encumbered. > To me, the question is simply one of whether trying to insist on > an unencumbered regime (whether for technical, economic, or > moral/ religious reasons) is important enough to justify > rejecting, a priori, any encumbered technology. The IETF has > decided, repeatedly, that the answer is "no" and "we want to > look at these things on a case-by-case basis and evaluate the > tradeoffs". While the part that follows the "no" differs, that > is the same conclusion reached by ISO, IEC, IEEE, and others. However the economic importance of insisting that standards must not be patent-encumbered is increasing. Therefore the decisions of the past can not validly be accepted as strong arguments against Larry's current initiative. > If you want to pursue this further, I think it would be helpful > if you started supplying arguments that we haven't heard, > repeatedly, before. Do you have a list of the arguments that you have heard so often already that you're not interested in hearing them again? Greetings, Norbert. --=20 Norbert Bollow http://Norbert.ch President of the Swiss Internet User Group SIUG http://SIUG.ch Working on establishing a non-corrupt and truly /open/ international standards organization http://OpenISO.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 22 16:16:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik3bI-0000kT-6j; Mon, 22 Oct 2007 16:10:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik3bF-0000bj-CM for ietf@ietf.org; Mon, 22 Oct 2007 16:10:09 -0400 Received: from mail26b.sbc-webhosting.com ([216.173.237.165] helo=mail26c.sbc-webhosting.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ik3bC-00070g-25 for ietf@ietf.org; Mon, 22 Oct 2007 16:10:06 -0400 Received: from mx61.stngva01.us.mxservers.net (204.202.242.131) by mail26b.sbc-webhosting.com (RS ver 1.0.95vs) with SMTP id 3-0731653803 for ; Mon, 22 Oct 2007 16:10:04 -0400 (EDT) Received: from mmm2630.sbc-webhosting.com [216.173.237.89] (EHLO mmm2630.sbc-webhosting.com) by mx61.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id 9820d174.29303.054.mx61.stngva01.us.mxservers.net; Mon, 22 Oct 2007 16:05:29 -0400 (EDT) Received: (qmail 91301 invoked from network); 22 Oct 2007 20:10:01 -0000 Received: from unknown (HELO LROSENTOSHIBA) (lrosen@208.106.45.202) by with ESMTPA; 22 Oct 2007 20:10:01 -0000 From: "Lawrence Rosen" To: References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> Date: Mon, 22 Oct 2007 13:08:14 -0700 Organization: Rosenlaw & Einschlag Message-ID: <04fe01c814e7$47f33060$6401a8c0@LROSENTOSHIBA> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgU1327/ZLarlBCSw20HiwXuZ9UiQACBxCg X-Spam: [F=0.0043103448; heur=0.500(-26100); stat=0.010; spamtraq-heur=0.300(2007101727)] X-MAIL-FROM: X-SOURCE-IP: [216.173.237.89] X-SF-Loop: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Subject: RE: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lrosen@rosenlaw.com List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org John Klensin wrote: > If you want to pursue this further, I think it would be helpful > if you started supplying arguments that we haven't heard, > repeatedly, before. Neither repeating those arguments, nor > making the assumption that the IETF agrees with your goals and > priorities, seems to be causing progress in this area. What it > does accomplish is to get people to stop reading threads on this > subject, which further lowers the odds of getting IETF consensus > on a change in position. John and others, I have never made my proposal on ietf@ietf.org before. Indeed, I only started contributing on this list recently. I'm pleased that YOU have heard my arguments before in other venues, but there's no reason to assume that others here have done so. I don't assume that IETF agrees with my goals or priorities, nor perhaps do you have any reason to assume that the broader IETF community agrees with you. I made my suggestion here to re-charter the IPR-WG after lurking on the list for long enough to understand (I hope) the issues that this list considers and the cultural environment in which those considerations occur, and long after I became convinced that at least some of the people participating on the much narrower IPR-WG list were culturally and philosophically unwilling to listen to *any* arguments that IETF patent policy should be clarified or changed. Your reference to the older and more stubbornly traditional ISO, IEC and IEEE merely reminds me of important counter-examples, W3C and OASIS. Each standards organization needs to articulate its patent policy in light of its own mission and culture. IETF is a world-wide organization of volunteers that standardizes much of the Internet. This is an *open* Internet, available to all. Encumbering it with non-free patents is a danger that W3C and OASIS have addressed. I suggest that IETF should address it too! So please stand back a bit, John, and let the arguments on all sides be fairly raised and rebutted before the participants on this list. Let's see if consensus does arise here. Please don't assume, as I don't assume, that everyone who has an opinion has already spoken up. I hope that others here will speak up. *************** Once again, specifically what I request is that we charter the IETF IPR-WG to propose policies and procedures, consistent with the worldwide mission of IETF, which will result in IETF specifications unencumbered by restrictive, non-free patents. *************** > -----Original Message----- > From: John C Klensin [mailto:john-ietf@jck.com] > Sent: Monday, October 22, 2007 11:15 AM > To: lrosen@rosenlaw.com; ietf@ietf.org > Subject: RE: A priori IPR choices [Re: Third Last Call:draft-housley-tls- > authz-extns] > > > > --On Saturday, 20 October, 2007 19:15 -0700 Lawrence Rosen > wrote: > > >... > > But we're talking here about IETF standards, specifications > > that are prepared cooperatively and for free by talented > > individuals, companies and countries around the world. These > > specifications are intended for implementation everywhere to > > facilitate communications among us all. > >... > > Larry, with all due respect, if you substitute "ISO/IEC JTC1" or > "IEEE" (at least in the computer and communications areas for > both) in the above statements, they will still be true. The > IETF is not particularly special in this regard. > > To me, the question is simply one of whether trying to insist on > an unencumbered regime (whether for technical, economic, or > moral/ religious reasons) is important enough to justify > rejecting, a priori, any encumbered technology. The IETF has > decided, repeatedly, that the answer is "no" and "we want to > look at these things on a case-by-case basis and evaluate the > tradeoffs". While the part that follows the "no" differs, that > is the same conclusion reached by ISO, IEC, IEEE, and others. > > If you want to pursue this further, I think it would be helpful > if you started supplying arguments that we haven't heard, > repeatedly, before. Neither repeating those arguments, nor > making the assumption that the IETF agrees with your goals and > priorities, seems to be causing progress in this area. What it > does accomplish is to get people to stop reading threads on this > subject, which further lowers the odds of getting IETF consensus > on a change in position. > > Just my opinion, of course. > john _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 22 16:38:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik3s6-0000yv-Ta; Mon, 22 Oct 2007 16:27:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik3s4-0000wc-OF for ietf@ietf.org; Mon, 22 Oct 2007 16:27:32 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik3s1-00086u-SA for ietf@ietf.org; Mon, 22 Oct 2007 16:27:32 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Ik3rw-0003rI-3N; Mon, 22 Oct 2007 16:27:25 -0400 Date: Mon, 22 Oct 2007 16:27:20 -0400 From: John C Klensin To: Norbert Bollow , ietf@ietf.org Message-ID: In-Reply-To: <20071022195723.4D9A22202DA@quill.bollow.ch> References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org --On Monday, 22 October, 2007 21:57 +0200 Norbert Bollow wrote: > John C Klensin wrote: >> > But we're talking here about IETF standards, specifications >> > that are prepared cooperatively and for free by talented >> > individuals, companies and countries around the world. These >> > specifications are intended for implementation everywhere to >> > facilitate communications among us all. >> > ... >> >> Larry, with all due respect, if you substitute "ISO/IEC JTC1" >> or "IEEE" (at least in the computer and communications areas >> for both) in the above statements, they will still be true. >> The IETF is not particularly special in this regard. But the IETF seems to be singled out, in Larry's recent notes and elsewhere, as the one body that needs to treat these things differently. > I agree. There are very good reasons to insist in all fora > where standards for protocols and data formats are developed > that such standards must not be patent-encumbered. But I see no evidence, at least in the ISO-level correspondence that I follow, that they are being pursued with equal persistence anywhere else. I suspect that is because the Member Bodies refuse to keep taking the question up over and over again, and that, if the IETF had procedures similar or equivalent to theirs, we would not be hearing about it again on this list. >> To me, the question is simply one of whether trying to insist >> on an unencumbered regime (whether for technical, economic, or >> moral/ religious reasons) is important enough to justify >> rejecting, a priori, any encumbered technology. The IETF has >> decided, repeatedly, that the answer is "no" and "we want to >> look at these things on a case-by-case basis and evaluate the >> tradeoffs". While the part that follows the "no" differs, >> that is the same conclusion reached by ISO, IEC, IEEE, and >> others. > > However the economic importance of insisting that standards > must not be patent-encumbered is increasing. Therefore the > decisions of the past can not validly be accepted as strong > arguments against Larry's current initiative. First, no persuasive evidence has been produced on this list that this economic importance is, in fact, increasing. The economic importance may well be increasing for some categories of encumbrances, or for some categories of implementations but I don't believe a statement this broad can be justified. Second, while such increasing importance, were it to exist, would justify a review of the policies, it doesn't automatically lead to the conclusion that Larry (and presumably you) support. In addition, "the past" isn't a long time here. The IETF policies were not established a decade or two ago and never reviewed since: the question has been raised over and over again as to whether the IETF, or various WGs, want to review the policies, and the answer comes back "no". So, even if the economic importance has increased as you suggest, or other arguments for unencumbered software exist, how often do you think that requires review of the policies? Once every few years? Once a year? Once a month? Once every two weeks until you get your way and then never again? There comes a point beyond which the raising of this position is a DoS attack on the IETF's getting other work done. I also note that we can easily get onto a slippery slope here. Many companies view the GPL to be an encumbrance no less severe than the patent policies of other companies. Perhaps it is even more severe because encumbrances associated with patents that can be made to go away by the payment of money are less complicated to deal with (if one is willing to spent the money) than encumbrances under the GPS, which just don't go away. Would you recommend that IETF not permit any materials that might be encumbered under the GPL, etc.? >> If you want to pursue this further, I think it would be >> helpful if you started supplying arguments that we haven't >> heard, repeatedly, before. > > Do you have a list of the arguments that you have heard so > often already that you're not interested in hearing them again? I have seen nothing new in any of Larry's postings, or Simon's postings, or other postings supporting their general positions, in the last two months, so perhaps you could use that list as a starting point. best, john _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 22 18:04:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik57A-0003sh-NQ; Mon, 22 Oct 2007 17:47:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik578-0003mV-PQ for ietf@ietf.org; Mon, 22 Oct 2007 17:47:10 -0400 Received: from dhcp-18-188-10-61.dyn.mit.edu ([18.188.10.61] helo=carter-zimmerman.suchdamage.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik578-0005P1-BW for ietf@ietf.org; Mon, 22 Oct 2007 17:47:10 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3C1944A45; Mon, 22 Oct 2007 17:46:36 -0400 (EDT) From: Sam Hartman To: lrosen@rosenlaw.com References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <04fe01c814e7$47f33060$6401a8c0@LROSENTOSHIBA> Date: Mon, 22 Oct 2007 17:46:36 -0400 In-Reply-To: <04fe01c814e7$47f33060$6401a8c0@LROSENTOSHIBA> (Lawrence Rosen's message of "Mon, 22 Oct 2007 13:08:14 -0700") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org For what it's worth, I'd like to write in general support of re-evaluating several aspects of our patent policy. I 'm not quite writing in support of rechartering IPR at this time. First, I think they have critical copyright work to finish. Second, I think that we need to find a way to have the discussion in a productive forum. I'm not entirely sure a rechartered IPR working group would do that. Here are some examples of questions I think it might be desirable to consider: * Establishing a clear category for some sort of open-source-compatible licensing terms. We seem to think that royalty-free is good enough in our current policy, but that is demonstrably false. * Evaluating whether our IPR policies are adequate to actually provide enforcement when people violate them. What recourse do we have when people violate our policies; what recourse do users of our specs have? Is this sufficient for our needs? If we had different policies how much better would things be? * Phil's proposal has been shot down prematurely in my opinion. I agree that his current version would not fly. However I do think there are working groups that could make conclusions about their patent policies and for which doing so would have helped the effort a lot. I think sacred and dnsext are such working groups. I think you could get consensus in krb-wg that patented technology is problematic in our standards. However I'm not sure it would be useful as I don't think it would save much time. I think considering whether there are aspects of Phil's proposals it would be useful to adopt might be useful. Working through draft-housley-tls-authz-extns gave me a personal significant lack of confidence in our patent policies and whether they meet our goals and objectives. I also wonder whether our goals and objectives may have shifted somewhat since they were written. However I'm definitely uncomfortable with relying on our existing documents in any real dispute. In conclusion, I think Larry's proposed rechartering is an appropriate contribution to this list. While we may not ultimately decide to follow his course of action, I think it an appropriate contribution. I do not think he is attempting to DOS the process and believe he is participating in good faith. --Sam _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 22 19:31:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik6UR-00047C-Ee; Mon, 22 Oct 2007 19:15:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik6UP-00046o-7q; Mon, 22 Oct 2007 19:15:17 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik6UO-0003vz-SN; Mon, 22 Oct 2007 19:15:17 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l9MNFDOP005255; Mon, 22 Oct 2007 18:15:13 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 18:15:13 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 18:15:12 -0500 Message-ID: <471D2FA3.8060403@ericsson.com> Date: Mon, 22 Oct 2007 19:17:55 -0400 From: Suresh Krishnan User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: General Area Review Team , magnus.westerlund@ericsson.com, stewe@stewe.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2007 23:15:12.0805 (UTC) FILETIME=[65DAD550:01C81501] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: fluffy@cisco.com, ietf@ietf.org, avt-chairs@tools.ietf.org Subject: Gen-ART review of draft-ietf-avt-topologies-06.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I am the assigned Gen-ART reviewer for draft-ietf-avt-topologies-06.txt For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Summary: This draft is very well written, an enjoyable read and is almost ready for publication except for a minor comment. Minor ===== ASM is a term commonly used in multicast to mean Any Source Multicast (as opposed to Source Specific Multicast). The glossary of this draft redefines this to be "Asynchronous Multicast". Is this just a typo? Because from my reading of the draft all instances of this acronym actually use it in the context of Any Source Multicast. If it is just a typo it can be fixed with just an RFC-Editor note. Cheers Suresh _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 22 23:13:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik9nE-0006NA-B4; Mon, 22 Oct 2007 22:46:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik9n6-0006Md-R8 for ietf@ietf.org; Mon, 22 Oct 2007 22:46:48 -0400 Received: from mailout00.controlledmail.com ([72.81.252.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik9n6-0007uw-IC for ietf@ietf.org; Mon, 22 Oct 2007 22:46:48 -0400 Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id EBE845CC107 for ; Tue, 23 Oct 2007 02:45:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1193107522; bh=hsUrMVDvM60UxzA5AQaM/2mmCDeTSym8Yoy1cTy c6Xc=; h=Received:From:Organization:To:Subject:Date:User-Agent: References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-Disposition:Message-Id: X-AV-Checked; b=rhr0TZaix7lQISesOp7/YgZDs9N4qNdL7hdKLZ0d1pV/g3fhzM 3ivDiJK3rkRXQLDJcfMrXWnKAWp91X4rrvctpZ+Z+lVki0X7oouaKaawtj3NdBulAru 9uVMLOs550vkhKT8hyCoEWZeeEmj8ycd+L867/CYOQHM1qEEZaOoMs= Received: from [192.168.111.102] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by mailout00.controlledmail.com (Postfix) with ESMTP id C4AC85CC0C2 for ; Tue, 23 Oct 2007 02:45:21 +0000 (UTC) From: Scott Kitterman Organization: Kitterman Technical Services To: ietf@ietf.org Date: Mon, 22 Oct 2007 22:45:19 -0400 User-Agent: KMail/1.9.5 References: <20071022195723.4D9A22202DA@quill.bollow.ch> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710222245.19950.scott@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Monday 22 October 2007 16:27, John C Klensin wrote: > I also note that we can easily get onto a slippery slope here. > Many companies view the GPL to be an encumbrance no less severe > than the patent policies of other companies. Perhaps it is even > more severe because encumbrances associated with patents that > can be made to go away by the payment of money are less > complicated to deal with (if one is willing to spent the money) > than encumbrances under the GPS, which just don't go away. > Would you recommend that IETF not permit any materials that > might be encumbered under the GPL, etc.? That sounds reasonable to me. To promote global interoperability, standards need to be implementable throughout the internet ecosystem, both Free and Proprietary. Scott K _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 22 23:27:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkAK4-0002rB-Dk; Mon, 22 Oct 2007 23:20:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkAK0-0002kE-BU for ietf@ietf.org; Mon, 22 Oct 2007 23:20:49 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkAJz-0002BL-Vu for ietf@ietf.org; Mon, 22 Oct 2007 23:20:48 -0400 Received: from [192.168.0.41] (pool-70-21-206-158.nwrk.east.verizon.net [70.21.206.158]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l9N3KFcx001730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 22 Oct 2007 23:20:15 -0400 (EDT) In-Reply-To: <200710222245.19950.scott@kitterman.com> References: <20071022195723.4D9A22202DA@quill.bollow.ch> <200710222245.19950.scott@kitterman.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <24AF97BA-64CA-44CC-ABA1-618D733E4F43@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Mon, 22 Oct 2007 23:20:15 -0400 To: Scott Kitterman X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I'm confused by this part of the discussion. How can a standard be encumbered by GPL? As far as I know, GPL does not prevent anyone from implementing a standard without any restrictions or fees, just possibly from using somebody else's code under certain conditions. I don't think that anybody is proposing that all implementations should be "free", in whatever sense of the word, just that free implementations can exist. Thus, I consider this somewhat of a diversion. Henning On Oct 22, 2007, at 10:45 PM, Scott Kitterman wrote: > On Monday 22 October 2007 16:27, John C Klensin wrote: > >> I also note that we can easily get onto a slippery slope here. >> Many companies view the GPL to be an encumbrance no less severe >> than the patent policies of other companies. Perhaps it is even >> more severe because encumbrances associated with patents that >> can be made to go away by the payment of money are less >> complicated to deal with (if one is willing to spent the money) >> than encumbrances under the GPS, which just don't go away. >> Would you recommend that IETF not permit any materials that >> might be encumbered under the GPL, etc.? > > That sounds reasonable to me. To promote global interoperability, > standards > need to be implementable throughout the internet ecosystem, both > Free and > Proprietary. > > Scott K > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 00:09:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkAoB-0002TB-Rd; Mon, 22 Oct 2007 23:51:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkAoA-0002Am-1p for ietf@ietf.org; Mon, 22 Oct 2007 23:51:58 -0400 Received: from nz-out-0506.google.com ([64.233.162.234]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkAo3-0004Gs-JE for ietf@ietf.org; Mon, 22 Oct 2007 23:51:51 -0400 Received: by nz-out-0506.google.com with SMTP id n1so603002nzf for ; Mon, 22 Oct 2007 20:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=DYTln3j+PfuCW5l49dHlLTlw8IF9uLAqk6ULAwKbbM4=; b=GjCjf7+7hnfhMHj3zHRGNOek87ls1vFHJ9nJzgtwEcJis95L3YCa7aJVkMaXVhht47twWEbYwSFihi/rJlWHhgJjTNhzjjBKwLVRvPf6X2oXt/uwAZnojkbhsmQhxWNVkRbkGYNTL9T94zpiHqO/V4aPJirfvg2748pYa8WlOis= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=isy/TjnYxz58bfnKhUs0nikeIcIo6/66m+Q+O3cDpAlR7/l9OHsRJI7+V4F6xWfnD1LqfJlKvdFHpZZJWrrHjRqpZz4ZNANkg/WML5HlypqSBlTBchDPZZ1zvKLaeyBzJm8CKeJCnshJ12CBIe57biQIFl+SAhyHQDSNfvU2H7Q= Received: by 10.114.190.6 with SMTP id n6mr566590waf.1193111510749; Mon, 22 Oct 2007 20:51:50 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id m40sm10504923waf.2007.10.22.20.51.48 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Oct 2007 20:51:49 -0700 (PDT) Message-ID: <471D6FD3.2020800@gmail.com> Date: Tue, 23 Oct 2007 16:51:47 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Henning Schulzrinne References: <20071022195723.4D9A22202DA@quill.bollow.ch> <200710222245.19950.scott@kitterman.com> <24AF97BA-64CA-44CC-ABA1-618D733E4F43@cs.columbia.edu> In-Reply-To: <24AF97BA-64CA-44CC-ABA1-618D733E4F43@cs.columbia.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Scott Kitterman , ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-23 16:20, Henning Schulzrinne wrote: > I'm confused by this part of the discussion. How can a standard be > encumbered by GPL? As far as I know, GPL does not prevent anyone from > implementing a standard without any restrictions or fees, just possibly > from using somebody else's code under certain conditions. There's certainly a tricky point if code embedded in a standard is explicitly subject to the GPL; that makes it effectively impossible for a commercial implementor to use even fragments of that code in a proprietary way. > I don't think > that anybody is proposing that all implementations should be "free", in > whatever sense of the word, just that free implementations can exist. > > Thus, I consider this somewhat of a diversion. Well, there's an inverse claim that some of the IETF's current rules make it impossible to use material extracted from RFCs in open source under certain OS licenses. But I agree that these copyright issues are distinct from patent issues. The latter concern whether an implementor can put code under a given OS license at all, depending on the exact form of patent licence available. Not all OS licenses have this problem, however. Brian > > Henning > > On Oct 22, 2007, at 10:45 PM, Scott Kitterman wrote: > >> On Monday 22 October 2007 16:27, John C Klensin wrote: >> >>> I also note that we can easily get onto a slippery slope here. >>> Many companies view the GPL to be an encumbrance no less severe >>> than the patent policies of other companies. Perhaps it is even >>> more severe because encumbrances associated with patents that >>> can be made to go away by the payment of money are less >>> complicated to deal with (if one is willing to spent the money) >>> than encumbrances under the GPS, which just don't go away. >>> Would you recommend that IETF not permit any materials that >>> might be encumbered under the GPL, etc.? >> >> That sounds reasonable to me. To promote global interoperability, >> standards >> need to be implementable throughout the internet ecosystem, both Free and >> Proprietary. >> >> Scott K >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www1.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 01:51:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkCNN-0000vz-Tc; Tue, 23 Oct 2007 01:32:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkCNM-0000uZ-Dz; Tue, 23 Oct 2007 01:32:24 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkCNL-0001mH-KP; Tue, 23 Oct 2007 01:32:24 -0400 Received: from E03MVC4-UKBR.domain1.systemhost.net ([193.113.197.116]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 06:31:51 +0100 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" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Oct 2007 06:34:28 +0100 Message-ID: In-Reply-To: <471D193F.8050302@ca.afilias.info> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: An example of what is wrong with the IETF's IPv6 documentation Thread-Index: AcgU9I8f98oH3BgkShmLoJPNpLjM0gAQHsrA References: <454810F09B5AA04E9D78D13A5C39028A0272FA72@nyrofcs2ke2k01.corp.pvt><20071022165908.GB89375@ussenterprise.ufp.org> <471D193F.8050302@ca.afilias.info> From: To: , X-OriginalArrivalTime: 23 Oct 2007 05:31:51.0832 (UTC) FILETIME=[03ECB180:01C81536] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: Subject: An example of what is wrong with the IETF's IPv6 documentation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org The following thread from ARIN's Public Policy Mailing List is an example of what is wrong with the IETF's documentation of IPv6. People are struggling to understand just how IPv6 works, not at the implementation level of detail, but at a higher level.=20 What is mandatory, what is optional? What are the basic principles, what is the fundamental architecture? Some people argue that IPv6 is merely IPv4 with more bits, therefore all the rules and constraints of IPv4 must necessarily be applied. There is no IETF document that provides the right kind of high-level view of IPv6, and no document that provides guidelines for RIRs. In the absence of such guidance, it appears as though people who plan to alloocate /120's to customers are right, and Brian Dickson is the authoritative voice of the IETF who understands IPv6 most clearly. Most people who make decisions about addressing plans in the RIRs or in ISPs, do not have the time to wade through dozens of RFCs trying to figure out what is NOT DEPRECATED and what is the IPv6 STANDARD. I believe that the 6MAN group should add to its charter two documents: IPv6 guidelines for RIRs and IPv6 Overview for ISPs. > -----Original Message----- > From: ppml-bounces@arin.net [mailto:ppml-bounces@arin.net] On=20 > Behalf Of Brian Dickson > Sent: 22 October 2007 22:42 > To: ARIN PPML > Subject: Re: [ppml] IPv6 assignment - proposal for change to nrpm >=20 > Leo Bicknell wrote: > > In a message written on Mon, Oct 22, 2007 at 09:31:36AM=20 > -0400, Azinger, Marla wrote: > > =20 > >> 3177 is a recommendation from 2001 and not a standar of any kind. > >> =20 > > > > I'm afraid many people are not looking at the right RFC's and/or=20 > > considering what all needs to be changed if the /64=20 > boundary is to be=20 > > updated. I'm fairly sure this is not an exhaustive list, /64 is=20 > > referenced in many locations in different IPv6 RFC's, many of which=20 > > are standards track. > > > > * http://www.faqs.org/rfcs/rfc2373.html > > "IP Version 6 Addressing Architecture" > > Status: Standards Track > > > > Section 2.5.1: "Interface IDs are required to be 64 bits long..." > > > > Section 2.5.7: Aggregatable Global Unicast Addresses > > > > Section 2.5.8: Local-Use IPv6 Unicast Addresses > > > > =20 > RFC 2373 was obsoleted by 3531 which was obsoleted by 4291. > 2.5.8 is gone, but AGUA is still roughly the same (all but=20 > 000 require use of EUI-64 modified), and ditto 2.5.1 > > * http://www.faqs.org/rfcs/rfc2374.html > > "An IPv6 Aggregatable Global Unicast Address Format" > > Status: Standards Track > > > > Section 3.1 makes it clear the lower 64 bits are an interface > > identifier for > > > > I also point out section 3.4 makes a recomendation we=20 > continue to use > > a slow start method: > > > > It is recommended that > > organizations assigning NLA address space use "slow=20 > start" allocation > > procedures similar to [RFC2050]. > > > > =20 > 2374 was obsoleted by 3587. > > * http://www.faqs.org/rfcs/rfc2450.html > > "Proposed TLA and NLA Assignment Rule" > > Status: Informational > > > > Section 3: IPv6 Aggregatable Global Unicast Address Format > > > > =20 > This bit was itself in RFC 2374, which was obsoleted by RFC 3587. > > * http://www.faqs.org/rfcs/rfc2460.html > > "Internet Protocol, Version 6 (IPv6) Specification" > > Status: Standards Track > > > > Section 3: Specifically referrs to 2373 (ADDRARCH) > > =20 > 4291 obsoletes 3531 which obsoleted 2373. >=20 > (I don't know why 2460 hasn't been updated with the new references...) > > * http://www.rfc-editor.org/rfc/rfc3177.txt > > "IAB/IESG Recommendations on IPv6 Address Allocations to Sites" > > Status: Informational > > > > Section 3: Recomendations > > =20 > This was informational only, from 2001, and IMHO no longer as=20 > relevant as it once was. >=20 > So, by my count, that is 4291 and 3587. >=20 > My IETF draft also lists 2464 (Ethernet), 4941 (privacy),=20 > and 4862 (autoconfiguration). > Most other IPv6 RFCs inherit from those few, and mostly the=20 > choice is rather axiomatic. > Two small changes, basically, in a backward-compatible=20 > manner, is meant to be as minimally-disruptive as is possible. > (Think surgery to remove a burst appendix or inflamed tonsils.) >=20 > Anyone interested can see the draft at: > http://www.ietf.org/internet-drafts/draft-dickson-v6man-new-au > toconf-00.txt >=20 > My draft even includes the necessary patch for Linux, about=20 > 17 lines in total, mostly the result of the necesssary line=20 > length provisions for an RFC. (It was 10 lines > originally.) >=20 > Brian > _______________________________________________ > PPML > You are receiving this message because you are subscribed to=20 > the ARIN Public Policy Mailing List (PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact=20 > the ARIN Member Services Help Desk at info@arin.net if you=20 > experience any issues. I don't think it is necessary to discuss the quoted text, just be aware of how hard it is to pin down how IPv6 works and find authoritative IETF documents to back up an assertion. --Michael Dillon=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 02:16:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkCv9-0003jn-6A; Tue, 23 Oct 2007 02:07:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkCv4-0003gj-I5 for ietf@ietf.org; Tue, 23 Oct 2007 02:07:14 -0400 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkCv4-0004il-8R for ietf@ietf.org; Tue, 23 Oct 2007 02:07:14 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l9N66HVG021789; Tue, 23 Oct 2007 02:06:25 -0400 (EDT) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l9N665kR001222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Oct 2007 02:06:06 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id l9N6650m006728; Tue, 23 Oct 2007 02:06:05 -0400 (EDT) To: Bob Briscoe References: <5.2.1.1.2.20071019165431.018d18c8@pop3.jungle.bt.co.uk> From: Tom Yu Date: Tue, 23 Oct 2007 02:06:05 -0400 In-Reply-To: <5.2.1.1.2.20071019165431.018d18c8@pop3.jungle.bt.co.uk> (Bob Briscoe's message of "Fri, 19 Oct 2007 17:41:46 +0100") Message-ID: Lines: 20 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: secdir@mit.edu, ietf@ietf.org, bsd@cisco.com, tsvwg-chairs@tools.ietf.org Subject: Re: secdir review of draft-ietf-tsvwg-ecn-mpls-02.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>>>> "Bob" == Bob Briscoe writes: Bob> Tom, Bob> You're analysis of the impact on the ECN nonce is accurate. Below is Bob> our reasoning for not including the ECN nonce capability in this Bob> proposal... [...] Thanks for the detailed rationale of your decision to not include the ECN nonce. Given that the question of detecting disruption of end-to-end ECN signaling within an MPLS domain occurred to me from the mention of RFC3540 in the Security Considerations, other readers of this document may have similar questions. I suggest that you add a sentence or two to the Security Considerations summarizing your decision to exclude the ECN nonce capability from this particular proposal. However, I will not object to the passage of this document if you choose not to include such a summary. ---Tom _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 02:17:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkCuo-0003PM-VM; Tue, 23 Oct 2007 02:06:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkCul-0003O2-9E for ietf@ietf.org; Tue, 23 Oct 2007 02:06:55 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkCuk-0004hh-U6 for ietf@ietf.org; Tue, 23 Oct 2007 02:06:55 -0400 Received: from [193.0.9.233] by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IkCue-0001ae-B3; Tue, 23 Oct 2007 06:06:48 +0000 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <195ACCCA-CB33-4B16-A536-61BF46E258D5@ca.afilias.info> Content-Transfer-Encoding: 7bit From: Joe Abley Date: Tue, 23 Oct 2007 08:06:43 +0200 To: IETF discussion list X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Ole Jacobsen , IAB IAB Subject: Re: Seeking ICANN Nomcom 2008 candidate X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Sun, 30 Sep 2007 15:59:28 +0200, Olaf Kolkman wrote: > On behalf of the IETF, the IAB has to deliver one of the 17 voting > members to the ICANN Nomcom for 2008. > > Now that the selections from the 2007 ICANN Nomcom have been > announced [1] we would like to ask the community for volunteers to > serve on the 2008 ICANN Nomcom. The IAB invites volunteers to reply > within 10 days, as that allows participation in the first meeting > in early November (see below). If you are interested, please send > us a short e-mail with your motivation and information concerning > your familiarity with the IETF and ICANN. The IAB has selected Ole Jacobsen as the IETF member of the 2008 ICANN Nomcom. We would like to thank all those who volunteered. For the IAB, Joe Abley (IAB execd) _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 03:26:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkDzy-0007oo-3L; Tue, 23 Oct 2007 03:16:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkDzu-0007e9-R8; Tue, 23 Oct 2007 03:16:18 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkDzu-0000sk-A7; Tue, 23 Oct 2007 03:16:18 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 553BC203EE; Tue, 23 Oct 2007 09:16:17 +0200 (CEST) X-AuditID: c1b4fb3c-b0e80bb0000007e1-7a-471d9fc1d343 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3930E20695; Tue, 23 Oct 2007 09:16:17 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 09:16:17 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 09:16:17 +0200 Message-ID: <471D9FC0.8070605@ericsson.com> Date: Tue, 23 Oct 2007 09:16:16 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Suresh Krishnan References: <471D2FA3.8060403@ericsson.com> In-Reply-To: <471D2FA3.8060403@ericsson.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Oct 2007 07:16:17.0157 (UTC) FILETIME=[9A596B50:01C81544] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: fluffy@cisco.com, General Area Review Team , ietf@ietf.org, avt-chairs@tools.ietf.org Subject: Re: Gen-ART review of draft-ietf-avt-topologies-06.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Yes, it is a typo. Magnus Suresh Krishnan skrev: > I am the assigned Gen-ART reviewer for > draft-ietf-avt-topologies-06.txt > > For background on Gen-ART, please see the FAQ at > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Summary: This draft is very well written, an enjoyable read and is > almost ready for publication except for a minor comment. > > Minor > ===== > > ASM is a term commonly used in multicast to mean Any Source Multicast > (as opposed to Source Specific Multicast). The glossary of this draft > redefines this to be "Asynchronous Multicast". Is this just a typo? > Because from my reading of the draft all instances of this acronym > actually use it in the context of Any Source Multicast. If it is just a > typo it can be fixed with just an RFC-Editor note. > > Cheers > Suresh > > -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 03:26:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkDxG-00025o-DC; Tue, 23 Oct 2007 03:13:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkDx9-0001gg-5E; Tue, 23 Oct 2007 03:13:27 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkDww-0000kL-EG; Tue, 23 Oct 2007 03:13:14 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l9N6iJVG052085; Mon, 22 Oct 2007 23:44:30 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Tue, 23 Oct 2007 09:13:02 +0200 X-PGP-Universal: processed; by terminus.local on Tue, 23 Oct 2007 09:13:02 +0200 In-Reply-To: References: <454810F09B5AA04E9D78D13A5C39028A0272FA72@nyrofcs2ke2k01.corp.pvt><20071022165908.GB89375@ussenterprise.ufp.org> <471D193F.8050302@ca.afilias.info> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <83DF27F6-9407-4359-8BF1-8EAD109FD0F3@virtualized.org> From: David Conrad Date: Tue, 23 Oct 2007 09:12:49 +0200 To: "" X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ipv6@ietf.org, ietf@ietf.org Subject: Re: An example of what is wrong with the IETF's IPv6 documentation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Michael, On Oct 23, 2007, at 7:34 AM, wrote: > The following thread from ARIN's Public Policy Mailing List is an > example of what is wrong with the IETF's documentation of IPv6. I look forward to seeing your draft. Regards, -drc _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 04:07:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkEdx-0006KU-7Y; Tue, 23 Oct 2007 03:57:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkEdv-0006Bj-3a; Tue, 23 Oct 2007 03:57:39 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkEdr-0002pH-Lw; Tue, 23 Oct 2007 03:57:35 -0400 Received: from E03MVC4-UKBR.domain1.systemhost.net ([193.113.197.116]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 08:57:32 +0100 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" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Oct 2007 09:00:09 +0100 Message-ID: In-Reply-To: <83DF27F6-9407-4359-8BF1-8EAD109FD0F3@virtualized.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: An example of what is wrong with the IETF's IPv6 documentation Thread-Index: AcgVRCqlKZpuqzrFQMaPNkZrhhJmPwABkyFw References: <454810F09B5AA04E9D78D13A5C39028A0272FA72@nyrofcs2ke2k01.corp.pvt><20071022165908.GB89375@ussenterprise.ufp.org> <471D193F.8050302@ca.afilias.info> <83DF27F6-9407-4359-8BF1-8EAD109FD0F3@virtualized.org> From: To: , X-OriginalArrivalTime: 23 Oct 2007 07:57:32.0920 (UTC) FILETIME=[5E04DF80:01C8154A] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: RE: An example of what is wrong with the IETF's IPv6 documentation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > > The following thread from ARIN's Public Policy Mailing List is an=20 > > example of what is wrong with the IETF's documentation of IPv6. >=20 > I look forward to seeing your draft. Unfortunately, I was not involved in the creation of IPv6, nor did I follow it as RFCs were released and then deprecated, so I don't fully understand it myself. This is a piece of work that needs to be taken on by some of the people who were immersed in the creation of IPv6. --Michael Dillon _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 04:21:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkEtK-00010K-9v; Tue, 23 Oct 2007 04:13:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkEtI-0000xq-EV for ietf@ietf.org; Tue, 23 Oct 2007 04:13:32 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkEtA-0002sm-7K for ietf@ietf.org; Tue, 23 Oct 2007 04:13:30 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IkEso-0001vu-5m for ietf@ietf.org; Tue, 23 Oct 2007 08:13:02 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Oct 2007 08:13:02 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Oct 2007 08:13:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: "Frank Ellermann" Date: Tue, 23 Oct 2007 10:10:11 +0200 Lines: 21 Message-ID: References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov><87y7e08phu.fsf@mocca.josefsson.org><2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com><4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local><03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA><877iljv6ed.fsf@mocca.josefsson.org><042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA><2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com><471A5668.8060505@gmail.com><048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA><04fe01c814e7$47f33060$6401a8c0@LROSENTOSHIBA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ipr-wg@ietf.org Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Sam Hartman wrote on the general list: > I'd like to write in general support of re-evaluating several aspects > of our patent policy. I'm not quite writing in support of = rechartering > IPR at this time. First, I think they have critical copyright work to > finish. +1 > Second, I think that we need to find a way to have the discussion in > a productive forum. I'm not entirely sure a rechartered IPR working > group would do that. If Simon supports it the IPR WG could adopt his draft . Cc: to the IPR list in support of John's unscheduled process experiment with "a DoS attack on the IETF's getting other work done." Add smiley. =20 Frank _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 05:00:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkFXb-0000VW-PS; Tue, 23 Oct 2007 04:55:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkFXZ-0000SN-Ir; Tue, 23 Oct 2007 04:55:09 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkFXT-0004it-99; Tue, 23 Oct 2007 04:55:09 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id BF13F240822; Tue, 23 Oct 2007 09:54:43 +0200 (CEST) Received: by horcrux (Postfix, from userid 1000) id AEB17157552; Tue, 23 Oct 2007 08:50:11 +0000 (GMT) Date: Tue, 23 Oct 2007 08:50:11 +0000 From: Stephane Bortzmeyer To: michael.dillon@bt.com Message-ID: <20071023085011.GA20612@laperouse.bortzmeyer.org> References: <471D193F.8050302@ca.afilias.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 7.04 (feisty) User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipv6@ietf.org, ietf@ietf.org Subject: Re: An example of what is wrong with the IETF's IPv6 documentation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Tue, Oct 23, 2007 at 06:34:28AM +0100, michael.dillon@bt.com wrote a message of 143 lines which said: > Most people who make decisions about addressing plans in the RIRs or > in ISPs, do not have the time to wade through dozens of RFCs trying > to figure out what is NOT DEPRECATED and what is the IPv6 STANDARD. > > I believe that the 6MAN group should add to its charter two > documents: IPv6 guidelines for RIRs and IPv6 Overview for ISPs. Do not forget to do the same for the DNS, which is in an even worse shape in that respect (lots of RFC, some partially deprecated, the two foundation RFC being extremely old-style, etc). _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 05:00:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkFXC-0008FJ-0d; Tue, 23 Oct 2007 04:54:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkFVJ-00066S-W2; Tue, 23 Oct 2007 04:52:50 -0400 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkFVJ-00057p-H6; Tue, 23 Oct 2007 04:52:49 -0400 DKIM-Signature: a=rsa-sha1; c=nowsp; d=consulintel.es; s=MDaemon; t=1193132981; x=1193737781; i=jordi.palet@consulintel.es; q=dns; h=DomainKey-Signature:Received:User-Agent:Date:Subject:From:To: Message-ID:Thread-Topic:Thread-Index:In-Reply-To:Mime-version: Content-type:Content-transfer-encoding:Reply-To; b=VYGdpOEd0iEq+W HKUOjXumvzrnB4132z1LcBsptW74G0AiFwUF8+sXBOVTZ/5P63oU5mUQzzi5bqXR MPKxP1I0VqrizhK2TJYB6hYlkF4vjBEucIQqWuUzk5Z1PmqEWrXAyhjYq8ewpMUN 4saUKdVpwT/0YERrVFHX1FlZ0u+aU= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=VXUBSXT5PsJs/tudty2TJR1pBRETWHib/NuHUW6CsYhwCNOKp9dL3YMaWk4AN1mJORNL+Of5Gu/XJjLdSJXTRJYAdQd0yQh61wmNve5YDezvjrJcEX5V2mSYnCDSQHgIC18WGD1ck4RYqcZxmn1tIpYQTuAsOTuCjP8aQBNIRrg=; Received: from [193.0.9.80] by consulintel.es (MDaemon.PRO.v8.1.5.R) with ESMTP id md50002700229.msg; Tue, 23 Oct 2007 10:49:38 +0200 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 23 Oct 2007 10:52:36 +0200 From: JORDI PALET MARTINEZ To: , Message-ID: Thread-Topic: An example of what is wrong with the IETF's IPv6 documentation Thread-Index: AcgVRCqlKZpuqzrFQMaPNkZrhhJmPwABkyFwAAHl6eE= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:071023:ietf@ietf.org::u5dOSnb4pEWXUYvE:00002c+Z X-MDRemoteIP: 193.0.9.80 X-Return-Path: jordi.palet@consulintel.es X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es X-Spam-Status: No, score=-4.7 required=4.5 tests=BAYES_00,MIME_QP_LONG_LINE autolearn=ham version=3.0.4 X-Spam-Level: X-Spam-Processed: consulintel.es, Tue, 23 Oct 2007 10:49:40 +0200 X-MDAV-Processed: consulintel.es, Tue, 23 Oct 2007 10:49:41 +0200 X-Spam-Score: 1.8 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Subject: Re: An example of what is wrong with the IETF's IPv6 documentation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org As IETF Sergeant-at-arms, I will suggest that this topic is specific to 6MAN and should be further discussed there. Thanks ! Regards, Jordi > De: > Responder a: > Fecha: Tue, 23 Oct 2007 09:00:09 +0100 > Para: , > Conversaci=F3n: An example of what is wrong with the IETF's IPv6 documentation > Asunto: RE: An example of what is wrong with the IETF's IPv6 documentation >=20 >>> The following thread from ARIN's Public Policy Mailing List is an >>> example of what is wrong with the IETF's documentation of IPv6. >>=20 >> I look forward to seeing your draft. >=20 > Unfortunately, I was not involved in the creation of IPv6, nor did I > follow it as RFCs were released and then deprecated, so I don't fully > understand it myself. This is a piece of work that needs to be taken on > by some of the people who were immersed in the creation of IPv6. >=20 > --Michael Dillon >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 07:12:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkHOw-0006WA-M4; Tue, 23 Oct 2007 06:54:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkHOu-0006P6-B8 for ietf@ietf.org; Tue, 23 Oct 2007 06:54:20 -0400 Received: from tarsus.bollow.ch ([82.195.230.222]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkHOg-0001JV-SO for ietf@ietf.org; Tue, 23 Oct 2007 06:54:15 -0400 Received: from tarsus.bollow.ch (localhost [127.0.0.1]) by tarsus.bollow.ch (Postfix) with ESMTP id 98D3FB2821E for ; Tue, 23 Oct 2007 13:29:44 +0200 (CEST) Authentication-Results: tarsus.bollow.ch from=nb@bollow.ch; domainkey=neutral (no signature; no policy for bollow.ch) Received: from quill.bollow.ch (10-9.0-85.cust.bluewin.ch [85.0.9.10]) by tarsus.bollow.ch (Postfix) with ESMTP for ; Tue, 23 Oct 2007 13:29:44 +0200 (CEST) Received: by quill.bollow.ch (Postfix, from userid 1000) id 8D9AC2202DA; Tue, 23 Oct 2007 12:56:51 +0200 (CEST) From: Norbert Bollow Organization: Bollow Software Economics Research MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=iso-8859-1 To: ietf@ietf.org In-reply-to: (message from John C Klensin on Mon, 22 Oct 2007 16:27:20 -0400) References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> Message-Id: <20071023105651.8D9AC2202DA@quill.bollow.ch> Date: Tue, 23 Oct 2007 12:56:51 +0200 (CEST) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org John C Klensin wrote: > --On Monday, 22 October, 2007 21:57 +0200 Norbert Bollow > wrote: > > John C Klensin wrote: > >> Larry, with all due respect, if you substitute "ISO/IEC JTC1" > >> or "IEEE" (at least in the computer and communications areas > >> for both) in the above statements, they will still be true. > >> The IETF is not particularly special in this regard. >=20 > But the IETF seems to be singled out, in Larry's recent notes > and elsewhere, as the one body that needs to treat these things > differently. I can't speak for Larry, but maybe the reason for his focusing on IETF is our culture of agreeing on how things should be done and then (generally) acting accordingly? By contrast e.g. ISO/IEC JTC1 is not following its own policy on patents in any consistent way. > > I agree. There are very good reasons to insist in all fora > > where standards for protocols and data formats are developed > > that such standards must not be patent-encumbered. >=20 > But I see no evidence, at least in the ISO-level correspondence > that I follow, that they are being pursued with equal > persistence anywhere else. I suspect that is because the > Member Bodies refuse to keep taking the question up over and > over again I've spoken not too long ago with the official of the Swiss Association for Standardization (our country's Member Body of ISO) who is responsible for that kind of thing, and he said that when there's a clear example of a patent-encombered "standard" of some significance that gets approved at the ISO/IEC JTC1 level, he's willing to have Switzerland initiate an appeal against that decision on the basis of patented "standards" being harmful to international commerce. He expressed confidence that we would win that appeal. =20 > > However the economic importance of insisting that standards > > must not be patent-encumbered is increasing. Therefore the > > decisions of the past can not validly be accepted as strong > > arguments against Larry's current initiative. >=20 > First, no persuasive evidence has been produced on this list > that this economic importance is, in fact, increasing. Ok, I'll write up an argument in support of my above assertion. > I also note that we can easily get onto a slippery slope here. > Many companies view the GPL to be an encumbrance no less severe > than the patent policies of other companies. Perhaps it is even > more severe because encumbrances associated with patents that > can be made to go away by the payment of money are less > complicated to deal with (if one is willing to spent the money) > than encumbrances under the GPS, which just don't go away. > Would you recommend that IETF not permit any materials that > might be encumbered under the GPL, etc.? I would recommend that in order to be considered acceptable, implementation in GPL'd free software as well as implementation in proprietary closed-source software must both be allowed by the licensing terms of any patents. Greetings, Norbert. --=20 Norbert Bollow http://Norbert.ch President of the Swiss Internet User Group SIUG http://SIUG.ch Working on establishing a non-corrupt and truly /open/ international standards organization http://OpenISO.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 07:12:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkHaI-0005P6-P3; Tue, 23 Oct 2007 07:06:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkHaG-0005Nx-9D; Tue, 23 Oct 2007 07:06:04 -0400 Received: from yxa.extundo.com ([83.241.177.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkHa4-0001oK-J1; Tue, 23 Oct 2007 07:05:59 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l9NB5e86004484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2007 13:05:40 +0200 From: Simon Josefsson To: "Frank Ellermann" References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <04fe01c814e7$47f33060$6401a8c0@LROSENTOSHIBA> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071023:ietf@ietf.org::GG8wVuMDKBc6KztW:7AkU X-Hashcash: 1:22:071023:ipr-wg@ietf.org::OOq8q71tQ1Jun8qB:CaIm X-Hashcash: 1:22:071023:nobody@xyzzy.claranet.de::Sl8Y1BuifyRDsBYD:DC44 Date: Tue, 23 Oct 2007 13:05:39 +0200 In-Reply-To: (Frank Ellermann's message of "Tue, 23 Oct 2007 10:10:11 +0200") Message-ID: <87ejfm2irg.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: ietf@ietf.org, ipr-wg@ietf.org Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org "Frank Ellermann" writes: > . I noticed that the 00 draft would expire in two days, and submitted a 01 with only minor changes. /Simon _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 07:12:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkHaI-0005P6-P3; Tue, 23 Oct 2007 07:06:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkHaG-0005Nx-9D; Tue, 23 Oct 2007 07:06:04 -0400 Received: from yxa.extundo.com ([83.241.177.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkHa4-0001oK-J1; Tue, 23 Oct 2007 07:05:59 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l9NB5e86004484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2007 13:05:40 +0200 From: Simon Josefsson To: "Frank Ellermann" References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <04fe01c814e7$47f33060$6401a8c0@LROSENTOSHIBA> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071023:ietf@ietf.org::GG8wVuMDKBc6KztW:7AkU X-Hashcash: 1:22:071023:ipr-wg@ietf.org::OOq8q71tQ1Jun8qB:CaIm X-Hashcash: 1:22:071023:nobody@xyzzy.claranet.de::Sl8Y1BuifyRDsBYD:DC44 Date: Tue, 23 Oct 2007 13:05:39 +0200 In-Reply-To: (Frank Ellermann's message of "Tue, 23 Oct 2007 10:10:11 +0200") Message-ID: <87ejfm2irg.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: ietf@ietf.org, ipr-wg@ietf.org Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org "Frank Ellermann" writes: > . I noticed that the 00 draft would expire in two days, and submitted a 01 with only minor changes. /Simon _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 07:30:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkHom-0000mf-2t; Tue, 23 Oct 2007 07:21:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkHok-0000jH-K3 for ietf@ietf.org; Tue, 23 Oct 2007 07:21:02 -0400 Received: from yxa.extundo.com ([83.241.177.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkHok-0001vB-3Q for ietf@ietf.org; Tue, 23 Oct 2007 07:21:02 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l9NBKumA008675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2007 13:20:57 +0200 From: Simon Josefsson To: Norbert Bollow References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071023:nb@bollow.ch::lcv+L4mxaVhLqgcH:Ll5J X-Hashcash: 1:22:071023:ietf@ietf.org::nvug6KkWtwk4Uajb:NpbH Date: Tue, 23 Oct 2007 13:20:56 +0200 In-Reply-To: <20071023105651.8D9AC2202DA@quill.bollow.ch> (Norbert Bollow's message of "Tue, 23 Oct 2007 12:56:51 +0200 (CEST)") Message-ID: <87abqa2i1z.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Norbert Bollow writes: >> I also note that we can easily get onto a slippery slope here. >> Many companies view the GPL to be an encumbrance no less severe >> than the patent policies of other companies. Perhaps it is even >> more severe because encumbrances associated with patents that >> can be made to go away by the payment of money are less >> complicated to deal with (if one is willing to spent the money) >> than encumbrances under the GPS, which just don't go away. >> Would you recommend that IETF not permit any materials that >> might be encumbered under the GPL, etc.? > > I would recommend that in order to be considered acceptable, > implementation in GPL'd free software as well as implementation in > proprietary closed-source software must both be allowed by the > licensing terms of any patents. I think that is a good recommendation, and I support it. I would even consider a requirement that in order to move beyond Proposed Standard, a protocol needs to have a free implementation available. /Simon _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 08:56:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJCY-0002Ku-Nc; Tue, 23 Oct 2007 08:49:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJCX-0002EA-3J for ietf@ietf.org; Tue, 23 Oct 2007 08:49:41 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkJCR-0004oB-MZ for ietf@ietf.org; Tue, 23 Oct 2007 08:49:36 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 23 Oct 2007 05:49:34 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9NCnY6B012580; Tue, 23 Oct 2007 05:49:34 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l9NCnJbf026228; Tue, 23 Oct 2007 12:49:34 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 08:49:26 -0400 Received: from swbmbp.local.employees.org ([10.86.241.240]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 08:49:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18205.60884.253199.882840@swbmbp.local> Date: Tue, 23 Oct 2007 08:49:24 -0400 From: Scott Brim To: Sam Hartman In-Reply-To: References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <04fe01c814e7$47f33060$6401a8c0@LROSENTOSHIBA> X-Mailer: VM 8.0.3-495 under Emacs 22.1.1 (i386-apple-darwin8.10.1) X-OriginalArrivalTime: 23 Oct 2007 12:49:25.0538 (UTC) FILETIME=[245A5020:01C81573] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15500.002 X-TM-AS-Result: No--4.195400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Authentication-Results: sj-dkim-3; header.From=swb@employees.org; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 22 Oct 2007 at 17:46 -0400, Sam Hartman allegedly wrote: > * Phil's proposal has been shot down prematurely in my opinion. I > agree that his current version would not fly. However I do think > there are working groups that could make conclusions about their > patent policies and for which doing so would have helped the > effort a lot. Working Groups have the freedom to do that if they wish. I don't want a simplistic edict from on high that all working groups must do so. Interactions between issues, technical and otherwise, are way too varied and potentially complicated for such shallow rule-making. > Working through draft-housley-tls-authz-extns gave me a personal > significant lack of confidence in our patent policies and whether > they meet our goals and objectives. I also wonder whether our goals > and objectives may have shifted somewhat since they were written. > However I'm definitely uncomfortable with relying on our existing > documents in any real dispute. I think the problem is that because we have a wide range of opinion and desired outcome, we cannot create simple rules, which means the difficult cases take a lot of discussion. I think that's important to preserve, in order to support the possibility of new outcomes. swb _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 08:56:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJFy-0000vB-L4; Tue, 23 Oct 2007 08:53:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJFw-0000uf-KO; Tue, 23 Oct 2007 08:53:12 -0400 Received: from machshav.com ([198.180.150.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkJFp-00069y-SW; Tue, 23 Oct 2007 08:53:12 -0400 Received: by machshav.com (Postfix, from userid 512) id AD428627; Tue, 23 Oct 2007 12:52:48 +0000 (GMT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0964F177; Tue, 23 Oct 2007 12:52:48 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 2634576608F; Tue, 23 Oct 2007 08:52:47 -0400 (EDT) Date: Tue, 23 Oct 2007 12:52:46 +0000 From: "Steven M. Bellovin" To: Theodore Tso Message-ID: <20071023125246.2b59cbb6@cs.columbia.edu> In-Reply-To: <20071023124206.GI27132@thunk.org> References: <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <04fe01c814e7$47f33060$6401a8c0@LROSENTOSHIBA> <87ejfm2irg.fsf@mocca.josefsson.org> <20071023124206.GI27132@thunk.org> Organization: Columbia University X-Mailer: Claws Mail 3.0.1 (GTK+ 2.10.14; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Frank Ellermann , Simon Josefsson , ietf@ietf.org, ipr-wg@ietf.org Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Tue, 23 Oct 2007 08:42:06 -0400 Theodore Tso wrote: > On Tue, Oct 23, 2007 at 01:05:39PM +0200, Simon Josefsson wrote: > > "Frank Ellermann" writes: > > > > > . > > > > I noticed that the 00 draft would expire in two days, and submitted > > a 01 with only minor changes. > > I like this document a lot; kudo's to Simon for writing it! > > My personal opinion is that suggestions for how to write a free > standard published as an informational RFC is much more useful than > trying to get consensus around some edict that the IETF _only_ publish > free standards. > I agree. There are a number of problems with the current draft (i.e., the reference to RSA patents -- those expired years ago), but none that I think would block progress of the document. This is definitely worth pursuing. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 08:56:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJ3G-0008RR-17; Tue, 23 Oct 2007 08:40:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJ39-0008LG-Id for ietf@ietf.org; Tue, 23 Oct 2007 08:39:59 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkJ32-0005bW-9X for ietf@ietf.org; Tue, 23 Oct 2007 08:39:57 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IkJ2P-0000Ms-K5 for ietf@ietf.org; Tue, 23 Oct 2007 12:39:13 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Oct 2007 12:39:13 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Oct 2007 12:39:13 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: "Frank Ellermann" Date: Tue, 23 Oct 2007 14:35:22 +0200 Lines: 13 Message-ID: References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov><87y7e08phu.fsf@mocca.josefsson.org><2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com><4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local><03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA><877iljv6ed.fsf@mocca.josefsson.org><042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA><2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com><471A5668.8060505@gmail.com><048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA><20071022195723.4D9A22202DA@quill.bollow.ch><20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Simon Josefsson wrote: > I would even consider a requirement that in order to move beyond > Proposed Standard, a protocol needs to have a free implementation > available. Tricky, e.g. my BOCU-1 implementation is "free" in a certain sense, but I'm also sure that I don't have a license. =20 Thanks for the new I-D.josefsson-free-standards-howto-01, I'm aware of some folks in the SPF community who'll like it. =20 Frank _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 09:17:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJUO-000457-7A; Tue, 23 Oct 2007 09:08:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJUL-00041X-3n for ietf@ietf.org; Tue, 23 Oct 2007 09:08:05 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkJUE-0006q4-Tr for ietf@ietf.org; Tue, 23 Oct 2007 09:08:05 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2D9064A45; Tue, 23 Oct 2007 09:07:40 -0400 (EDT) From: Sam Hartman To: Scott Brim References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <04fe01c814e7$47f33060$6401a8c0@LROSENTOSHIBA> <18205.60884.253199.882840@swbmbp.local> Date: Tue, 23 Oct 2007 09:07:40 -0400 In-Reply-To: <18205.60884.253199.882840@swbmbp.local> (Scott Brim's message of "Tue, 23 Oct 2007 08:49:24 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>>>> "Scott" == Scott Brim writes: Scott> On 22 Oct 2007 at 17:46 -0400, Sam Hartman allegedly wrote: >> * Phil's proposal has been shot down prematurely in my opinion. >> I agree that his current version would not fly. However I do >> think there are working groups that could make conclusions >> about their patent policies and for which doing so would have >> helped the effort a lot. Scott> Working Groups have the freedom to do that if they wish. I Scott> don't want a simplistic edict from on high that all working Scott> groups must do so. Interactions between issues, technical Scott> and otherwise, are way too varied and potentially Scott> complicated for such shallow rule-making. I agree that forcing working groups to make a decision at the beginning would be bad. I think the you must decide part of Phil's proposal is one of the things that would have to go. Phil may argue that's the only value his proposal has; I disagree. >> Working through draft-housley-tls-authz-extns gave me a >> personal significant lack of confidence in our patent policies >> and whether they meet our goals and objectives. I also wonder >> whether our goals and objectives may have shifted somewhat >> since they were written. However I'm definitely uncomfortable >> with relying on our existing documents in any real dispute. Scott> I think the problem is that because we have a wide range of Scott> opinion and desired outcome, we cannot create simple rules, Scott> which means the difficult cases take a lot of discussion. Scott> I think that's important to preserve, in order to support Scott> the possibility of new outcomes. My lack of confidence had more to do with doubting that our policies would do what we want in court, concerns that there are ambiguities, lack of clarity and that sort of thing than that they allowed for discussion. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 09:17:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJX1-0000eO-JY; Tue, 23 Oct 2007 09:10:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJWz-0000dP-U1 for ietf@ietf.org; Tue, 23 Oct 2007 09:10:49 -0400 Received: from yxa.extundo.com ([83.241.177.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkJWu-0006yp-BJ for ietf@ietf.org; Tue, 23 Oct 2007 09:10:49 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l9NDATb9031625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2007 15:10:30 +0200 From: Simon Josefsson To: "Frank Ellermann" References: <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071023:ietf@ietf.org::J4c0Wz01TMUhr8ht:BJZM X-Hashcash: 1:22:071023:nobody@xyzzy.claranet.de::E4/R/yKWFH4wIXrr:DeIt Date: Tue, 23 Oct 2007 15:10:29 +0200 In-Reply-To: (Frank Ellermann's message of "Tue, 23 Oct 2007 14:35:22 +0200") Message-ID: <871wbm2cze.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ietf@ietf.org Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org "Frank Ellermann" writes: > Simon Josefsson wrote: > >> I would even consider a requirement that in order to move beyond >> Proposed Standard, a protocol needs to have a free implementation >> available. > > Tricky, e.g. my BOCU-1 implementation is "free" in a certain sense, > but I'm also sure that I don't have a license. Do you refer to the IBM patent on BOCU? As far as I have understood, IBM promised to grant a free patent license to people who requested it, but people never received a license despite requesting one. If this is accurate, I think it is a good example of a technology that should not be standardized and should not be promoted by the community. BOCU would also be a good example of why promises to grant a free patent license to those who request it is insufficient. I think the solution here is to come up with a reasonable definition of "free" that would fail to be met in the specific case of BOCU. I don't think it is an impossible problem to solve. How about 'Should be possible to implement without having to pay for a patent license'? /Simon _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 09:45:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJvN-0007LQ-P2; Tue, 23 Oct 2007 09:36:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJvM-0007LG-4W; Tue, 23 Oct 2007 09:36:00 -0400 Received: from relay.cs.tcd.ie ([2001:770:10:200:203:baff:fe16:d11a] helo=smtp.cs.tcd.ie) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkJvL-0000Di-SN; Tue, 23 Oct 2007 09:36:00 -0400 Received: from localhost (localhost [127.0.0.1]) by relay.cs.tcd.ie (Postfix) with ESMTP id DF825384F; Tue, 23 Oct 2007 14:35:43 +0100 (IST) X-Virus-Scanned: amavisd-new at cs.tcd.ie Received: from smtp.cs.tcd.ie ([127.0.0.1]) by localhost (smtp.cs.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lST+6bu6SVS; Tue, 23 Oct 2007 14:35:42 +0100 (IST) Received: from webmail.cs.tcd.ie (wilde.cs.tcd.ie [IPv6:2001:770:10:200:203:baff:fe96:d2b3]) by smtp.cs.tcd.ie (Postfix) with ESMTP id 62E2D38C0; Tue, 23 Oct 2007 14:35:34 +0100 (IST) Received: from 195.56.169.120 (SquirrelMail authenticated user sfarrel6) by webmail.cs.tcd.ie with HTTP; Tue, 23 Oct 2007 14:35:42 +0100 (IST) Message-ID: <51172.195.56.169.120.1193146542.squirrel@webmail.cs.tcd.ie> In-Reply-To: <20071023125246.2b59cbb6@cs.columbia.edu> References: <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <04fe01c814e7$47f33060$6401a8c0@LROSENTOSHIBA> <87ejfm2irg.fsf@mocca.josefsson.org> <20071023124206.GI27132@thunk.org> <20071023125246.2b59cbb6@cs.columbia.edu> Date: Tue, 23 Oct 2007 14:35:42 +0100 (IST) From: stephen.farrell@cs.tcd.ie To: "Steven M. Bellovin" User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.4 (-) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Frank Ellermann , Simon Josefsson , Theodore Tso , ietf@ietf.org, ipr-wg@ietf.org Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stephen.farrell@cs.tcd.ie List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > On Tue, 23 Oct 2007 08:42:06 -0400 > Theodore Tso wrote: >> I like this document a lot; kudo's to Simon for writing it! >> >> My personal opinion is that suggestions for how to write a free >> standard published as an informational RFC is much more useful than >> trying to get consensus around some edict that the IETF _only_ publish >> free standards. >> > I agree. There are a number of problems with the current draft (i.e., > the reference to RSA patents -- those expired years ago), but none that > I think would block progress of the document. This is definitely worth > pursuing. Me too. In a WG I've been involved with recently we had one participant with a patent who wanted to make their declaration open-source friendly but that took a few iterations (which cost them lawyer time). If this document could help short-circuit that, that'd be another good thing. Stephen. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 09:45:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkK09-0004sg-NB; Tue, 23 Oct 2007 09:40:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkK07-0004pK-RW for ietf@ietf.org; Tue, 23 Oct 2007 09:40:56 -0400 Received: from [2002:4519:c427:1:220:edff:fe18:5794] (helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkK06-0000R3-Nb for ietf@ietf.org; Tue, 23 Oct 2007 09:40:55 -0400 Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtps (tls_cipher TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50 #1 (Debian)) id 1IkK94-0003Nm-4v; Tue, 23 Oct 2007 09:50:10 -0400 Received: from tytso by closure.thunk.org with local (Exim 4.67) (envelope-from ) id 1IkJyv-0008Qf-Pe; Tue, 23 Oct 2007 09:39:41 -0400 Date: Tue, 23 Oct 2007 09:39:41 -0400 From: Theodore Tso To: Simon Josefsson Bcc: tytso@mit.edu Message-ID: <20071023133941.GJ27132@thunk.org> References: <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871wbm2cze.fsf@mocca.josefsson.org> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false X-Spam-Score: -0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Frank Ellermann , ietf@ietf.org Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Tue, Oct 23, 2007 at 03:10:29PM +0200, Simon Josefsson wrote: > "Frank Ellermann" writes: > > Do you refer to the IBM patent on BOCU? As far as I have understood, > IBM promised to grant a free patent license to people who requested it, > but people never received a license despite requesting one. If this is > accurate, I think it is a good example of a technology that should not > be standardized and should not be promoted by the community. Can someone give an example of someone who has requested a license but not received one, please? (For reference, there is a copy of a letter which was apparently sent from IBM to the Unicode consortium here: http://unicode.org/notes/tn6/) Since the letter was sent in January 2006, IBM has moved to a new way of dealing with patents and standards, with its "Interoperability Specification Pledge", which is essentially an irrovocable covenant not to assert any Necessary Claims to anyone making, using, importing, selling, or offerring for sale any Covered Implementations, with a broad defensive clause. This was announced in July of this past year, and more details can be found here: http://www-03.ibm.com/linux/opensource/ispinfo.shtml BOCU is not on the list of Covered Specifications, but my guess is that such an omission is very likely due to an oversight rather than any kind of maliciousness. The good news is this new framework doesn't require any kind of formal request to obtain a patent license, and so hopefully a request to move the offer of a RF license covering BOCU to the Interopreability Specification Pledge framework would hopefully take care of your issue. - Ted P.S. All opinions stated above are my own, and do not necessarily reflect IBM's positions, strategies, or opinions. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 10:10:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkKDs-0006oZ-T6; Tue, 23 Oct 2007 09:55:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkKDr-0006lV-HX for ietf@ietf.org; Tue, 23 Oct 2007 09:55:07 -0400 Received: from tarsus.bollow.ch ([82.195.230.222]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkKDr-0008JN-21 for ietf@ietf.org; Tue, 23 Oct 2007 09:55:07 -0400 Received: from tarsus.bollow.ch (localhost [127.0.0.1]) by tarsus.bollow.ch (Postfix) with ESMTP id 69D13B28216; Tue, 23 Oct 2007 16:31:07 +0200 (CEST) Authentication-Results: tarsus.bollow.ch from=nb@bollow.ch; domainkey=neutral (no signature; no policy for bollow.ch) Received: from quill.bollow.ch (10-9.0-85.cust.bluewin.ch [85.0.9.10]) by tarsus.bollow.ch (Postfix) with ESMTP; Tue, 23 Oct 2007 16:31:07 +0200 (CEST) Received: by quill.bollow.ch (Postfix, from userid 1000) id 2CB992202DA; Tue, 23 Oct 2007 15:58:15 +0200 (CEST) From: Norbert Bollow Organization: Bollow Software Economics Research MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=iso-8859-1 To: simon@josefsson.org In-reply-to: <871wbm2cze.fsf@mocca.josefsson.org> (message from Simon Josefsson on Tue, 23 Oct 2007 15:10:29 +0200) References: <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> Message-Id: <20071023135815.2CB992202DA@quill.bollow.ch> Date: Tue, 23 Oct 2007 15:58:15 +0200 (CEST) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: nobody@xyzzy.claranet.de, ietf@ietf.org Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Simon Josefsson wrote: > I think the solution here is to come up with a reasonable definition of > "free" that would fail to be met in the specific case of BOCU. I don't > think it is an impossible problem to solve. How about 'Should be > possible to implement without having to pay for a patent license'? That's IMO not quite strong enough. There are patent licenses which don't require to pay a fee but which impose other conditions that are so severe that having to pay a fee would be by far the lesser evil. How about: 'Should be possible to implement without having to ask for permission or pay a fee'? Greetings, Norbert. --=20 Norbert Bollow http://Norbert.ch President of the Swiss Internet User Group SIUG http://SIUG.ch Working on establishing a non-corrupt and truly /open/ international standards organization http://OpenISO.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 10:50:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkKv7-0004Bj-FV; Tue, 23 Oct 2007 10:39:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkKv5-0004BB-M7 for ietf@ietf.org; Tue, 23 Oct 2007 10:39:47 -0400 Received: from mail26j.sbc-webhosting.com ([216.173.236.231]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IkKux-0003On-EC for ietf@ietf.org; Tue, 23 Oct 2007 10:39:45 -0400 Received: from mx109.stngva01.us.mxservers.net (198.173.112.15) by mail26j.sbc-webhosting.com (RS ver 1.0.95vs) with SMTP id 1-077821366 for ; Tue, 23 Oct 2007 10:39:28 -0400 (EDT) Received: from mmm2630.sbc-webhosting.com [216.173.237.89] (EHLO mmm2630.sbc-webhosting.com) by mx109.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id c670e174.16324.303.mx109.stngva01.us.mxservers.net; Tue, 23 Oct 2007 10:38:36 -0400 (EDT) Received: (qmail 71401 invoked from network); 23 Oct 2007 14:39:24 -0000 Received: from unknown (HELO LROSENTOSHIBA) (lrosen@208.106.45.202) by with ESMTPA; 23 Oct 2007 14:39:24 -0000 From: "Lawrence Rosen" To: References: <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com><471A5668.8060505@gmail.com><048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA><20071022195723.4D9A22202DA@quill.bollow.ch><20071023105651.8D9AC2202DA@quill.bollow.ch><87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> <20071023133941.GJ27132@thunk.org> Date: Tue, 23 Oct 2007 07:38:14 -0700 Organization: Rosenlaw & Einschlag Message-ID: <05ba01c81582$5b156640$6401a8c0@LROSENTOSHIBA> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20071023133941.GJ27132@thunk.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgVe3gXcZVHkxwJQJuURhoGbRq1KAABl0CA X-Spam: [F=0.0043103448; heur=0.500(-26100); stat=0.010; spamtraq-heur=0.300(2007101727)] X-MAIL-FROM: X-SOURCE-IP: [216.173.237.89] X-SF-Loop: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: RE: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lrosen@rosenlaw.com List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Ted Tso wrote: > Since the letter was sent in January 2006, IBM has moved to a new way > of dealing with patents and standards, with its "Interoperability > Specification Pledge", which is essentially an irrovocable covenant > not to assert any Necessary Claims to anyone making, using, importing, > selling, or offerring for sale any Covered Implementations, with a > broad defensive clause. This was announced in July of this past year, IBM's "Interoperability Specification Pledge" is fully consistent with the patent policy I urge generally upon IETF. We should encourage companies to adopt similar covenants for IETF specifications. Thanks, IBM. /Larry > -----Original Message----- > From: Theodore Tso [mailto:tytso@mit.edu] > Sent: Tuesday, October 23, 2007 6:40 AM > To: Simon Josefsson > Cc: Frank Ellermann; ietf@ietf.org > Subject: Re: A priori IPR choices > > On Tue, Oct 23, 2007 at 03:10:29PM +0200, Simon Josefsson wrote: > > "Frank Ellermann" writes: > > > > Do you refer to the IBM patent on BOCU? As far as I have understood, > > IBM promised to grant a free patent license to people who requested it, > > but people never received a license despite requesting one. If this is > > accurate, I think it is a good example of a technology that should not > > be standardized and should not be promoted by the community. > > Can someone give an example of someone who has requested a license but > not received one, please? (For reference, there is a copy of a letter > which was apparently sent from IBM to the Unicode consortium here: > http://unicode.org/notes/tn6/) > > Since the letter was sent in January 2006, IBM has moved to a new way > of dealing with patents and standards, with its "Interoperability > Specification Pledge", which is essentially an irrovocable covenant > not to assert any Necessary Claims to anyone making, using, importing, > selling, or offerring for sale any Covered Implementations, with a > broad defensive clause. This was announced in July of this past year, > and more details can be found here: > > http://www-03.ibm.com/linux/opensource/ispinfo.shtml > > BOCU is not on the list of Covered Specifications, but my guess is > that such an omission is very likely due to an oversight rather than > any kind of maliciousness. The good news is this new framework > doesn't require any kind of formal request to obtain a patent license, > and so hopefully a request to move the offer of a RF license covering > BOCU to the Interopreability Specification Pledge framework would > hopefully take care of your issue. > > - Ted > > P.S. All opinions stated above are my own, and do not necessarily > reflect IBM's positions, strategies, or opinions. > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 11:12:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkLDM-0006m8-3O; Tue, 23 Oct 2007 10:58:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkLDK-0006cD-3g for ietf@ietf.org; Tue, 23 Oct 2007 10:58:38 -0400 Received: from robin.verisign.com ([65.205.251.75]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkLD7-0002LE-JP for ietf@ietf.org; Tue, 23 Oct 2007 10:58:25 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l9NEt7aO009980 for ; Tue, 23 Oct 2007 07:55:07 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Oct 2007 07:58:08 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 23 Oct 2007 07:58:08 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557084EFC@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Lightening talks at the plenary Thread-Index: AcgVfmt83iaHq8BEQ7a5XbwUvgu+0QABfCHu References: <87y7e08phu.fsf@mocca.josefsson.org><2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com><4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local><03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA><877iljv6ed.fsf@mocca.josefsson.org><042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA><2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com><471A5668.8060505@gmail.com><048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA><20071022195723.4D9A22202DA@quill.bollow.ch><20071023105651.8D9AC2202DA@quill.bollow.ch><87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> <20071023135815.2CB992202DA@quill.bollow.ch> From: "Hallam-Baker, Phillip" To: X-OriginalArrivalTime: 23 Oct 2007 14:58:08.0170 (UTC) FILETIME=[1F6670A0:01C81585] X-Spam-Score: 1.8 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: Lightening talks at the plenary X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0503827675==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============0503827675== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81585.1F4D737B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81585.1F4D737B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At the last plenary there was some talk about there no longer being the = technical presentations we used to have. Suggestions were made that this = return. An alternative that might be more interesting would be to adopt the W3C = practice of lightning talks which are 3 minute presentations on a very = specific topic. These are actually quite fun. ------_=_NextPart_001_01C81585.1F4D737B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: A priori IPR choices=0A= =0A= =0A= =0A=

At the last plenary there was some talk about there no longer being = the technical presentations we used to have. Suggestions were made that = this return.

=0A=

An alternative that might be more interesting would be to adopt the = W3C practice of lightning talks which are 3 minute presentations on a = very specific topic. These are actually quite fun.

------_=_NextPart_001_01C81585.1F4D737B-- --===============0503827675== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0503827675==-- From ietf-bounces@ietf.org Tue Oct 23 15:11:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkP5l-0006Uz-NK; Tue, 23 Oct 2007 15:07:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkP5j-0006Me-Sk for ietf@ietf.org; Tue, 23 Oct 2007 15:07:03 -0400 Received: from stratton-two-sixty-six.mit.edu ([18.187.6.11] helo=carter-zimmerman.suchdamage.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkP5Z-0008NK-Ht for ietf@ietf.org; Tue, 23 Oct 2007 15:06:58 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 353DC4A45; Tue, 23 Oct 2007 15:06:53 -0400 (EDT) From: Sam Hartman To: Simon Josefsson References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> Date: Tue, 23 Oct 2007 15:06:53 -0400 In-Reply-To: <87abqa2i1z.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 23 Oct 2007 13:20:56 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>>>> "Simon" == Simon Josefsson writes: Simon> Norbert Bollow writes: >>> I also note that we can easily get onto a slippery slope here. >>> Many companies view the GPL to be an encumbrance no less >>> severe than the patent policies of other companies. Perhaps >>> it is even more severe because encumbrances associated with >>> patents that can be made to go away by the payment of money >>> are less complicated to deal with (if one is willing to spent >>> the money) than encumbrances under the GPS, which just don't >>> go away. Would you recommend that IETF not permit any >>> materials that might be encumbered under the GPL, etc.? >> I would recommend that in order to be considered acceptable, >> implementation in GPL'd free software as well as implementation >> in proprietary closed-source software must both be allowed by >> the licensing terms of any patents. Simon> I think that is a good recommendation, and I support it. Simon> I would even consider a requirement that in order to move Simon> beyond Proposed Standard, a protocol needs to have a free Simon> implementation available. I'd love to get there, but I think building that consensus today would be a non-starter. Let me suggest starting with a lesser goal. TrFrom ietf-bounces@ietf.org Tue Oct 23 15:11:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkP5l-0006Uz-NK; Tue, 23 Oct 2007 15:07:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkP5j-0006Me-Sk for ietf@ietf.org; Tue, 23 Oct 2007 15:07:03 -0400 Received: from stratton-two-sixty-six.mit.edu ([18.187.6.11] helo=carter-zimmerman.suchdamage.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkP5Z-0008NK-Ht for ietf@ietf.org; Tue, 23 Oct 2007 15:06:58 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 353DC4A45; Tue, 23 Oct 2007 15:06:53 -0400 (EDT) From: Sam Hartman To: Simon Josefsson References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> Date: Tue, 23 Oct 2007 15:06:53 -0400 In-Reply-To: <87abqa2i1z.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 23 Oct 2007 13:20:56 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>>>> "Simon" == Simon Josefsson writes: Simon> Norbert Bollow writes: >>> I also note that we can easily get onto a slippery slope here. >>> Many companies view the GPL to be an encumbrance no less >>> severe than the patent policies of other companies. Perhaps >>> it is even more severe because encumbrances associated with >>> patents that can be made to go away by the payment of money >>> are less complicated to deal with (if one is willing to spent >>> the money) than encumbrances under the GPS, which just don't >>> go away. Would you recommend that IETF not permit any >>> materials that might be encumbered under the GPL, etc.? >> I would recommend that in order to be considered acceptable, >> implementation in GPL'd free software as well as implementation >> in proprietary closed-source software must both be allowed by >> the licensing terms of any patents. Simon> I think that is a good recommendation, and I support it. Simon> I would even consider a requirement that in order to move Simon> beyond Proposed Standard, a protocol needs to have a free Simon> implementation available. I'd love to get there, but I think building that consensus today would be a non-starter. Let me suggest starting with a lesser goal. Try to build a consensus that unless there is a good reason to do otherwise, it needs to be possible to write an open-source implementation of a standard and that the absence of such an implementation should be considered a red flag when advancing beyond proposed. Basically I'd like to start by getting to a point where we assume that open-source implementations are a goal and that we explicitly decide that they are not a requirement in contexts where that makes sense. I suspect we would run into resistance building that consensus but it might be worth trying. --Sam _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 15:11:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkOy4-0007Gi-MI; Tue, 23 Oct 2007 14:59:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkOy2-000791-Ka for ietf@ietf.org; Tue, 23 Oct 2007 14:59:06 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkOxo-0007vm-4h for ietf@ietf.org; Tue, 23 Oct 2007 14:58:58 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l9NIs8WF010976; Tue, 23 Oct 2007 11:54:08 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Oct 2007 11:57:38 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 23 Oct 2007 11:57:37 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557084F00@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A priori IPR choices [Re: Third LastCall:draft-housley-tls-authz-extns] Thread-Index: AcgVdxjDlo84G/YaQmCJv1CWVsiDtQAKo4Pk References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov><87y7e08phu.fsf@mocca.josefsson.org><2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com><4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local><03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA><877iljv6ed.fsf@mocca.josefsson.org><042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA><2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com><471A5668.8060505@gmail.com><048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA><04fe01c814e7$47f33060$6401a8c0@LROSENTOSHIBA> <18205.60884.253199.882840@swbmbp.local> From: "Hallam-Baker, Phillip" To: "Sam Hartman" , "Scott Brim" X-OriginalArrivalTime: 23 Oct 2007 18:57:38.0325 (UTC) FILETIME=[94AE1450:01C815A6] X-Spam-Score: 1.8 (+) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: ietf@ietf.org Subject: RE: A priori IPR choices [Re: Third LastCall:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0532603761==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============0532603761== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C815A6.947239F7" This is a multi-part messagey to build a consensus that unless there is a good reason to do otherwise, it needs to be possible to write an open-source implementation of a standard and that the absence of such an implementation should be considered a red flag when advancing beyond proposed. Basically I'd like to start by getting to a point where we assume that open-source implementations are a goal and that we explicitly decide that they are not a requirement in contexts where that makes sense. I suspect we would run into resistance building that consensus but it might be worth trying. --Sam _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 15:11:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkOy4-0007Gi-MI; Tue, 23 Oct 2007 14:59:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkOy2-000791-Ka for ietf@ietf.org; Tue, 23 Oct 2007 14:59:06 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkOxo-0007vm-4h for ietf@ietf.org; Tue, 23 Oct 2007 14:58:58 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l9NIs8WF010976; Tue, 23 Oct 2007 11:54:08 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Oct 2007 11:57:38 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 23 Oct 2007 11:57:37 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557084F00@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A priori IPR choices [Re: Third LastCall:draft-housley-tls-authz-extns] Thread-Index: AcgVdxjDlo84G/YaQmCJv1CWVsiDtQAKo4Pk References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov><87y7e08phu.fsf@mocca.josefsson.org><2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com><4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local><03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA><877iljv6ed.fsf@mocca.josefsson.org><042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA><2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com><471A5668.8060505@gmail.com><048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA><04fe01c814e7$47f33060$6401a8c0@LROSENTOSHIBA> <18205.60884.253199.882840@swbmbp.local> From: "Hallam-Baker, Phillip" To: "Sam Hartman" , "Scott Brim" X-OriginalArrivalTime: 23 Oct 2007 18:57:38.0325 (UTC) FILETIME=[94AE1450:01C815A6] X-Spam-Score: 1.8 (+) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: ietf@ietf.org Subject: RE: A priori IPR choices [Re: Third LastCall:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0532603761==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============0532603761== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C815A6.947239F7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C815A6.947239F7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The objective here is to constrain the amount of unproductive argument = by limiting the number of possible end states. =20 In particular I would like to tip the scales so that if we have = proposals A and B where A is unemcumbered but B is not that proposal B = has to demonstrate a remarkably higher value in order to be chosen over = A.=20 =20 Now imagine that proposal B is slightly better but not so overwhelmingly = so that it is going to win if it continues to be encumbered. I want the = engineer responsible to be able to go to their management with a clear = value proposition: that the licensing fees will be $0 in either case, = that in order to benefit from the advantages of B the IPR owner is going = to have to execute an agreement that satisfies these specific criteria, = and that these criteria have proved acceptable to the lawyers at major = patent conscious companies such as [...], that this will not blunt the = defensive use of the patents and that any other IPR holders will be = required to provide access to their technology on terms that are at = least as favorable. =20 The more wiggle room is allowed, the less likely it is that the intended = result will be achieved. In particular the lawyer for company B is going = to be looking to demonstrate their worth to management by demonstrating = that they have successfully ensured that equally favorable terms will be = available from othe companies. =20 =20 Another important case is the defensive patent or patent application = which is understood to be complete garbage by everyone including the = owner but can be finessed to establish a dominant position in a working = group before it begins. The 'its my ball and I'm taking it home unless I = get to bat first' gambit. =20 =20 Another way to tip the scales would be to specify whether the IPR regime = is RAND or RANDZ in the charter and allow this to be changed by = rechartering. =20 We already make a limited IPR release when submitting an Internet Draft. = I see two cases of interest: =20 1) The whole point of the proposal is to make the ideas covered by the = IPR into a standard. 2) A proposal is made which incidentally happens to involve other IPR = held by the submitter's company that the submitter is either not aware = of or not aware of the connection. =20 The second is the corner case concern which motivates a lot of the big = company objections to up front declarations. But in practice the first = point is much more frequent. =20 If the first case holds I think the submitter should either state that = this is a RAND proposal when they submit or get the necessary approvals = to submitt as a proposal for RANDZ - IF ACCEPTED. =20 =20 If we get two RANDZ proposals and one thats only RAND we don't need to = talk about the third one unless the IPR changes. =20 ________________________________ From: Sam Hartman [mailto:hartmans-ietf@mit.edu] Sent: Tue 23/10/2007 9:07 AM To: Scott Brim Cc: ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third = LastCall:draft-housley-tls-authz-extns] >>>>> "Scott" =3D=3D Scott Brim writes: Scott> On 22 Oct 2007 at 17:46 -0400, Sam Hartman allegedly wrote: >> * Phil's proposal has been shot down prematurely in my opinion. >> I agree that his current version would not fly. However I do >> think there are working groups that could make conclusions >> about their patent policies and for which doing so would have >> helped the effort a lot. Scott> Working Groups have the freedom to do that if they wish. I Scott> don't want a simplistic edict from on high that all working Scott> groups must do so. Interactions between issues, technical Scott> and otherwise, are way too varied and potentially Scott> complicated for such shallow rule-making. I agree that forcing working groups to make a decision at the beginning would be bad. I think the you must decide part of P in MIME format. ------_=_NextPart_001_01C815A6.947239F7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The objective here is to constrain the amount of unproductive argument = by limiting the number of possible end states. =20 In particular I would like to tip the scales so that if we have = proposals A and B where A is unemcumbered but B is not that proposal B = has to demonstrate a remarkably higher value in order to be chosen over = A.=20 =20 Now imagine that proposal B is slightly better but not so overwhelmingly = so that it is going to win if it continues to be encumbered. I want the = engineer responsible to be able to go to their management with a clear = value proposition: that the licensing fees will be $0 in either case, = that in order to benefit from the advantages of B the IPR owner is going = to have to execute an agreement that satisfies these specific criteria, = and that these criteria have proved acceptable to the lawyers at major = patent conscious companies such as [...], that this will not blunt the = defensive use of the patents and that any other IPR holders will be = required to provide access to their technology on terms that are at = least as favorable. =20 The more wiggle room is allowed, the less likely it is that the intended = result will be achieved. In particular the lawyer for company B is going = to be looking to demonstrate their worth to management by demonstrating = that they have successfully ensured that equally favorable terms will be = available from othe companies. =20 =20 Another important case is the defensive patent or patent application = which is understood to be complete garbage by everyone including the = owner but can be finessed to establish a dominant position in a working = group before it begins. The 'its my ball and I'm taking it home unless I = get to bat first' gambit. =20 =20 Another way to tip the scales would be to specify whether the IPR regime = is RAND or RANDZ in the charter and allow this to be changed by = rechartering. =20 We already make a limited IPR release when submitting an Internet Draft. = I see two cases of interest: =20 1) The whole point of the proposal is to make the ideas covered by the = IPR into a standard. 2) A proposal is made which incidentally happens to involve other IPR = held by the submitter's company that the submitter is either not aware = of or not aware of the connection. =20 The second is the corner case concern which motivates a lot of the big = company objections to up front declarations. But in practice the first = point is much more frequent. =20 If the first case holds I think the submitter should either state that = this is a RAND proposal when they submit or get the necessary approvals = to submitt as a proposal for RANDZ - IF ACCEPTED. =20 =20 If we get two RANDZ proposals and one thats only RAND we don't need to = talk about the third one unless the IPR changes. =20 ________________________________ From: Sam Hartman [mailto:hartmans-ietf@mit.edu] Sent: Tue 23/10/2007 9:07 AM To: Scott Brim Cc: ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third = LastCall:draft-housley-tls-authz-extns] >>>>> "Scott" =3D=3D Scott Brim writes: Scott> On 22 Oct 2007 at 17:46 -0400, Sam Hartman allegedly wrote: >> * Phil's proposal has been shot down prematurely in my opinion. >> I agree that his current version would not fly. However I do >> think there are working groups that could make conclusions >> about their patent policies and for which doing so would have >> helped the effort a lot. Scott> Working Groups have the freedom to do that if they wish. I Scott> don't want a simplistic edict from on high that all working Scott> groups must do so. Interactions between issues, technical Scott> and otherwise, are way too varied and potentially Scott> complicated for such shallow rule-making. I agree that forcing working groups to make a decision at the beginning would be bad. I think the you must decide part of Phil's proposal is one of the things that would have to go. Phil may argue that's the only value his proposal has; I disagree. >> Working through draft-housley-tls-authz-extns gave me a >> personal significant lack of confidence in our patent policies >> and whether they meet our goals and objectives. I also wonder >> whether our goals and objectives may have shifted somewhat >> since they were written. However I'm definitely uncomfortable >> with relying on our existing documents in any real dispute. Scott> I think the problem is that because we have a wide range of Scott> opinion and desired outcome, we cannot create simple rules, Scott> which means the difficult cases take a lot of discussion. Scott> I think that's important to preserve, in order to support Scott> the possibility of new outcomes. My lack of confidence had more to do with doubting that our policies would do what we want in court, concerns that there are ambiguities, lack of clarity and that sort of thing than that they allowed for discussion. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ------_=_NextPart_001_01C815A6.947239F7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: A priori IPR choices [Re: Third = LastCall:draft-housley-tls-authz-extns]=0A= =0A= =0A= =0A=
=0A=
The objective = here is to constrain the amount of unproductive argument by limiting the = number of possible end states.
=0A=
 
=0A=
In particular I would like to = tip the scales so that if we have proposals A and B where A is = unemcumbered but B is not that proposal B has to demonstrate a = remarkably higher value in order to be chosen over A.
=0A=
 
=0A=
Now imagine that proposal B = is slightly better but not so overwhelmingly so that it is going to win = if it continues to be encumbered. I want the engineer responsible to be = able to go to their management with a clear value proposition: that the = licensing fees will be $0 in either case, that in order to benefit from = the advantages of B the IPR owner is going to have to execute an = agreement that satisfies these specific criteria, and that these = criteria have proved acceptable to the lawyers at major patent conscious = companies such as [...], that this will not blunt the defensive use of = the patents and that any other IPR holders will be required to = provide access to their technology on terms that are at least as = favorable.
=0A=
 
=0A=
The more wiggle room is = allowed, the less likely it is that the intended result will be = achieved. In particular the lawyer for company B is going to be looking = to demonstrate their worth to management by demonstrating that they have = successfully ensured that equally favorable terms will be available from = othe companies.
=0A=
 
=0A=
 
=0A=
Another important case is the = defensive patent or patent application which is understood to be = complete garbage by everyone including the owner  but can be = finessed to establish a dominant position in a working group before it = begins. The 'its my ball and I'm taking it home unless I get to bat = first' gambit.
=0A=
> Working through draft-housley-tls-authz-extns gave me a >> personal significant lack of confidence in our patent policies >> and whether they meet our goals and objectives. I also wonder >> whether our goals and objectives may have shifted somewhat >> since they were written. However I'm definitely uncomfortable >> with relying on our existing documents in any real dispute. Scott> I think the problem is that because we have a wide range of Scott> opinion and desired outcome, we cannot create simple rules, Scott> which means the difficult cases take a lot of discussion. Scott> I think that's important to preserve, in order to support Scott> the possibility of new outcomes. My lack of confidence had more to do with doubting that our policies would do what we want in court, concerns that there are ambiguities, lack of clarity and that sort of thing than that they allowed for discussion. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ------_=_NextPart_001_01C815A6.947239F7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: A priori IPR choices [Re: Third = LastCall:draft-housley-tls-authz-extns]=0A= =0A= =0A= =0A=
=0A=
The objective = here is to constrain the amount of unproductive argument by limiting the = number of possible end states.
=0A=
 
=0A=
In particular I would like to = tip the scales so that if we have proposals A and B where A is = unemcumbered but B is not that proposal B has to demonstrate a = remarkably higher value in order to be chosen over A.
=0A=
 
=0A=
Now imagine that proposal B = is slightly better but not so overwhelmingly so that it is going to win = if it continues to be encumbered. I want the engineer responsible to be = able to go to their management with a clear value proposition: that the = licensing fees will be $0 in either case, that in order to benefit from = the advantages of B the IPR owner is going to have to execute an = agreement that satisfies these specific criteria, and that these = criteria have proved acceptable to the lawyers at major patent conscious = companies such as [...], that this will not blunt the defensive use of = the patents and that any other IPR holders will be required to = provide access to their technology on terms that are at least as = favorable.
=0A=
 
=0A=
The more wiggle room is = allowed, the less likely it is that the intended result will be = achieved. In particular the lawyer for company B is going to be looking = to demonstrate their worth to management by demonstrating that they have = successfully ensured that equally favorable terms will be available from = othe companies.
=0A=
 
=0A=
 
=0A=
Another important case is the = defensive patent or patent application which is understood to be = complete garbage by everyone including the owner  but can be = finessed to establish a dominant position in a working group before it = begins. The 'its my ball and I'm taking it home unless I get to bat = first' gambit.
=0A=
 
=0A=
 
=0A=
Another way to tip the scales = would be to specify whether the IPR regime is RAND or RANDZ in the = charter and allow this to be changed by rechartering.
=0A=
 
=0A=
We already make a limited IPR = release when submitting an Internet Draft. I see two cases of = interest:
=0A=
 
=0A=
1) The whole point of the = proposal is to make the ideas covered by the IPR into a = standard.
=0A=
2) A proposal is made which = incidentally happens to involve other IPR held by the submitter's = company that the submitter is either not aware of or not aware of the = connection.
=0A=
 
=0A=
The second is the corner case = concern which motivates a lot of the big company objections to up front = declarations. But in practice the first point is much more = frequent.
=0A=
 
=0A=
If the first case holds I = think the submitter should either state that this is a RAND proposal = when they submit or get the necessary approvals to submitt as a = proposal for RANDZ - IF ACCEPTED.
=0A=
 
=0A=
 
=0A=
If we get two RANDZ proposals = and one thats only RAND we don't need to talk about the third one unless = the IPR changes.
=0A=
 
=0A=
=0A=
=0A=
=0A=
=0A=
From: Sam Hartman = [mailto:hartmans-ietf@mit.edu]
Sent: Tue 23/10/2007 9:07 = AM
To: Scott Brim
Cc: = ietf@ietf.org
Subject: Re: A priori IPR choices [Re: Third = LastCall:draft-housley-tls-authz-extns]

=0A=
=0A=

>>>>> "Scott" =3D=3D Scott Brim = <swb@employees.org> writes:

    Scott> On = 22 Oct 2007 at 17:46 -0400, Sam Hartman allegedly = wrote:
    >> * Phil's proposal has been shot = down prematurely in my opinion.
    >> I agree = that his current version would not fly.  However I = do
    >> think there are working groups that = could make conclusions
    >> about their patent = policies and for which doing so would have
    = >> helped the effort a lot.

    Scott> = Working Groups have the freedom to do that if they wish.  = I
    Scott> don't want a simplistic edict from on = high that all working
    Scott> groups must do = so.  Interactions between issues, technical
    = Scott> and otherwise, are way too varied and = potentially
    Scott> complicated for such shallow = rule-making.

I agree that forcing working groups to make a = decision at the
beginning would be bad.  I think the you must = decide part of Phil's
proposal is one of the things that would have = to go.  Phil may argue
that's the only value his proposal has; I = disagree.

    >> Working through = draft-housley-tls-authz-extns gave me a
    >> = personal significant lack of confidence in our patent = policies
  &nbsce=3DArial size=3D2>
 

=0A=
 
=0A=
Another way to tip the scales = would be to specify whether the IPR regime is RAND or RANDZ in the = charter and allow this to be changed by rechartering.
=0A=
 
=0A=
We already make a limited IPR = release when submitting an Internet Draft. I see two cases of = interest:
=0A=
 
=0A=
1) The whole point of the = proposal is to make the ideas covered by the IPR into a = standard.
=0A=
2) A proposal is made which = incidentally happens to involve other IPR held by the submitter's = company that the submitter is either not aware of or not aware of the = connection.
=0A=
 
=0A=
The second is the corner case = concern which motivates a lot of the big company objections to up front = declarations. But in practice the first point is much more = frequent.
=0A=
 
=0A=
If the first case holds I = think the submitter should either state that this is a RAND proposal = when they submit or get the necessary approvals to submitt as a = proposal for RANDZ - IF ACCEPTED.
=0A=
 
=0A=
 
=0A=
If we get two RANDZ proposals = and one thats only RAND we don't need to talk about the third one unless = the IPR changes.
=0A=
 
=0A=
=0A=
=0A=
=0A=
=0A=
From: Sam Hartman = [mailto:hartmans-ietf@mit.edu]
Sent: Tue 23/10/2007 9:07 = AM
To: Scott Brim
Cc: = ietf@ietf.org
Subject: Re: A priori IPR choices [Re: Third = LastCall:draft-housley-tls-authz-extns]

=0A=
=0A=

>>>>> "Scott" =3D=3D Scott Brim = <swb@employees.org> writes:

    Scott> On = 22 Oct 2007 at 17:46 -0400, Sam Hartman allegedly = wrote:
    >> * Phil's proposal has been shot = down prematurely in my opinion.
    >> I agree = that his current version would not fly.  However I = do
    >> think there are working groups that = could make conclusions
    >> about their patent = policies and for which doing so would have
    = >> helped the effort a lot.

    Scott> = Working Groups have the freedom to do that if they wish.  = I
    Scott> don't want a simplistic edict from on = high that all working
    Scott> groups must do = so.  Interactions between issues, technical
    = Scott> and otherwise, are way too varied and = potentially
    Scott> complicated for such shallow = rule-making.

I agree that forcing working groups to make a = decision at the
beginning would be bad.  I think the you must = decide part of Phil's
proposal is one of the things that would have = to go.  Phil may argue
that's the only value his proposal has; I = disagree.

    >> Working through = draft-housley-tls-authz-extns gave me a
    >> = personal significant lack of confidence in our patent = policies
    >> and whether they meet our goals = and objectives.  I also wonder
    >> = whether our goals and objectives may have shifted = somewhat
    >> since they were written.  = However I'm definitely uncomfortable
    >> with = relying on our existing documents in any real = dispute.

    Scott> I think the problem is that = because we have a wide range of
    Scott> opinion = and desired outcome, we cannot create simple = rules,
    Scott> which means the difficult cases = take a lot of discussion.
    Scott> I think that's = important to preserve, in order to support
    = Scott> the possibility of new outcomes.

My lack of confidence = had more to do with doubting that our policies
would do what we want = in court, concerns that there are ambiguities,
lack of clarity and = that sort of thing than that they allowed = for
discussion.


___________________________________________= ____
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.or= g/mailman/listinfo/ietf

------_=_NextPart_001_01C815A6.947239F7-- --===============0532603761== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0532603761==-- p; >> and whether they meet our goals = and objectives.  I also wonder
    >> = whether our goals and objectives may have shifted = somewhat
    >> since they were written.  = However I'm definitely uncomfortable
    >> with = relying on our existing documents in any real = dispute.

    Scott> I think the problem is that = because we have a wide range of
    Scott> opinion = and desired outcome, we cannot create simple = rules,
    Scott> which means the difficult cases = take a lot of discussion.
    Scott> I think that's = important to preserve, in order to support
    = Scott> the possibility of new outcomes.

My lack of confidence = had more to do with doubting that our policies
would do what we want = in court, concerns that there are ambiguities,
lack of clarity and = that sort of thing than that they allowed = for
discussion.


___________________________________________= ____
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.or= g/mailman/listinfo/ietf

------_=_NextPart_001_01C815A6.947239F7-- --===============0532603761== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0532603761==-- From ietf-bounces@ietf.org Tue Oct 23 15:22:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkPHN-0007W3-Uh; Tue, 23 Oct 2007 15:19:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkPHM-0007Hn-Jj for ietf@ietf.org; Tue, 23 Oct 2007 15:19:04 -0400 Received: from stratton-two-sixty-six.mit.edu ([18.187.6.11] helo=carter-zimmerman.suchdamage.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkPHH-0005q4-AC for ietf@ietf.org; Tue, 23 Oct 2007 15:18:59 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D85C64A45; Tue, 23 Oct 2007 15:18:58 -0400 (EDT) From: Sam Hartman To: "Hallam-Baker, Phillip" References: <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <04fe01c814e7$47f33060$6401a8c0@LROSENTOSHIBA> <18205.60884.253199.882840@swbmbp.local> <2788466ED3E31C418E9ACC5C31661557084F00@mou1wnexmb09.vcorp.ad.vrsn.com> Date: Tue, 23 Oct 2007 15:18:58 -0400 In-Reply-To: <2788466ED3E31C418E9ACC5C31661557084F00@mou1wnexmb09.vcorp.ad.vrsn.com> (Phillip Hallam-Baker's message of "Tue, 23 Oct 2007 11:57:37 -0700") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third LastCall:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Phil, I understand what you're trying to do. I agree that more wiggle room makes it harder. However I think that to achieve consensus you're going to need to allow working groups to choose to turn on the wiggle room. I think that you could get somewhere with an opt-in proposal. For a particular technology or WG, the WG can opt-in to something with very little wiggle room. I personally don't think you can do better than that. However I do think you could put together some standard optinos to opt-in to. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 15:22:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkPDt-0001c1-AU; Tue, 23 Oct 2007 15:15:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkPDq-0001ae-UD for ietf@ietf.org; Tue, 23 Oct 2007 15:15:26 -0400 Received: from stratton-two-sixty-six.mit.edu ([18.187.6.11] helo=carter-zimmerman.suchdamage.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkPDq-0005gf-GV for ietf@ietf.org; Tue, 23 Oct 2007 15:15:26 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1EE844A45; Tue, 23 Oct 2007 15:15:26 -0400 (EDT) From: Sam Hartman To: Simon Josefsson References: <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> Date: Tue, 23 Oct 2007 15:15:26 -0400 In-Reply-To: <871wbm2cze.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 23 Oct 2007 15:10:29 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ietf@ietf.org Subject: When is using patented technology appropriate? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>>>> "Simon" == Simon Josefsson writes: Simon> "Frank Ellermann" writes: >> Simon Josefsson wrote: >>> I would even consider a requirement that in order to move >>> beyond Proposed Standard, a protocol needs to have a free >>> implementation available. >> Tricky, e.g. my BOCU-1 implementation is "free" in a certain >> sense, but I'm also sure that I don't have a license. Simon> Do you refer to the IBM patent on BOCU? As far as I have Simon> understood, IBM promised to grant a free patent license to Simon> people who requested it, but people never received a Simon> license despite requesting one. If this is accurate, I Simon> think it is a good example of a technology that should not Simon> be standardized and should not be promoted by the Simon> community. It seems very unlikely to me that IBM would choose to assert such a patent against an implementation after having promised to give a free license. If we didn't know about the patent we would be happy to go use the technology. Yet somehow that we know about the patent and we have strong reason to suspect that we will never be bothered by the patent, we are unwilling to depend on the technology? That makes no sense to me. It seems to me that in some sense that disclosing a patent should not make us less willing to use something. This is especially true when the disclosing party is not obligated to make the disclosure. Disclosing a patent along with an implication that the patent will be enforced or that the patent is high value should make us less willing to use a technology. I'll even except that absent royalty-free licensing a typical patent disclosure has the implication of desire to enforce the patent. If IBM had implied that they cared a lot that people actually ask for the license; if IBM had attempted to assert the patent or threatened to do so, I'd agree with you that we did not use the technology. However by promising to give out free licenses and by not even caring enough about the patent to set up a licensing infrastructure that actually works, I think IBM sends a rather different message. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 16:21:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkPzY-0004t5-RA; Tue, 23 Oct 2007 16:04:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkPzX-0004ls-RJ for ietf@ietf.org; Tue, 23 Oct 2007 16:04:43 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkPzT-0007jX-7o for ietf@ietf.org; Tue, 23 Oct 2007 16:04:39 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9NK4ab6013553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 Oct 2007 13:04:37 -0700 Received: from [98.207.5.180] (vpn-10-50-16-8.qualcomm.com [10.50.16.8]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9NK4XNP017257; Tue, 23 Oct 2007 13:04:34 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <2788466ED3E31C418E9ACC5C31661557084F00@mou1wnexmb09.vcorp.ad.vrsn.com> References: <2FCE85A0-6C57-4205-B716-1B371FC3987C @nist.gov><87y7e08phu.fsf@mocca.josefsson.org><2788466ED3E31C418E9ACC5C316 61557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com><4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local><03d501c811dc$031404a0$6401a8c0@LR OSENTOSHIBA><877iljv6ed.fsf@mocca .josefsson.org><042201c8128a$63a1e40 0$6401a8c0@LROSENTOSHIBA><2788466ED3E31C418E9ACC5C31661557084EE8@mou1wne xmb09.vcorp.ad.vrsn.com><471A5668.8060505@gmail.com><048d01c81388$5230a9a0 $6401a8c0@LROSENTOSHIBA><04fe01c814e7 $47f33060$6401a8c0@LROSENTOSHIBA> <18205.60884.253199.882840@swbmbp.local> <2788466ED3E31C418E9ACC5C31661557084F00@mou1wnexmb09.vcorp.ad.vrsn.com> Date: Tue, 23 Oct 2007 13:04:32 -0700 To: "Hallam-Baker, Phillip" , "Sam Hartman" , "Scott Brim" From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ietf@ietf.org Subject: RE: A priori IPR choices [Re: Third LastCall:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 11:57 AM -0700 10/23/07, Hallam-Baker, Phillip wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C815A6.947239F7" > >The objective here is to constrain the amount of unproductive argument by limiting the number of possible end states. > >In particular I would like to tip the scales so that if we have proposals A and B where A is unemcumbered but B is not that proposal B has to demonstrate a remarkably higher value in order to be chosen over A. > I believe it is fairer to recognize that in your example proposal B is known to have been patented where A is not. There is always the chance that someone will turn out to have secured rights which they later claim read on A. In that case it may actually be better to choose B, knowing that the license offered works for the development and deployment community than to choose A. In other words, a "defensive" patent declaration by someone whose license works for the appropriate community may actually add security. It doesn't completely remove the risk that someone will turn up with other rights, but it really can help. The reason that the "wiggle room" argument is problematic is that the development and deployment communities for different areas of standards work in the IETF are different. A license offered by company C for work in routing may work well, where the exact same license by organization M for work at the apps layer may not. Allowing the folks who actually plan to write the code to indicate where there are problems and where not may be better than trying to get a few sizes to fit all. Several people have already sent pointers to Simon's draft, which describes how to get to a particular outcome; I think that is a good thrust. With that and similar documents in hand, that community can have blueprints for how to achieve particular goals. Those will get used, and that will make things easier. But that's very different from trying to set the scales for working groups in advance. That will just get into hair-splitting over whether something meets a vague test for "remarkably higher", which is even harder to get argued. "I can and will implement this, with the offered license" is a much easier statement to evaluate than "This meets the 3 tests offered in RFC XXXX for "remarkably higher" value because of N, M, and O". Speaking only for my non-lawyer self, Ted _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 16:33:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkQIs-0007Hu-KK; Tue, 23 Oct 2007 16:24:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkQIr-0007HC-9D for ietf@ietf.org; Tue, 23 Oct 2007 16:24:41 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkQIl-0003lt-1L for ietf@ietf.org; Tue, 23 Oct 2007 16:24:41 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9NKOIEg015814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 Oct 2007 13:24:19 -0700 Received: from [98.207.5.180] (vpn-10-50-16-8.qualcomm.com [10.50.16.8]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9NKOFQf010947; Tue, 23 Oct 2007 13:24:15 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> Date: Tue, 23 Oct 2007 13:24:13 -0700 To: Sam Hartman , Simon Josefsson From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 3:06 PM -0400 10/23/07, Sam Hartman wrote: > >Let me suggest starting with a lesser goal. Try to build a consensus >that unless there is a good reason to do otherwise, it needs to be >possible to write an open-source implementation of a standard and that >the absence of such an implementation should be considered a red flag >when advancing beyond proposed. I think you have to be careful here, as "open-source" covers a variety of licenses. Having a diverse set of implementations is clearly a good sign that a standard's specification is clear enough to implement and useful enough that folks have chosen to spend the time. Those ought to be critical aspects of our thinking when we look at how to revive the standards track's upper reaches. But reviving it will get more difficult, in my opinion, if we set tests like "must show at least one implementation subject to the GPL", as that presumes which implementation groups are interested, or delays forward progress until a group that does not work in that mode produces an example implementation that meets the test. Even if this is an informal requirement (lore vs. spec.), this could discourage those working for advancement. >Basically I'd like to start by getting to a point where we assume that >open-source implementations are a goal and that we explicitly decide >that they are not a requirement in contexts where that makes sense. > >I suspect we would run into resistance building that consensus but it >might be worth trying. I'm a little confused as to the antecedent of "we" in the statement above. I assume you mean you and Simon, but that you are basically speaking for yourself. If you mean "we" in some other sense (especially if you mean it to include the IESG, which some might infer from your role), it is not clear. Speaking only for myself, Ted _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 16:41:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkQTL-00083C-VF; Tue, 23 Oct 2007 16:35:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkQTJ-0007p0-Pv for ietf@ietf.org; Tue, 23 Oct 2007 16:35:29 -0400 Received: from stratton-two-sixty-six.mit.edu ([18.187.6.11] helo=carter-zimmerman.suchdamage.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkQTF-0000NY-9s for ietf@ietf.org; Tue, 23 Oct 2007 16:35:25 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B53ED4A45; Tue, 23 Oct 2007 16:35:24 -0400 (EDT) From: Sam Hartman To: Ted Hardie References: <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> Date: Tue, 23 Oct 2007 16:35:24 -0400 In-Reply-To: (Ted Hardie's message of "Tue, 23 Oct 2007 13:24:13 -0700") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Simon Josefsson , ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>>>> "Ted" == Ted Hardie writes: Ted> At 3:06 PM -0400 10/23/07, Sam Hartman wrote: >> Let me suggest starting with a lesser goal. Try to build a >> consensus that unless there is a good reason to do otherwise, >> it needs to be possible to write an open-source implementation >> of a standard and that the absence of such an implementation >> should be considered a red flag when advancing beyond proposed. Ted> I think you have to be careful here, as "open-source" covers Ted> a variety of licenses. Having a diverse set of Ted> implementations is clearly a good sign that a standard's Ted> specification is clear enough to implement and useful enough Ted> that folks have chosen to spend the time. Those ought to be Ted> critical aspects of our thinking when we look at how to Ted> revive the standards track's upper reaches. But reviving it Ted> will get more difficult, in my opinion, if we set tests like Ted> "must show at least one implementation subject to the GPL", Ted> as that presumes which implementation groups are interested, Ted> or delays forward progress until a group that does not work Ted> in that mode produces an example implementation that meets Ted> the test. Even if this is an informal requirement (lore Ted> vs. spec.), this could discourage those working for Ted> advancement. my assumption is that our standards that are useful tend to be useful in open-source environments. And that people should at least stop and think if there is not an OS implementation of a standard. We might find a few areas (MPLS and CCAMP spring to mind) where it is quite clear that no such desire to implement exists even though there are significant other implementations. And that we'd want to think about why there was no OS implementation if it happened there was none. By think about I mean provide some explanation for and consider whether there is a deeper problem. >> Basically I'd like to start by getting to a point where we >> assume that open-source implementations are a goal and that we >> explicitly decide that they are not a requirement in contexts >> where that makes sense. >> >> I suspect we would run into resistance building that consensus >> but it might be worth trying. Ted> I'm a little confused as to the antecedent of "we" in the Ted> statement above. I assume you mean you and Simon, but that Ted> you are basically speaking for yourself. If you mean "we" in Ted> some other sense (especially if you mean it to include the Ted> IESG, which some might infer from your role), it is not Ted> clear. We == those interested in this idea. I'm sorry that I failed to make it clear I'm speaking only for myself and especially not for the IESG. --Sam _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 16:48:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkQcr-0000Pn-G1; Tue, 23 Oct 2007 16:45:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkQcp-0007xv-8s for ietf@ietf.org; Tue, 23 Oct 2007 16:45:19 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkQcb-0004Zs-7k for ietf@ietf.org; Tue, 23 Oct 2007 16:45:11 -0400 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l9NKeoie014790; Tue, 23 Oct 2007 13:40:50 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Oct 2007 21:44:20 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 23 Oct 2007 13:44:19 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557084F03@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A priori IPR choices [Re: Third LastCall:draft-housley-tls-authz-extns] Thread-Index: AcgVqYc3Xq76RbkzQPmqO5UDo/L+fAACSe2y References: <87y7e08phu.fsf@mocca.josefsson.org><2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com><4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local><03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA><877iljv6ed.fsf@mocca.josefsson.org><042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA><2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com><471A5668.8060505@gmail.com><048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA><04fe01c814e7$47f33060$6401a8c0@LROSENTOSHIBA> <18205.60884.253199.882840@swbmbp.local><2788466ED3E31C418E9ACC5C31661557084F00@mou1wnexmb09.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: "Sam Hartman" X-OriginalArrivalTime: 23 Oct 2007 20:44:20.0174 (UTC) FILETIME=[7C7AB6E0:01C815B5] X-Spam-Score: -2.2 (--) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: ietf@ietf.org Subject: RE: A priori IPR choices [Re: Third LastCall:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0020960810==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============0020960810== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C815B5.7C3BBA2B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C815B5.7C3BBA2B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The two types of wiggle room that experience has taught me to be highly = undesirable are: =20 1) Wiggle room of the form 'our terms are as good as RANDZ' when what is = being offered is going to require licensing for significant classes of = implementation, for example: =20 A Terms that preclude commercial implementation B Terms that effectively preclude open source C Terms that preclude particular types of open source license D Terms that allow certain uses but allow the IPR holder to reserve = certain key use types such as providing essential services. =20 2) Wiggle room of the type 'customary RANDZ terms are not acceptable = from you because' =20 A We don't like your company and want to make life difficult for you B We have discovered a theological objection to the customary terms C We lost a debate in another forum and would like to reopen it D We have a technical objection and will use this as a veto =20 While it is impossible to determine what the motive of a party might be = in a given circumstance I have heard all of these motives at least = plausibly ascribed to one or more parties in real situations. =20 The most pernicious of these in my view is 1D. This should not be = considered RANDZ, it is a royalty based licensing scheme where the = rights holder has decided to maximize their revenues by applying a = particular business model. =20 ________________________________ From: Sam Hartman [mailto:hartmans-ietf@mit.edu] Sent: Tue 23/10/2007 3:18 PM To: Hallam-Baker, Phillip Cc: Scott Brim; ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third = LastCall:draft-housley-tls-authz-extns] Phil, I understand what you're trying to do. I agree that more wiggle room makes it harder. However I think that to achieve consensus you're going to need to allow working groups to choose to turn on the wiggle room. I think that you could get somewhere with an opt-in proposal. For a particular technology or WG, the WG can opt-in to something with very little wiggle room. I personally don't think you can do better than that. However I do think you could put together some standard optinos to opt-in to. ------_=_NextPart_001_01C815B5.7C3BBA2B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: A priori IPR choices [Re: Third = LastCall:draft-housley-tls-authz-extns]=0A= =0A= =0A= =0A=
=0A=
The two types = of wiggle room that experience has taught me to be highly undesirable = are:
=0A=
 
=0A=
1) Wiggle room of the form = 'our terms are as good as RANDZ' when what is being offered is going to = require licensing for significant classes of implementation, for = example:
=0A=
 
=0A=
   A Terms = that preclude commercial implementation
=0A=
   B Terms that = effectively preclude open source
=0A=
   C Terms = that preclude particular types of open source license
=0A=
   D Terms = that allow certain uses but allow the IPR holder to reserve certain key = use types such as providing essential services.
=0A=
 
=0A=
2) Wiggle room of the type = 'customary RANDZ terms are not acceptable from you because'
=0A=
 
=0A=
   A We don't = like your company and want to make life difficult for you
=0A=
   B We have = discovered a theological objection to the customary terms
=0A=
   C We lost a = debate in another forum and would like to reopen it
=0A=
   D We have a = technical objection and will use this as a veto
=0A=
 
=0A=
While it is impossible to = determine what the motive of a party might be in a given circumstance I = have heard all of these motives at least plausibly ascribed to one or = more parties in real situations.
=0A=
 
=0A=
The most pernicious of these = in my view is 1D. This should not be considered RANDZ, it is a royalty = based licensing scheme where the rights holder has decided to maximize = their revenues by applying a particular business = model.
=0A=
 
=0A=

=0A=
=0A= From: Sam Hartman = [mailto:hartmans-ietf@mit.edu]
Sent: Tue 23/10/2007 3:18 = PM
To: Hallam-Baker, Phillip
Cc: Scott Brim; = ietf@ietf.org
Subject: Re: A priori IPR choices [Re: Third = LastCall:draft-housley-tls-authz-extns]

=0A=
=0A=

Phil, I understand what you're trying to do.  I = agree that more wiggle
room makes it harder.

However I think = that to achieve consensus you're going to need to
allow working = groups to choose to turn on the wiggle room.

I think that you = could get somewhere with an opt-in proposal.  For a
particular = technology or WG, the WG can opt-in to something with very
little = wiggle room.  I personally don't think you can do better = than
that.

However I do think you could put together some = standard optinos to
opt-in to.

------_=_NextPart_001_01C815B5.7C3BBA2B-- --===============0020960810== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0020960810==-- From ietf-bounces@ietf.org Tue Oct 23 16:48:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkQZB-0007RN-9Q; Tue, 23 Oct 2007 16:41:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkQZ9-0007O2-Bx for ietf@ietf.org; Tue, 23 Oct 2007 16:41:31 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkQZ1-0004SR-K7 for ietf@ietf.org; Tue, 23 Oct 2007 16:41:31 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9NKfCZA008461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 Oct 2007 13:41:12 -0700 Received: from [98.207.5.180] (vpn-10-50-16-8.qualcomm.com [10.50.16.8]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9NKf6lu027322; Tue, 23 Oct 2007 13:41:07 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> Date: Tue, 23 Oct 2007 13:41:06 -0700 To: Sam Hartman , Simon Josefsson From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ietf@ietf.org Subject: Re: When is using patented technology appropriate? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > >It seems to me that in some sense that disclosing a patent should not >make us less willing to use something. This is especially true when >the disclosing party is not obligated to make the disclosure. >Disclosing a patent along with an implication that the patent will be >enforced or that the patent is high value should make us less willing >to use a technology. I'll even except that absent royalty-free >licensing a typical patent disclosure has the implication of desire to >enforce the patent. I think it is very dangerous to infer anything like "desire to enforce the patent". These are situations where you actually have to read the specifics to know what it is going. That's why we already have strong encouragement to include license statements with IPR disclosures (see the declaration form, section VI). The availability of for-royalty patent licenses along side other types of licenses, as in the statement at http://www1.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-ecrit-lost-06.txt may or may not change the calculus of a developer who intends to implement this. But it is clearly neither the same as a case where all licenses are royalty bearing nor the case where all licenses are free. Nor is it the same as a license where the maximum fee requested is guaranteed to be a percentage (and hence zero for free implementations). Again, speaking just for myself. regards, Ted PS. My apologies to my Cisco colleagues if I appear to be consistently using your declarations as examples. No harm intended. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 16:56:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkQgR-0002wT-RY; Tue, 23 Oct 2007 16:49:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkQgP-0002tj-Iw for ietf@ietf.org; Tue, 23 Oct 2007 16:49:01 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkQgJ-0004ki-B1 for ietf@ietf.org; Tue, 23 Oct 2007 16:49:01 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9NKmjfQ018088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 Oct 2007 13:48:46 -0700 Received: from [98.207.5.180] (vpn-10-50-16-8.qualcomm.com [10.50.16.8]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9NKmg91017593; Tue, 23 Oct 2007 13:48:43 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> Date: Tue, 23 Oct 2007 13:48:40 -0700 To: Sam Hartman From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Simon Josefsson , ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 4:35 PM -0400 10/23/07, Sam Hartman wrote: > >my assumption is that our standards that are useful tend to be useful >in open-source environments. And that people should at least stop and >think if there is not an OS implementation of a standard. We might >find a few areas (MPLS and CCAMP spring to mind) where it is quite >clear that no such desire to implement exists even though there are >significant other implementations. Interestingly, I was also thinking of CCAMP and MPLS when I was coming up with examples. There may well be others, though, where the open-source implementations have a comparatively small impact on the actual deployments even though they clearly exist; BGP, for example, might fit into that category. The bigger point, though, is that there are now and likely will be in the future some technologies that are worth IETF time and effort even if they don't appeal to the open source community as projects (or even if the open source community projects will have little deployment). >We == those interested in this idea. I'm sorry that I failed to make >it clear I'm speaking only for myself and especially not for the IESG. > >--Sam Thank you for your clarification. I, as well, am speaking only for myself. regards, Ted _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 16:56:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkQgq-0003UJ-RQ; Tue, 23 Oct 2007 16:49:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkQgo-0003GZ-KT for ietf@ietf.org; Tue, 23 Oct 2007 16:49:26 -0400 Received: from stratton-two-sixty-six.mit.edu ([18.187.6.11] helo=carter-zimmerman.suchdamage.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkQgk-0000oO-9r for ietf@ietf.org; Tue, 23 Oct 2007 16:49:22 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id ADB564A45; Tue, 23 Oct 2007 16:49:21 -0400 (EDT) From: Sam Hartman To: Ted Hardie References: <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> Date: Tue, 23 Oct 2007 16:49:21 -0400 In-Reply-To: (Ted Hardie's message of "Tue, 23 Oct 2007 13:41:06 -0700") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Simon Josefsson , ietf@ietf.org Subject: Re: When is using patented technology appropriate? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>>>> "Ted" == Ted Hardie writes: >> It seems to me that in some sense that disclosing a patent >> should not make us less willing to use something. This is >> especially true when the disclosing party is not obligated to >> make the disclosure. Disclosing a patent along with an >> implication that the patent will be enforced or that the patent >> is high value should make us less willing to use a technology. >> I'll even except that absent royalty-free licensing a typical >> patent disclosure has the implication of desire to enforce the >> patent. Ted> I think it is very dangerous to infer anything like "desire Ted> to enforce the patent". These are situations where you Ted> actually have to read the specifics to know what it is going. You are probably right. However I feel there is something pathalogical going on in the open source community surrounding patents. People are willing to use technologies that probably have patents but are unwilling to use technologies that clearly have patents and that have a long track record of not particularly being enforced. I get worried when I see that spilling into the IETF. Speaking for myself, --Sam _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 17:04:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkQoo-0008Mb-Fy; Tue, 23 Oct 2007 16:57:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkQom-0008Iy-Vg for ietf@ietf.org; Tue, 23 Oct 2007 16:57:41 -0400 Received: from stratton-two-sixty-six.mit.edu ([18.187.6.11] helo=carter-zimmerman.suchdamage.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkQok-0001AM-JO for ietf@ietf.org; Tue, 23 Oct 2007 16:57:38 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E60A64A47; Tue, 23 Oct 2007 16:57:37 -0400 (EDT) From: Sam Hartman To: "Hallam-Baker, Phillip" References: <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <04fe01c814e7$47f33060$6401a8c0@LROSENTOSHIBA> <18205.60884.253199.882840@swbmbp.local> <2788466ED3E31C418E9ACC5C31661557084F00@mou1wnexmb09.vcorp.ad.vrsn.com> <2788466ED3E31C418E9ACC5C31661557084F03@mou1wnexmb09.vcorp.ad.vrsn.com> Date: Tue, 23 Oct 2007 16:57:37 -0400 In-Reply-To: <2788466ED3E31C418E9ACC5C31661557084F03@mou1wnexmb09.vcorp.ad.vrsn.com> (Phillip Hallam-Baker's message of "Tue, 23 Oct 2007 13:44:19 -0700") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third LastCall:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>>>> "Hallam-Baker," == Hallam-Baker, Phillip writes: Hallam-Baker,> The two types of wiggle room that experience has Hallam-Baker,> taught me to be highly undesirable are: Hallam-Baker,> 1) Wiggle room of the form 'our terms are as good Hallam-Baker,> as RANDZ' when what is being offered is going to Hallam-Baker,> require licensing for significant classes of Hallam-Baker,> implementation, for example: Hallam-Baker,> A Terms that preclude commercial implementation Hallam-Baker,> B Terms that effectively preclude open source C Hallam-Baker,> Terms that preclude particular types of open source Hallam-Baker,> license D Terms that allow certain uses but allow Hallam-Baker,> the IPR holder to reserve certain key use types Hallam-Baker,> such as providing essential services. Hallam-Baker,> 2) Wiggle room of the type 'customary RANDZ terms Hallam-Baker,> are not acceptable from you because' Hallam-Baker,> A We don't like your company and want to make Hallam-Baker,> life difficult for you B We have discovered a Hallam-Baker,> theological objection to the customary terms C We Hallam-Baker,> lost a debate in another forum and would like to Hallam-Baker,> reopen it D We have a technical objection and will Hallam-Baker,> use this as a veto I agree that these types of discussions happen and are almost always bad ideas. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 21:02:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkUDW-0005Hb-Ud; Tue, 23 Oct 2007 20:35:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkUDV-0005HV-Ku for ietf@ietf.org; Tue, 23 Oct 2007 20:35:25 -0400 Received: from rv-out-0910.google.com ([209.85.198.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkUDP-0004zK-B7 for ietf@ietf.org; Tue, 23 Oct 2007 20:35:25 -0400 Received: by rv-out-0910.google.com with SMTP id l15so22213rvb for ; Tue, 23 Oct 2007 17:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=vimxmqUWo71JmfRfsTVnnd2oVXS8eUf6n6NGBnDRJ6A=; b=Grtfn8LWtVdK3h0SQ8v6sytUJl19k0asFs6mO0AMq8YnDd14J5HtUJLbPwgu3ygeOtBAP8YfLe8nfD7FDci8WQ1BtqPuMVrlMcOYq15HSPTgWo2XZOZt2ZDC9XCVGx+wJpuEBBN0uhj0JUUAwfIgJ2uQpVFh4g/DMu4pZXtQvVk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=E/nP9SZLiipwc4NbviQgS3GKDKDPHQ537DlFHke781DNnLG3Zht+kNR+3Z8YfHNTBm5kd4YYsRu9J7x9KBV0cMz6pHMewHHLsRWMuDOgASo7QtAQ9/bPi7sF1mAoIwch25gAcsBeSQ/TqUbnRErxjSSGwaDZKMN5p8xw+/Dm/ks= Received: by 10.114.173.15 with SMTP id v15mr1471wae.1193186091602; Tue, 23 Oct 2007 17:34:51 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id j21sm239644wah.2007.10.23.17.34.48 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Oct 2007 17:34:49 -0700 (PDT) Message-ID: <471E9325.9020400@gmail.com> Date: Wed, 24 Oct 2007 13:34:45 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ietf@ietf.org References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> In-Reply-To: <87abqa2i1z.fsf@mocca.josefsson.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-24 00:20, Simon Josefsson wrote: > Norbert Bollow writes: ... >> I would recommend that in order to be considered acceptable, >> implementation in GPL'd free software as well as implementation in >> proprietary closed-source software must both be allowed by the >> licensing terms of any patents. > > I think that is a good recommendation, and I support it. > > I would even consider a requirement that in order to move beyond > Proposed Standard, a protocol needs to have a free implementation > available. There are two *very* different suggestions above. Norbert specifically suggests GPL compatibility as a requirement. That is a very stringent requirement, because of the way the GPL is written. Simon suggests the existence of a free implementation as part of the IETF's implementation interop requirements; depending on the definition of "free", that is a much milder requirement. In fact it seems like a quite natural extension of the rule established in RFC 2026 section 4.1.2, first paragraph: "If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process." On 2007-10-24 08:06, Sam Hartman wrote: > Let me suggest starting with a lesser goal. Try to build a consensus > that unless there is a good reason to do otherwise, it needs to be > possible to write an open-source implementation of a standard and that > the absence of such an implementation should be considered a red flag > when advancing beyond proposed. s/red flag/yellow flag/ perhaps, but I agree this is a very reasonable goal, and as far as I can see, essentially consistent with RFC 2026 as quoted above. On 2007-10-24 02:58, Norbert Bollow wrote: ... > That's IMO not quite strong enough. There are patent licenses which > don't require to pay a fee but which impose other conditions that are > so severe that having to pay a fee would be by far the lesser evil. > > How about: 'Should be possible to implement without having to ask for > permission or pay a fee'? That will never fly. For good reason, many patent holders insist on reciprocity conditions, and that seems to require an explicit request and acknowledgement. On 2007-10-24 07:57, Hallam-Baker, Phillip wrote: > If we get two RANDZ proposals and one thats only RAND we don't > need to talk about the third one unless the IPR changes. I think we do, if the third one is clearly technically superior. Why is the cost of a patent automatically more important than *any* engineering cost or benefit? Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 21:30:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkUpo-0002HJ-0N; Tue, 23 Oct 2007 21:15:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkUpm-0002Gg-5z for ietf@ietf.org; Tue, 23 Oct 2007 21:14:58 -0400 Received: from mailout00.controlledmail.com ([72.81.252.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkUpl-0001CN-Kt for ietf@ietf.org; Tue, 23 Oct 2007 21:14:58 -0400 Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id EF3985CC107; Wed, 24 Oct 2007 01:14:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1193188497; bh=hiniqNRf/3FRBbkjQxczaHn9HF7qHWWmlmZu59J N85Y=; h=Received:Mime-Version:X-Mailer:To:Subject:Message-ID: In-Reply-To:References:From:Date:Content-type: Content-transfer-encoding:X-AV-Checked; b=j1bK9fwZErs6hVVgi0S185Dl wiTs9qWIqz6b8IlwCOmFnwunAAmEC/OBzwoSdkDIPPr59DVVsuL3QbySF74c/2NuLm7 /+17gsOJ/OFfH1t1Kkl2f/lU5TbSCtNeibfI38ZDb5IiyYr4Z4zZivr7F5pnhiff5HE qf1MwSn2NCego= Received: from [70.195.169.164] (164.sub-70-195-169.myvzw.com [70.195.169.164]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout00.controlledmail.com (Postfix) with ESMTP id 927B45CC0F9; Wed, 24 Oct 2007 01:14:46 +0000 (UTC) Mime-Version: 1.0 X-Mailer: SnapperMail 2.3.5.02 by Snapperfish To: ietf@ietf.org Message-ID: <8138-SnapperMsgD8DB99B6C3444D0A@[70.195.169.164]> In-Reply-To: <471E9325.9020400@gmail.com> References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> <471E9325.9020400@gmail.com> From: Scott Kitterman Date: Tue, 23 Oct 2007 21:14:37 -0400 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Wed, 24 Oct 2007 13:34:45 +1300 Brian E Carpenter wrote: >On 2007-10-24 00:20, Simon Josefsson wrote: >> Norbert Bollow writes: >... >>> I would recommend that in order to be considered acceptable, >>> implementation in GPL'd free software as well as implementation in >>> proprietary closed-source software must both be allowed by the >>> licensing terms of any patents. >> >> I think that is a good recommendation, and I support it. >> >> I would even consider a requirement that in order to move beyond >> Proposed Standard, a protocol needs to have a free implementation >> available. > >There are two *very* different suggestions above. > >Norbert specifically suggests GPL compatibility as a requirement. >That is a very stringent requirement, because of the way the GPL >is written. Simon suggests the existence of a free implementation >as part of the IETF's implementation interop requirements; depending >on the definition of "free", that is a much milder requirement. > >In fact it seems like a quite natural extension of the rule >established in RFC 2026 section 4.1.2, first paragraph: >"If patented or otherwise controlled technology > is required for implementation, the separate implementations must > also have resulted from separate exercise of the licensing process." > >On 2007-10-24 08:06, Sam Hartman wrote: > >> Let me suggest starting with a lesser goal. Try to build a consensus >> that unless there is a good reason to do otherwise, it needs to be >> possible to write an open-source implementation of a standard and that >> the absence of such an implementation should be considered a red flag >> when advancing beyond proposed. > >s/red flag/yellow flag/ perhaps, but I agree this is a very reasonable >goal, and as far as I can see, essentially consistent with RFC 2026 >as quoted above. > >On 2007-10-24 02:58, Norbert Bollow wrote: >... >> That's IMO not quite strong enough. There are patent licenses which >> don't require to pay a fee but which impose other conditions that are >> so severe that having to pay a fee would be by far the lesser evil. >> >> How about: 'Should be possible to implement without having to ask for >> permission or pay a fee'? > >That will never fly. For good reason, many patent holders insist >on reciprocity conditions, and that seems to require an explicit >request and acknowledgement. And that will never fly (IANAL) with the GPL and so here we sit at an impasse again. So either a GPL implementation is important to interoperability in a given space or it is not. If it is important to interoperabilty, then this is a showstopper. If not, maybe not. >On 2007-10-24 07:57, Hallam-Baker, Phillip wrote: > >> If we get two RANDZ proposals and one thats only RAND we don't >> need to talk about the third one unless the IPR changes. > >I think we do, if the third one is clearly technically superior. >Why is the cost of a patent automatically more important than >*any* engineering cost or benefit? It's not the cost, but the incurred limit on interoperability. Scott K _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 23 23:21:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkWMB-00020a-OO; Tue, 23 Oct 2007 22:52:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkWM9-0001db-T4 for ietf@ietf.org; Tue, 23 Oct 2007 22:52:29 -0400 Received: from mail26i.sbc-webhosting.com ([216.173.236.230]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IkWM1-0001aF-Hz for ietf@ietf.org; Tue, 23 Oct 2007 22:52:27 -0400 Received: from mx75.stngva01.us.mxservers.net (204.202.242.146) by mail26i.sbc-webhosting.com (RS ver 1.0.95vs) with SMTP id 0-0623154320 for ; Tue, 23 Oct 2007 22:52:00 -0400 (EDT) Received: from mmm2630.sbc-webhosting.com [216.173.237.89] (EHLO mmm2630.sbc-webhosting.com) by mx75.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id 662be174.1555.044.mx75.stngva01.us.mxservers.net; Tue, 23 Oct 2007 22:48:06 -0400 (EDT) Received: (qmail 55226 invoked from network); 24 Oct 2007 02:51:58 -0000 Received: from unknown (HELO LROSENTOSHIBA) (lrosen@208.106.45.202) by with ESMTPA; 24 Oct 2007 02:51:58 -0000 From: "Lawrence Rosen" To: Date: Tue, 23 Oct 2007 19:50:53 -0700 Organization: Rosenlaw & Einschlag Message-ID: <001d01c815e8$b2b966b0$6401a8c0@LROSENTOSHIBA> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgV6LDV1h0ax/DmTLatmeFJFPPcyQ== X-Spam: [F=0.0100000000; heur=0.500(1100); stat=0.010; spamtraq-heur=0.500(2007101727)] X-MAIL-FROM: X-SOURCE-IP: [216.173.237.89] X-SF-Loop: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: license-discuss@opensource.org Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lrosen@rosenlaw.com List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2037402710==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============2037402710== Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C815AE.065A8EB0" This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C815AE.065A8EB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: IETF list These are statements from FSF about the issue we've been discussing at ietf@ietf.org. http://www.fsf.org/campaigns/software-patents/draft-housley-tls-authz-extns. html and http://www.fsf.org/news/oppose-tls-authz-standard.html The GPL does not have problems with most IETF specifications, only those that are encumbered by non-free patents. This is an important example of why so many of us in the open source and free software communities believe that the IETF patent policy must be improved. /Larry Rosen Lawrence Rosen Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com) 3001 King Ranch Road, Ukiah, CA 95482 707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243 Skype: LawrenceRosen Author of "Open Source Licensing: Software Freedom and Intellectual Property Law" (Prentice Hall 2004) ------=_NextPart_000_001E_01C815AE.065A8EB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To: IETF list

 

These are statements from FSF about the issue we've = been discussing at ietf@ietf.org. =

 

http://www.fsf.org/campaigns/software-patents/draft-hous= ley-tls-authz-extns.html

 

and

 

http://ww= w.fsf.org/news/oppose-tls-authz-standard.html

 

The GPL does not have problems with most IETF specifications, only those that are encumbered by non-free patents. This = is an important example of why so many of us in the open source and free = software communities believe that the IETF patent policy must be improved. =

 

/Larry Rosen

 

Lawrence Rosen

Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com)=

3001 King Ranch Road, Ukiah, CA = 95482

707-485-1242 * cell: 707-478-8932 * fax: = 707-485-1243

Skype: LawrenceRosen

Author of "Open Source Licensing: Software = Freedom and

         =        Intellectual Property Law" (Prentice Hall = 2004)

 

------=_NextPart_000_001E_01C815AE.065A8EB0-- --===============2037402710== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============2037402710==-- From ietf-bounces@ietf.org Wed Oct 24 02:03:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkYuO-00011M-UU; Wed, 24 Oct 2007 01:36:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkYuH-0000vv-7R for ietf@ietf.org; Wed, 24 Oct 2007 01:35:53 -0400 Received: from [2002:4519:c427:1:220:edff:fe18:5794] (helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkYuB-0006Ee-Sy for ietf@ietf.org; Wed, 24 Oct 2007 01:35:48 -0400 Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtps (tls_cipher TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50 #1 (Debian)) id 1IkZ38-0007Xa-S3; Wed, 24 Oct 2007 01:45:04 -0400 Received: from tytso by closure.thunk.org with local (Exim 4.67) (envelope-from ) id 1IkTpI-0001fU-UK; Tue, 23 Oct 2007 20:10:24 -0400 Date: Tue, 23 Oct 2007 20:10:24 -0400 From: Theodore Tso To: Ted Hardie Bcc: tytso@mit.edu Message-ID: <20071024001024.GA6404@thunk.org> References: <18205.60884.253199.882840@swbmbp.local> <2788466ED3E31C418E9ACC5C31661557084F00@mou1wnexmb09.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false X-Spam-Score: 1.4 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Sam Hartman , ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third LastCall:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Tue, Oct 23, 2007 at 01:04:32PM -0700, Ted Hardie wrote: > I believe it is fairer to recognize that in your example proposal B > is known to have been patented where A is not. There is always the > chance that someone will turn out to have secured rights which they > later claim read on A. In that case it may actually be better to > choose B, knowing that the license offered works for the development > and deployment community than to choose A. In other words, a > "defensive" patent declaration by someone whose license works for > the appropriate community may actually add security. It doesn't > completely remove the risk that someone will turn up with other > rights, but it really can help. This doesn't follow. Just because a company has patents that read on B doesn't guarantee some other company *also* has patents that read on B. So you can't say with certainty choosing path B is better than path A just because a company has already declared they have patents that read on B. The US Patent Office may have simply issued two patents on the identical technology (I believe the cannonical example is the case where three patents were issued covering the same compression algorithm). Or there may have been other aspects of B that happened to be patented by another company, and if it is currently owned by a Patent Troll who has no interest in participating in the IETF process, there is no way for the working group to know about the Patent Troll's patents. Aren't patents fun? :-) - Ted _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 24 06:41:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkdEV-0001Mc-6X; Wed, 24 Oct 2007 06:13:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkdET-0001Hy-PX for ietf@ietf.org; Wed, 24 Oct 2007 06:13:01 -0400 Received: from yxa.extundo.com ([83.241.177.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkdEF-0007xb-2G for ietf@ietf.org; Wed, 24 Oct 2007 06:12:47 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l9OACcxU015608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Oct 2007 12:12:41 +0200 From: Simon Josefsson To: Sam Hartman References: <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071024:ietf@ietf.org::lhWm1WREzXm2bMFN:4NNa X-Hashcash: 1:22:071024:hartmans-ietf@mit.edu::b9vdSW2RN083wsQB:e2nx Date: Wed, 24 Oct 2007 12:12:38 +0200 In-Reply-To: (Sam Hartman's message of "Tue, 23 Oct 2007 15:15:26 -0400") Message-ID: <87fy00vn1l.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ietf@ietf.org Subject: Re: When is using patented technology appropriate? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Sam Hartman writes: >>>>>> "Simon" == Simon Josefsson writes: > > Simon> "Frank Ellermann" writes: > >> Simon Josefsson wrote: > >>> I would even consider a requirement that in order to move > >>> beyond Proposed Standard, a protocol needs to have a free > >>> implementation available. > >> Tricky, e.g. my BOCU-1 implementation is "free" in a certain > >> sense, but I'm also sure that I don't have a license. > > Simon> Do you refer to the IBM patent on BOCU? As far as I have > Simon> understood, IBM promised to grant a free patent license to > Simon> people who requested it, but people never received a > Simon> license despite requesting one. If this is accurate, I > Simon> think it is a good example of a technology that should not > Simon> be standardized and should not be promoted by the > Simon> community. > > It seems very unlikely to me that IBM would choose to assert such a > patent against an implementation after having promised to give a free > license. If you replace IBM with 'A Patent Troll', do you think the same holds? I think not. If the IETF is going to have a policy on this, I believe it is important for the policy to treat everyone the same. I think that BOCU is a relevant example to show that promises to give a patent license is not good enough. (That is assuming my understanding of the BOCU example is correct; I haven't implemented or tried to get a license myself, I have only read about others who have done so.) If even IBM cannot do it properly, we have reason to not assume that others will be able to do it. Especially those less supportive of the free software community. > If we didn't know about the patent we would be happy to go use the > technology. Yet somehow that we know about the patent and we have > strong reason to suspect that we will never be bothered by the patent, > we are unwilling to depend on the technology? That makes no sense to > me. Agreed, it doesn't make sense. However, if somebody other than IBM proposes a technology and gives a patent license promise, I don't think we have a strong reason to suspect we will never be bothered by their patent. /Simon _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 24 06:59:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkdlC-0005OO-2b; Wed, 24 Oct 2007 06:46:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkdlA-0005Kz-FS for ietf@ietf.org; Wed, 24 Oct 2007 06:46:48 -0400 Received: from tarsus.bollow.ch ([82.195.230.222]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikdl9-0000L8-WD for ietf@ietf.org; Wed, 24 Oct 2007 06:46:48 -0400 Received: from tarsus.bollow.ch (localhost [127.0.0.1]) by tarsus.bollow.ch (Postfix) with ESMTP id A4DF1B28092 for ; Wed, 24 Oct 2007 13:22:57 +0200 (CEST) Authentication-Results: tarsus.bollow.ch from=nb@bollow.ch; domainkey=neutral (no signature; no policy for bollow.ch) Received: from quill.bollow.ch (215-4.0-85.cust.bluewin.ch [85.0.4.215]) by tarsus.bollow.ch (Postfix) with ESMTP for ; Wed, 24 Oct 2007 13:22:57 +0200 (CEST) Received: by quill.bollow.ch (Postfix, from userid 1000) id 90F0622024E; Wed, 24 Oct 2007 12:50:10 +0200 (CEST) From: Norbert Bollow Organization: Bollow Software Economics Research MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=iso-8859-1 To: ietf@ietf.org In-reply-to: <8138-SnapperMsgD8DB99B6C3444D0A@[70.195.169.164]> (message from Scott Kitterman on Tue, 23 Oct 2007 21:14:37 -0400) References: <2FCE85A0-6C57-4205-B716-1B371FC3987C@nist.gov> <87y7e08phu.fsf@mocca.josefsson.org> <2788466ED3E31C418E9ACC5C31661557084ED4@mou1wnexmb09.vcorp.ad.vrsn.com> <4717D090.1000908@gmail.com> <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> <471E9325.9020400@gmail.com> <8138-SnapperMsgD8DB99B6C3444D0A@[70.195.169.164]> Message-Id: <20071024105010.90F0622024E@quill.bollow.ch> Date: Wed, 24 Oct 2007 12:50:10 +0200 (CEST) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Scott Kitterman wrote: > And that will never fly (IANAL) with the GPL and so here we sit at an=20 > impasse again. So either a GPL implementation is important to=20 > interoperability in a given space or it is not. If it is important to=20 > interoperabilty, then this is a showstopper. If not, maybe not. Do you have any specific example of an internet standard for which you think that lack of GPL-compatible licensing of any (perhaps just hypothetical) relevant patents would not cause interoperability serious problems if the patent holder chose to aggressive enforce the terms of that non-GPL-compatible patent license? Greetings, Norbert. --=20 Norbert Bollow http://Norbert.ch President of the Swiss Internet User Group SIUG http://SIUG.ch Working on establishing a non-corrupt and truly /open/ international standards organization http://OpenISO.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 24 08:22:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikevh-00085b-48; Wed, 24 Oct 2007 08:01:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikevf-00084Q-6i for ietf@ietf.org; Wed, 24 Oct 2007 08:01:43 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikeve-0002De-QR for ietf@ietf.org; Wed, 24 Oct 2007 08:01:43 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ikevb-0003YH-Vm for ietf@ietf.org; Wed, 24 Oct 2007 12:01:39 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Oct 2007 12:01:39 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Oct 2007 12:01:39 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: "Frank Ellermann" Date: Wed, 24 Oct 2007 13:58:28 +0200 Lines: 20 Message-ID: References: <001d01c815e8$b2b966b0$6401a8c0@LROSENTOSHIBA> <015101c81624$3357e090$0a01a8c0@rodage.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: license-discuss@opensource.org Subject: FYI 28 (was: A priori IPR choices) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Philippe Verdy wrote: > We do have lots of informational RFCs which are still needed and > actively used, sometimes even required (notably those in the BCP > series, like the "Netiquette" which has become a requirement for > almost all ISP customers, as part of their contract, despite they > are only informational, and could change at any time after having > been replaced by another RFC replacing the older one with the same > BCP number. BCPs aren't informational RFCs, for an introduction see RFC 4677 or . Maybe you confused BCP with FYI, RFC 1855 is also known as FYI 28. FLAME ON: It's now 12 years old, and some parts are rather silly: Be careful with monospacing fonts, and be sure to have a signature which you attach to your message. FLAME OFF (flame tags recommended by FYI 28). Frank _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 24 08:41:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkfJh-0003Qz-0z; Wed, 24 Oct 2007 08:26:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkfJe-0003LG-JV for ietf@ietf.org; Wed, 24 Oct 2007 08:26:30 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkfJb-0002mD-4e for ietf@ietf.org; Wed, 24 Oct 2007 08:26:27 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IkfJM-00007b-Cm for ietf@ietf.org; Wed, 24 Oct 2007 12:26:12 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Oct 2007 12:26:12 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Oct 2007 12:26:12 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: "Frank Ellermann" Date: Wed, 24 Oct 2007 14:23:06 +0200 Lines: 16 Message-ID: References: <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com><471A5668.8060505@gmail.com><048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA><20071022195723.4D9A22202DA@quill.bollow.ch><20071023105651.8D9AC2202DA@quill.bollow.ch><87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> <20071023133941.GJ27132@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Theodore Tso wrote: [BOCU-1]=20 > Can someone give an example of someone who has requested > a license but not received one, please? Apparently somebody tried and got no answer, compare > http://www-03.ibm.com/linux/opensource/ispinfo.shtml > BOCU is not on the list of Covered Specifications Yes, I knew this page, unfortunately BOCU wasn't listed. Frank _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 24 11:00:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkhLG-0000jW-ET; Wed, 24 Oct 2007 10:36:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkhLE-0000jP-A4 for ietf@ietf.org; Wed, 24 Oct 2007 10:36:16 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkhLD-0006hJ-OB for ietf@ietf.org; Wed, 24 Oct 2007 10:36:16 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9OEa8fo011892; Wed, 24 Oct 2007 17:36:11 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 17:35:11 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 17:35:10 +0300 Received: from [172.21.34.120] (esdhcp034120.research.nokia.com [172.21.34.120]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9OEZ65r025305; Wed, 24 Oct 2007 17:35:09 +0300 In-Reply-To: References: <5.2.1.1.2.20071019165431.018d18c8@pop3.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <08E0F075-B798-4224-A689-8BB1CCE657AD@nokia.com> From: Lars Eggert Date: Wed, 24 Oct 2007 17:35:03 +0300 To: ext Tom Yu X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 24 Oct 2007 14:35:10.0497 (UTC) FILETIME=[14A7F910:01C8164B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Bob Briscoe , tsvwg-chairs@tools.ietf.org, secdir@MIT.EDU, bsd@cisco.com, ietf@ietf.org Subject: Re: secdir review of draft-ietf-tsvwg-ecn-mpls-02.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1438152484==" Errors-To: ietf-bounces@ietf.org --===============1438152484== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-43-180938916; protocol="application/pkcs7-signature" --Apple-Mail-43-180938916 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Authors, if you want to change the draft based on the sec-dir or gen-art reviews, please let me know and either send me a corresponding RFC Editor Note or tell me that you're submitting a new draft. Lars On 2007-10-23, at 9:06, ext Tom Yu wrote: >>>>>> "Bob" == Bob Briscoe writes: > > Bob> Tom, > Bob> You're analysis of the impact on the ECN nonce is accurate. > Below is > Bob> our reasoning for not including the ECN nonce capability in this > Bob> proposal... > > [...] > > Thanks for the detailed rationale of your decision to not include the > ECN nonce. Given that the question of detecting disruption of > end-to-end ECN signaling within an MPLS domain occurred to me from the > mention of RFC3540 in the Security Considerations, other readers of > this document may have similar questions. I suggest that you add a > sentence or two to the Security Considerations summarizing your > decision to exclude the ECN nonce capability from this particular > proposal. However, I will not object to the passage of this document > if you choose not to include such a summary. > > ---Tom --Apple-Mail-43-180938916 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzEwMjQxNDM1MDRaMCMGCSqGSIb3DQEJBDEWBBSx3PYDao48h9FB MV8oSUyko39Q6jCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAvUJJBs2qa2N9NsI35F3cad59bdBEXzakkN1TJu90AJCF/IT2DT3h iC3dirnm2hEcXlIDrWRzlYPGE4OjFfj7U5PF4rSBqa/V22MtZA1IBIC2WVgaEmNPowB6kelGu+I+ M7l/8PKqribdENbUE0TIt+HlRlsisZsx5NNfoHwl6EEzbsQ0bH0kDf+psfNt8gWtLO0q7sE507FZ bsEEKgEzODPh2J0uwi8SM9RLdLLjtXKKPtT6SDXgQMkkxT2OV4qOlN55cMGrgDmM73W0sc0aNsZR xflGUjK/EQGPLC9x8t6aaudXyDYroPqE5XNABY8bcaCrxIY1CoAKQRyUItf/fwAAAAAAAA== --Apple-Mail-43-180938916-- --===============1438152484== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============1438152484==-- From ietf-bounces@ietf.org Wed Oct 24 11:04:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkhdV-0007GK-L6; Wed, 24 Oct 2007 10:55:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkhdT-0007Ek-Qn; Wed, 24 Oct 2007 10:55:07 -0400 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkhdS-0007IH-4B; Wed, 24 Oct 2007 10:55:07 -0400 X-IronPort-AV: E=Sophos;i="4.21,325,1188792000"; d="scan'208";a="73107235" Received: from 14.140.8.135.in-addr.arpa (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-outbound.avaya.com with ESMTP; 24 Oct 2007 10:55:06 -0400 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" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Oct 2007 16:55:02 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-ietf-psamp-framework (A Framework for Packet Selection and Reporting) to Informational RFC Thread-Index: AcgUto1PilTlpT/tTc6GLaZx7bz8wgA3Ev9Q References: From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: psamp@ietf.org Subject: RE: Last Call: draft-ietf-psamp-framework (A Framework for Packet Selection and Reporting) to Informational RFC X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Here are my Technical and Editorial comments:=20 T1: page 19, Section 6.1 - =20 The Metering Process must support inclusion of the following in=20 each Packet Report, as a configurable option:=20 =20 (iii) a basic report on the packet, i.e., some number of=20 contiguous bytes from the start of the packet, including the=20 packet header (which includes link layer, network layer and=20 other encapsulation headers) and some subsequent bytes of=20 the packet payload.=20 In most cases I do not know how an IP-layer networking device like a router can access the link layer header.=20 T2: page 19, Section 6.2 - The value of the DSCP field is worth being added to (iv) T3: page 24, Section 9 - The manageability considerations should include not only information about how to configure the Metering Process, but also how to configure reporting and how to monitor the status of the observation points and of the collectors. Also, are there any alarms situations (congested collectors for example?) T4: Section 11.3 - for psamp-based Passive Performance Measurement to play a role in verification of SLAs, one needs to have the basic metering process parameters be included in the definition of the SLA and how SLA metrics are defined and measured T5: Section 12 Security Considerations - this section seems to me incomplete. For example RFC 3917 describes in its corresponding Security Considerations section the need to deal with the DoS and forgery threats. Similar information should be included here at least by reference - e.g. the need of authenticating collectors, protect against mis-configuration of the metering and reporting processes, etc.=20 E1: The two paragraphs before the Table of Contents should be deleted E2: The text after the Table of Comments until the start of Section 1 duplicates text on page 1 and should be deleted.=20 E3: Section 3.2 - 'Examples include: a line to which a probe is attached, a shared medium, such as an Ethernet-based LAN, a single port of a router, or a set of interfaces (physical or logical) of a router.' - what is a 'port of a router' - is it not equivalent with a physical interface? If so I suggest to make the terminology consistent E4: Section 3.9 - why does the 'most generic' Metering Process include a primitive selector. It seems to me that what is meant here is not the 'most generic' but the most simple or basic Metering Process.=20 E5: Section 4.2 - what means 'cognizant of privacy and anonymity issues'?=20 E6: Section 5.2 - I do not like the definition of systematic count based sampling. It would be better if it was stand-alone and not defined by similarity with systematic time based sampling. In any case, if it based on the later, the definition of systematic time based sampling should come first. Then there is a typo that makes the phrase even harder to understand s/expect / except.=20 E7: the list of filters for the Selection Process in Section 5.2, page 15: What do (iv) and (v) mean? Are these packets that failed Ingress filtering as per RFC2827 (iv) and packets that were detected as out of spec for (v)? Making this clear would help.=20 E8: page 18, Section 5.4 - 'The Attained Selection Fraction can be used to estimate the number bytes present in a portion of the Observed Packet Stream. Let b1, b2,..., bn be the bytes reported in each of the packets that reached the Collector ...' s/number bytes/number of bytes/ and s/be the bytes/be the number of bytes/ E9: page 24, Section 9 - s/writeable MIB module/MIB module with writeable objects/ E10: Section 10 - The first paragraph is duplicated E11: Section 10.2 - The first phrase in the section could be dropped E12: Section 10.2 - Expand ASIC Thanks and Regards, Dan =20 =20 > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org]=20 > Sent: Monday, October 22, 2007 4:06 PM > To: IETF-Announce > Cc: psamp@ietf.org > Subject: Last Call: draft-ietf-psamp-framework (A Framework=20 > for Packet Selection and Reporting) to Informational RFC=20 >=20 > The IESG has received a request from the Packet Sampling WG=20 > (psamp) to consider the following document: >=20 > - 'A Framework for Packet Selection and Reporting ' > as an Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and=20 > solicits final comments on this action. Please send=20 > substantive comments to the ietf@ietf.org mailing lists by=20 > 2007-11-05. Exceptionally, comments may be sent to=20 > iesg@ietf.org instead. In either case, please retain the=20 > beginning of the Subject line to allow automated sorting. >=20 > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-psamp-framework-12.txt >=20 >=20 > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dvie > w_id&dTag=3D9292&rfc_flag=3D0 >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 24 11:34:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iki4Z-0003lc-KI; Wed, 24 Oct 2007 11:23:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iki4Y-0003in-0K for ietf@ietf.org; Wed, 24 Oct 2007 11:23:06 -0400 Received: from ppsw-8.csi.cam.ac.uk ([131.111.8.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iki4N-00020N-C8 for ietf@ietf.org; Wed, 24 Oct 2007 11:23:02 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:38591) by ppsw-8.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Iki3w-0004Hi-QB (Exim 4.67) (return-path ); Wed, 24 Oct 2007 16:22:28 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Iki3w-00074J-3A (Exim 4.67) (return-path ); Wed, 24 Oct 2007 16:22:28 +0100 Date: Wed, 24 Oct 2007 16:22:28 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Sam Hartman In-Reply-To: Message-ID: References: <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Simon Josefsson , ietf@ietf.org Subject: Re: When is using patented technology appropriate? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Tue, 23 Oct 2007, Sam Hartman wrote: > > However I feel there is something pathalogical going on in the open > source community surrounding patents. People are willing to use > technologies that probably have patents but are unwilling to use > technologies that clearly have patents and that have a long track record > of not particularly being enforced. I get worried when I see that > spilling into the IETF. Past behaviour is not a predictor of future behaviour, e.g. GIF. Tony. -- f.a.n.finch http://dotat.at/ SOUTHEAST ICELAND: NORTHERLY 5 AT FIRST IN EAST, OTHERWISE SOUTHEASTERLY 4 OR 5 INCREASING 6 OR 7. MODERATE OR ROUGH. RAIN LATER. GOOD, OCCASIONALLY MODERATE LATER. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 24 11:40:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkiCL-0003iB-O4; Wed, 24 Oct 2007 11:31:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkiCJ-0003hc-E9 for ietf@ietf.org; Wed, 24 Oct 2007 11:31:07 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkiCD-0002Ie-D7 for ietf@ietf.org; Wed, 24 Oct 2007 11:31:07 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AD18E4A45; Wed, 24 Oct 2007 11:30:44 -0400 (EDT) From: Sam Hartman To: Simon Josefsson References: <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> <87fy00vn1l.fsf@mocca.josefsson.org> Date: Wed, 24 Oct 2007 11:30:44 -0400 In-Reply-To: <87fy00vn1l.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed, 24 Oct 2007 12:12:38 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ietf@ietf.org Subject: Re: When is using patented technology appropriate? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>>>> "Simon" == Simon Josefsson writes: Simon> Sam Hartman writes: >>>>>>> "Simon" == Simon Josefsson writes: >> Simon> "Frank Ellermann" writes: >> >> Simon Josefsson wrote: >>> I would even consider a >> requirement that in order to move >>> beyond Proposed Standard, >> a protocol needs to have a free >>> implementation available. >> >> Tricky, e.g. my BOCU-1 implementation is "free" in a certain >> >> sense, but I'm also sure that I don't have a license. >> Simon> Do you refer to the IBM patent on BOCU? As far as I have Simon> understood, IBM promised to grant a free patent license to Simon> people who requested it, but people never received a Simon> license despite requesting one. If this is accurate, I Simon> think it is a good example of a technology that should not Simon> be standardized and should not be promoted by the Simon> community. >> It seems very unlikely to me that IBM would choose to assert >> such a patent against an implementation after having promised >> to give a free license. Simon> If you replace IBM with 'A Patent Troll', do you think the Simon> same holds? I think that such behavior should be presumed not to be a patent troll. Patent trolls are not known forpromising to give away royalty-free licenses. Simon> I think not. If the IETF is going to have a Simon> policy on this, I believe it is important for the policy to Simon> treat everyone the same. The IETf should treat everyone the same. However when we decide whether we are willing to implement using a patented technology, we as implementers consider a lot of factors. I think that the history of the patent and probably even the company needs to be considered there. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 24 11:41:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkiEs-0007Sh-OG; Wed, 24 Oct 2007 11:33:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkiEq-0007JN-I4 for ietf@ietf.org; Wed, 24 Oct 2007 11:33:44 -0400 Received: from mailout00.controlledmail.com ([72.81.252.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkiEq-00007O-8f for ietf@ietf.org; Wed, 24 Oct 2007 11:33:44 -0400 Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id DCC535CC0F4 for ; Wed, 24 Oct 2007 15:33:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1193240023; bh=vcQuyqbLCDcMN2gaaaGgZD53yfsuyziOyLRg21c QG2o=; h=Received:From:Organization:To:Subject:Date:User-Agent: References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-Disposition:Message-Id: X-AV-Checked; b=Ju79+rGjSIcWuXYUlHuJErPVT73fGyj4kYQz9pGNxlwHa4aw4o nlq870Dlznl3vjQjD+ncVfe83PLSxnJBzpTOViOQ5sccNdgRVJVYnSgzR1xA2uD8e5q tC1ZYpV5PxzPI+iY1FNjyU4FESN7y90J5r5Sv2n0pDBO7FmFHfw2vg= Received: from [192.168.111.102] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by mailout00.controlledmail.com (Postfix) with ESMTP id AF3075CC0E9 for ; Wed, 24 Oct 2007 15:33:43 +0000 (UTC) From: Scott Kitterman Organization: Kitterman Technical Services To: ietf@ietf.org Date: Wed, 24 Oct 2007 11:33:40 -0400 User-Agent: KMail/1.9.5 References: <8138-SnapperMsgD8DB99B6C3444D0A@[70.195.169.164]> <20071024105010.90F0622024E@quill.bollow.ch> In-Reply-To: <20071024105010.90F0622024E@quill.bollow.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710241133.41148.scott@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Wednesday 24 October 2007 06:50, Norbert Bollow wrote: > Scott Kitterman wrote: > > And that will never fly (IANAL) with the GPL and so here we sit at an > > impasse again. So either a GPL implementation is important to > > interoperability in a given space or it is not. If it is important to > > interoperabilty, then this is a showstopper. If not, maybe not. > > Do you have any specific example of an internet standard for which you > think that lack of GPL-compatible licensing of any (perhaps just > hypothetical) relevant patents would not cause interoperability serious > problems if the patent holder chose to aggressive enforce the terms of > that non-GPL-compatible patent license? > No. My point was that for the IETF, interoperability is the goal, not some general statement about goodness of Free software. In many/most/maybe all cases, this will require any IPR restrictions to be GPL compatible. Scott K _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 24 12:35:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikj5H-0005ET-H5; Wed, 24 Oct 2007 12:27:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikj5F-0005Di-SM for ietf@ietf.org; Wed, 24 Oct 2007 12:27:53 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikj59-0004fK-KA for ietf@ietf.org; Wed, 24 Oct 2007 12:27:53 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9OGRYoO028247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Oct 2007 09:27:35 -0700 Received: from [98.207.5.180] (vpn-10-50-0-224.qualcomm.com [10.50.0.224]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9OGRWbe007143; Wed, 24 Oct 2007 09:27:33 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <20071024001024.GA6404@thunk.org> References: <18205.60884.253199.882840@swbmbp.local> <2788466ED3E31C418E9ACC5C31661557084F00@mou1wnexmb09.vcorp.ad.vrsn.com> <20071024001024.GA6404@thunk.org> Date: Wed, 24 Oct 2007 09:27:31 -0700 To: Theodore Tso From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Sam Hartman , ietf@ietf.org Subject: Re: A priori IPR choices [Re: Third LastCall:draft-housley-tls-authz-extns] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 8:10 PM -0400 10/23/07, Theodore Tso wrote: >On Tue, Oct 23, 2007 at 01:04:32PM -0700, Ted Hardie wrote: >> I believe it is fairer to recognize that in your example proposal B >> is known to have been patented where A is not. There is always the >> chance that someone will turn out to have secured rights which they >> later claim read on A. In that case it may actually be better to >> choose B, knowing that the license offered works for the development >> and deployment community than to choose A. In other words, a >> "defensive" patent declaration by someone whose license works for >> the appropriate community may actually add security. It doesn't >> completely remove the risk that someone will turn up with other >> rights, but it really can help. > >This doesn't follow. Just because a company has patents that read on >B doesn't guarantee some other company *also* has patents that read on >B. So you can't say with certainty choosing path B is better than >path A just because a company has already declared they have patents >that read on B. Yes, this was the case I was thinking of when I said it does not fully remove the risk. What it can give you, though, is a company whose interests in the patent they have been granted may cause them to challenge later patents which read on the same technology. I am not a lawyer, but I believe it can also go to the "willful infringement" test. If you have a license from company A that covers a technology and B and C are also granted patents to the same technology (your compression algorithm case), then I find it hard to believe that you could be found willful in your infringements of B and C's patents. As I said, though, I'm not a lawyer and I'd ask one before I made that statement to a working group facing the problem. >The US Patent Office may have simply issued two patents on the >identical technology (I believe the cannonical example is the case >where three patents were issued covering the same compression >algorithm). Or there may have been other aspects of B that happened >to be patented by another company, and if it is currently owned by a >Patent Troll who has no interest in participating in the IETF process, >there is no way for the working group to know about the Patent Troll's >patents. I don't think we even have to get to "patent troll" before we find this problem. There are lots of folks involved in developing technology who do not participate in the IETF. If a sound engineering company develops a compression algorithm that turns out to be really useful in compressing byte streams, it might get used by a WG without recognition that the patent exists. When the coverage is later discovered, the industry has to deal with it. regards, Ted _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 24 12:35:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikiup-0007UG-Uy; Wed, 24 Oct 2007 12:17:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikiun-0007Ql-OL for ietf@ietf.org; Wed, 24 Oct 2007 12:17:05 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikiuh-0004E5-GT for ietf@ietf.org; Wed, 24 Oct 2007 12:17:05 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9OGGgns005017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Oct 2007 09:16:43 -0700 Received: from [98.207.5.180] (vpn-10-50-0-224.qualcomm.com [10.50.0.224]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9OGGeeZ015941; Wed, 24 Oct 2007 09:16:42 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <200710241133.41148.scott@kitterman.com> References: <8138-SnapperMsgD8DB99B6C3444D0A@[70.195.169.164]> <20071024105010.90F0622024E@quill.bollow.ch> <200710241133.41148.scott@kitterman.com> Date: Wed, 24 Oct 2007 09:16:39 -0700 To: Scott Kitterman , ietf@ietf.org From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -4.0 (----) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >No. My point was that for the IETF, interoperability is the goal, not some >general statement about goodness of Free software. In many/most/maybe all >cases, this will require any IPR restrictions to be GPL compatible. Can you think of an open-source project interested in the work of CCAMP? That was one of the examples neither Sam nor I could immediately come up with, but I'd be interested in hearing if it is just too far off my stomping grounds. The point being, of course, that there is a world of difference between "many" and "all" here. If there is no development community using the GPL in an area, forcing the IPR restrictions to meet a GPL test may hinder development rather than enhance it, especially in cases where the only requirement in a license is to request it. For many development communities, that is not an issue since it requires no monetary outlay. Speaking only for myself, regards, Ted _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 24 13:21:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikje3-0003Hr-6y; Wed, 24 Oct 2007 13:03:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikje0-00034j-Tx for ietf@ietf.org; Wed, 24 Oct 2007 13:03:48 -0400 Received: from mail26i.sbc-webhosting.com ([216.173.236.230]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ikjdq-0005uo-My for ietf@ietf.org; Wed, 24 Oct 2007 13:03:44 -0400 Received: from mx09.stngva01.us.mxservers.net (204.202.242.68) by mail26i.sbc-webhosting.com (RS ver 1.0.95vs) with SMTP id 0-0233305410 for ; Wed, 24 Oct 2007 13:03:31 -0400 (EDT) Received: from mmm2630.sbc-webhosting.com [216.173.237.89] (EHLO mmm2630.sbc-webhosting.com) by mx09.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id 2ea7f174.18009.128.mx09.stngva01.us.mxservers.net; Wed, 24 Oct 2007 13:03:30 -0400 (EDT) Received: (qmail 9196 invoked from network); 24 Oct 2007 17:03:27 -0000 Received: from unknown (HELO LROSENTOSHIBA) (lrosen@208.106.45.202) by with ESMTPA; 24 Oct 2007 17:03:27 -0000 From: "Lawrence Rosen" To: References: <8138-SnapperMsgD8DB99B6C3444D0A@[70.195.169.164]><20071024105010.90F0622024E@quill.bollow.ch><200710241133.41148.scott@kitterman.com> Date: Wed, 24 Oct 2007 10:02:23 -0700 Organization: Rosenlaw & Einschlag Message-ID: <007001c8165f$a6007090$6401a8c0@LROSENTOSHIBA> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AcgWW7VS3Oj+BzavQeypibzlxs7UwQAAcLxQ X-Spam: [F=0.0043103448; heur=0.500(-26100); stat=0.010; spamtraq-heur=0.300(2007101727)] X-MAIL-FROM: X-SOURCE-IP: [216.173.237.89] X-SF-Loop: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: RE: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lrosen@rosenlaw.com List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Ted Hardie wrote: > The point being, of course, that there is a world of difference between > "many" and "all" here. If there is no development community using > the GPL in an area, forcing the IPR restrictions to meet a GPL test > may hinder development rather than enhance it, especially in > cases where the only requirement in a license is to request it. > For many development communities, that is not an issue since it > requires no monetary outlay. Will you please stop talking about GPL as if it is the only open source license relevant here! My concern is that *all* free and open source licensors be able to implement IETF specifications without patent encumbrances. And *all* proprietary licensors too, for that matter. There ought to be no "GPL test" for IETF specifications, other than that our specifications be implementable and distributable under the GPL *and any other* license. As for setting our IPR policy based on whether there be an actual GPL (or other specific license) implementation at the time the specification is being created and approved, that's a strange proposal. The freedom and openness we seek is for implementations of IETF specifications now *or in the future*. We may not be using GPL now, but maybe someone will want to later. Why shouldn't IETF's IPR policy be compatible with that? /Larry > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Wednesday, October 24, 2007 9:17 AM > To: Scott Kitterman; ietf@ietf.org > Subject: Re: A priori IPR choices > > >No. My point was that for the IETF, interoperability is the goal, not > some > >general statement about goodness of Free software. In many/most/maybe > all > >cases, this will require any IPR restrictions to be GPL compatible. > > Can you think of an open-source project interested in the work of CCAMP? > That was one of the examples neither Sam nor I could immediately > come up with, but I'd be interested in hearing if it is just too far off > my > stomping grounds. > > The point being, of course, that there is a world of difference between > "many" and "all" here. If there is no development community using > the GPL in an area, forcing the IPR restrictions to meet a GPL test > may hinder development rather than enhance it, especially in > cases where the only requirement in a license is to request it. > For many development communities, that is not an issue since it > requires no monetary outlay. > > Speaking only for myself, > regards, > Ted > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 24 14:19:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkkYc-0008Ry-Gw; Wed, 24 Oct 2007 14:02:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkkYa-0008Ra-Oc for ietf@ietf.org; Wed, 24 Oct 2007 14:02:16 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkkYP-0007wl-AX for ietf@ietf.org; Wed, 24 Oct 2007 14:02:10 -0400 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l9OHwCpN026273; Wed, 24 Oct 2007 10:58:12 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Oct 2007 11:01:14 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 24 Oct 2007 11:01:13 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557084F05@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A priori IPR choices Thread-Index: AcgWVA0JKk9sOkIXTTmI4Jp2o6KZwgAD9eQh References: <8138-SnapperMsgD8DB99B6C3444D0A@[70.195.169.164]><20071024105010.90F0622024E@quill.bollow.ch> <200710241133.41148.scott@kitterman.com> From: "Hallam-Baker, Phillip" To: "Scott Kitterman" , X-OriginalArrivalTime: 24 Oct 2007 18:01:14.0015 (UTC) FILETIME=[DDE31AF0:01C81667] X-Spam-Score: -2.2 (--) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: Subject: RE: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1783434991==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============1783434991== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81667.DDCDA231" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81667.DDCDA231 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable GPL would not be a criterion I would consider reasonable. And in = particular I would not accept the idea that the IETF or any other body = be committed to whatever notions insert themselves into RMS in the = future. I have actually met RMS. =20 What I would like to do here is to arrive at a set of terms that is = considered to be sufficiently RANDZ to be sufficiently compatible with = the consensus amongst open source developers. At the moment I do not see = a consensus in favor of GPL 3.0.=20 =20 Having seen a WG crash and burn after theological discussions over open = source license compatibility I would like to see an IETF level consensus = that terms X are sufficiently open for most purposes. If someone had a = reason to beleive that these were not sufficient in a specific working = group for specific reasons these could then be argued in the WG if there = was a WG consensus that this was necessary.=20 =20 Contrawise if someone were to argue that there was a case that made it = necessary to accept RAND terms with a paid license this would also be an = option but one that I would expect to be the rare exception which is the = reason I started my example 'absent a compelling technical case'. =20 =20 Most of the IPR that becomes troublesome was originally filed as = defensive. I am going to be filing a lot more patent applications in the = future, the main business case for doing so being to reduce (not = eliminate) patent liability exposure. I would like to have the licensing = criteria established at the time we make the application, not three = times (on application, on starting work in WG, on finalizing work in WG) = with possibly different lawyers. =20 =20 =20 ________________________________ From: Scott Kitterman [mailto:scott@kitterman.com] Sent: Wed 24/10/2007 11:33 AM To: ietf@ietf.org Subject: Re: A priori IPR choices On Wednesday 24 October 2007 06:50, Norbert Bollow wrote: > Scott Kitterman wrote: > > And that will never fly (IANAL) with the GPL and so here we sit at = an > > impasse again. So either a GPL implementation is important to > > interoperability in a given space or it is not. If it is important = to > > interoperabilty, then this is a showstopper. If not, maybe not. > > Do you have any specific example of an internet standard for which you > think that lack of GPL-compatible licensing of any (perhaps just > hypothetical) relevant patents would not cause interoperability = serious > problems if the patent holder chose to aggressive enforce the terms of > that non-GPL-compatible patent license? > No. My point was that for the IETF, interoperability is the goal, not = some general statement about goodness of Free software. In many/most/maybe = all cases, this will require any IPR restrictions to be GPL compatible. Scott K _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ------_=_NextPart_001_01C81667.DDCDA231 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: A priori IPR choices=0A= =0A= =0A= =0A=
=0A=
GPL would not = be a criterion I would consider reasonable. And in particular I would = not accept the idea that the IETF or any other body be committed to = whatever notions insert themselves into RMS in the future. I have = actually met RMS.
=0A=
 
=0A=
What I would like to do here = is to arrive at a set of terms that is considered to be sufficiently = RANDZ to be sufficiently compatible with the consensus amongst open = source developers. At the moment I do not see a consensus in favor of = GPL 3.0.
=0A=
 
=0A=
Having seen a WG crash and = burn after theological discussions over open source license = compatibility I would like to see an IETF level consensus that terms X = are sufficiently open for most purposes. If someone had a reason to = beleive that these were not sufficient in a specific working group for = specific reasons these could then be argued in the WG if there was a WG = consensus that this was necessary.
=0A=
 
=0A=
Contrawise if someone were to = argue that there was a case that made it necessary to accept RAND terms = with a paid license this would also be an option but one that I would = expect to be the rare exception which is the reason I started my example = 'absent a compelling technical case'.
=0A=
 
=0A=
 
=0A=
Most of the IPR that becomes = troublesome was originally filed as defensive. I am going to be filing a = lot more patent applications in the future, the main business case for = doing so being to reduce (not eliminate) patent liability = exposure. I would like to have the licensing criteria established = at the time we make the application, not three times (on application, on = starting work in WG, on finalizing work in WG) with possibly different = lawyers.
=0A=
 
=0A=
 
=0A=
 
=0A=
=0A=
=0A=
=0A=
From: Scott Kitterman = [mailto:scott@kitterman.com]
Sent: Wed 24/10/2007 11:33 = AM
To: ietf@ietf.org
Subject: Re: A priori IPR = choices

=0A=
=0A=

On Wednesday 24 October 2007 06:50, Norbert Bollow = wrote:
> Scott Kitterman <scott@kitterman.com> = wrote:
> > And that will never fly (IANAL) with the GPL and so = here we sit at an
> > impasse again.  So either a GPL = implementation is important to
> > interoperability in a given = space or it is not.  If it is important to
> > = interoperabilty, then this is a showstopper.  If not, maybe = not.
>
> Do you have any specific example of an internet = standard for which you
> think that lack of GPL-compatible = licensing of any (perhaps just
> hypothetical) relevant patents = would not cause interoperability serious
> problems if the patent = holder chose to aggressive enforce the terms of
> that = non-GPL-compatible patent license?
>
No.  My point was = that for the IETF, interoperability is the goal, not some
general = statement about goodness of Free software.  In many/most/maybe = all
cases, this will require any IPR restrictions to be GPL = compatible.

Scott = K

_______________________________________________
Ietf mailing = list
Ietf@ietf.org
https://www1.ietf.or= g/mailman/listinfo/ietf

------_=_NextPart_001_01C81667.DDCDA231-- --===============1783434991== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============1783434991==-- From ietf-bounces@ietf.org Wed Oct 24 14:51:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikl5x-0000vF-P7; Wed, 24 Oct 2007 14:36:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikl5w-0000nY-D7 for ietf@ietf.org; Wed, 24 Oct 2007 14:36:44 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikl5p-0005bN-PE for ietf@ietf.org; Wed, 24 Oct 2007 14:36:38 -0400 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l9OIWjgV019277; Wed, 24 Oct 2007 11:32:45 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Oct 2007 11:36:16 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 24 Oct 2007 11:33:39 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557084F08@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FYI 28 (was: A priori IPR choices) Thread-Index: AcgWN8XFOUkz8ZVHTx+3+zUTZC/HXgANJ9tj References: <001d01c815e8$b2b966b0$6401a8c0@LROSENTOSHIBA><015101c81624$3357e090$0a01a8c0@rodage.dyndns.org> From: "Hallam-Baker, Phillip" To: "Frank Ellermann" , X-OriginalArrivalTime: 24 Oct 2007 18:36:16.0345 (UTC) FILETIME=[C2F93490:01C8166C] X-Spam-Score: 1.8 (+) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: license-discuss@opensource.org Subject: RE: FYI 28 (was: A priori IPR choices) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1489105463==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============1489105463== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8166C.C2DA2CE1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8166C.C2DA2CE1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Not as out of date as some sources =20 http://davidguy.brinkster.net/computer/ =20 It was my first computer book. ________________________________ From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] Sent: Wed 24/10/2007 7:58 AM To: ietf@ietf.org Cc: license-discuss@opensource.org Subject: FYI 28 (was: A priori IPR choices) Philippe Verdy wrote: > We do have lots of informational RFCs which are still needed and > actively used, sometimes even required (notably those in the BCP > series, like the "Netiquette" which has become a requirement for > almost all ISP customers, as part of their contract, despite they > are only informational, and could change at any time after having > been replaced by another RFC replacing the older one with the same > BCP number. BCPs aren't informational RFCs, for an introduction see RFC 4677 or . Maybe you confused BCP with FYI, RFC 1855 is also known as FYI 28. FLAME ON: It's now 12 years old, and some parts are rather silly: Be careful with monospacing fonts, and be sure to have a signature which you attach to your message. FLAME OFF (flame tags recommended by FYI 28). Frank _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ------_=_NextPart_001_01C8166C.C2DA2CE1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI 28 (was: A priori IPR choices)=0A= =0A= =0A= =0A=
=0A=
Not as out of = date as some sources
=0A=
 
=0A=
=0A=
 
=0A=
It was my first computer book.
=0A=

=0A=
=0A= From: Frank Ellermann = [mailto:nobody@xyzzy.claranet.de]
Sent: Wed 24/10/2007 7:58 = AM
To: ietf@ietf.org
Cc: = license-discuss@opensource.org
Subject: FYI 28 (was: A priori = IPR choices)

=0A=
=0A=

Philippe Verdy wrote:

> We do have lots of = informational RFCs which are still needed and
> actively used, = sometimes even required (notably those in the BCP
> series, like = the "Netiquette" which has become a requirement for
> almost all = ISP customers, as part of their contract, despite they
> are only = informational, and could change at any time after having
> been = replaced by another RFC replacing the older one with the same
> = BCP number.

BCPs aren't informational RFCs, for an introduction = see RFC 4677
or <http://= en.wikipedia.org/wiki/Request_for_Comments#Status>.
Maybe you = confused BCP with FYI, RFC 1855 is also known as FYI 28.

FLAME = ON: It's now 12 years old, and some parts are rather silly:
Be = careful with monospacing fonts, and be sure to have a signature
which = you attach to your message.
FLAME OFF (flame tags recommended by FYI = 28).

 Frank


______________________________________= _________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.or= g/mailman/listinfo/ietf

------_=_NextPart_001_01C8166C.C2DA2CE1-- --===============1489105463== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============1489105463==-- From ietf-bounces@ietf.org Wed Oct 24 15:21:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IklXZ-0000Z4-9c; Wed, 24 Oct 2007 15:05:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IklXY-0000YZ-3h for ietf@ietf.org; Wed, 24 Oct 2007 15:05:16 -0400 Received: from mailout00.controlledmail.com ([72.81.252.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IklXX-0006jl-Ou for ietf@ietf.org; Wed, 24 Oct 2007 15:05:16 -0400 Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 7D6EC5CC0F4 for ; Wed, 24 Oct 2007 19:05:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1193252715; bh=ELJbNNwZ87GTMGjiLYs6RdcK6Xe4ULriXLFIBbR S/f4=; h=Received:From:Organization:To:Subject:Date:User-Agent: References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-Disposition:Message-Id: X-AV-Checked; b=FmdAwTJMeHaK5y1YA/pKeFqvs3rsMdySEC8eofyQ//zVA4pOJ1 iNFFH4r3iKNkRB6Qc/JhaFwhjVVCLX7Z2cwctJV6eazs57h6xGo4k/Kdedk52Bdwq8y Mg6eViCRz7KQoLzNLkPyGfG8ha8Fi+NEoa/Pb2u0KvZ4sLW2C5mO0Q= Received: from [192.168.111.102] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by mailout00.controlledmail.com (Postfix) with ESMTP id 6A0475CC08D for ; Wed, 24 Oct 2007 19:05:15 +0000 (UTC) From: Scott Kitterman Organization: Kitterman Technical Services To: ietf@ietf.org Date: Wed, 24 Oct 2007 15:05:12 -0400 User-Agent: KMail/1.9.5 References: <200710241133.41148.scott@kitterman.com> <2788466ED3E31C418E9ACC5C31661557084F05@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <2788466ED3E31C418E9ACC5C31661557084F05@mou1wnexmb09.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710241505.13295.scott@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Wednesday 24 October 2007 14:01, Hallam-Baker, Phillip wrote: > GPL would not be a criterion I would consider reasonable. And in particular > I would not accept the idea that the IETF or any other body be committed to > whatever notions insert themselves into RMS in the future. I have actually > met RMS. > > What I would like to do here is to arrive at a set of terms that is > considered to be sufficiently RANDZ to be sufficiently compatible with the > consensus amongst open source developers. At the moment I do not see a > consensus in favor of GPL 3.0. > > Having seen a WG crash and burn after theological discussions over open > source license compatibility I would like to see an IETF level consensus > that terms X are sufficiently open for most purposes. If someone had a > reason to beleive that these were not sufficient in a specific working > group for specific reasons these could then be argued in the WG if there > was a WG consensus that this was necessary. I'd say it entirely depends. I can understand not wanting to hitch your wagon to any particular individual's view of the future of licensing. OTOH, where GPL software represents a significant fragment of the internet landscape, you have to (I think) accept GPL compatible licensing terms or give up on interoperability. BTW, I think Yahoo!'s revised DomainKeys license solvFrom ietf-bounces@ietf.org Wed Oct 24 15:21:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IklXZ-0000Z4-9c; Wed, 24 Oct 2007 15:05:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IklXY-0000YZ-3h for ietf@ietf.org; Wed, 24 Oct 2007 15:05:16 -0400 Received: from mailout00.controlledmail.com ([72.81.252.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IklXX-0006jl-Ou for ietf@ietf.org; Wed, 24 Oct 2007 15:05:16 -0400 Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 7D6EC5CC0F4 for ; Wed, 24 Oct 2007 19:05:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1193252715; bh=ELJbNNwZ87GTMGjiLYs6RdcK6Xe4ULriXLFIBbR S/f4=; h=Received:From:Organization:To:Subject:Date:User-Agent: References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-Disposition:Message-Id: X-AV-Checked; b=FmdAwTJMeHaK5y1YA/pKeFqvs3rsMdySEC8eofyQ//zVA4pOJ1 iNFFH4r3iKNkRB6Qc/JhaFwhjVVCLX7Z2cwctJV6eazs57h6xGo4k/Kdedk52Bdwq8y Mg6eViCRz7KQoLzNLkPyGfG8ha8Fi+NEoa/Pb2u0KvZ4sLW2C5mO0Q= Received: from [192.168.111.102] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by mailout00.controlledmail.com (Postfix) with ESMTP id 6A0475CC08D for ; Wed, 24 Oct 2007 19:05:15 +0000 (UTC) From: Scott Kitterman Organization: Kitterman Technical Services To: ietf@ietf.org Date: Wed, 24 Oct 2007 15:05:12 -0400 User-Agent: KMail/1.9.5 References: <200710241133.41148.scott@kitterman.com> <2788466ED3E31C418E9ACC5C31661557084F05@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <2788466ED3E31C418E9ACC5C31661557084F05@mou1wnexmb09.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710241505.13295.scott@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Wednesday 24 October 2007 14:01, Hallam-Baker, Phillip wrote: > GPL would not be a criterion I would consider reasonable. And in particular > I would not accept the idea that the IETF or any other body be committed to > whatever notions insert themselves into RMS in the future. I have actually > met RMS. > > What I would like to do here is to arrive at a set of terms that is > considered to be sufficiently RANDZ to be sufficiently compatible with the > consensus amongst open source developers. At the moment I do not see a > consensus in favor of GPL 3.0. > > Having seen a WG crash and burn after theological discussions over open > source license compatibility I would like to see an IETF level consensus > that terms X are sufficiently open for most purposes. If someone had a > reason to beleive that these were not sufficient in a specific working > group for specific reasons these could then be argued in the WG if there > was a WG consensus that this was necessary. I'd say it entirely depends. I can understand not wanting to hitch your wagon to any particular individual's view of the future of licensing. OTOH, where GPL software represents a significant fragment of the internet landscape, you have to (I think) accept GPL compatible licensing terms or give up on interoperability. BTW, I think Yahoo!'s revised DomainKeys license solves this is a useful way that may have more general utility. Scott K _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 24 15:21:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IklXM-0000PB-8o; Wed, 24 Oct 2007 15:05:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IklXK-0000Ou-UU for ietf@ietf.org; Wed, 24 Oct 2007 15:05:02 -0400 Received: from ppsw-4.csi.cam.ac.uk ([131.111.8.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IklXE-00026g-Oe for ietf@ietf.org; Wed, 24 Oct 2007 15:05:02 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:53490) by ppsw-4.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.154]:25) with esmtpa (EXTERNAL:fanf2) id 1IklWy-0000wd-Cy (Exim 4.63) (return-path ); Wed, 24 Oct 2007 20:04:40 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1IklWy-0002vv-07 (Exim 4.67) (return-path ); Wed, 24 Oct 2007 20:04:40 +0100 Date: Wed, 24 Oct 2007 20:04:40 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: "Hallam-Baker, Phillip" In-Reply-To: <2788466ED3E31C418E9ACC5C31661557084F05@mou1wnexmb09.vcorp.ad.vrsn.com> Message-ID: References: <8138-SnapperMsgD8DB99B6C3444D0A@[70.195.169.164]><20071024105010.90F0622024E@quill.bollow.ch> <200710241133.41148.scott@kitterman.com> <2788466ED3E31C418E9ACC5C31661557084F05@mou1wnexmb09.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ietf@ietf.org Subject: RE: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Wed, 24 Oct 2007, Hallam-Baker, Phillip wrote: > GPL would not be a criterion I would consider reasonable. And in > particular I would not accept the idea that the IETF or any other body > be committed to whatever notions insert themselves into RMS in the > future. There are plenty of much less rabid open source licences which have similar approaches to patents as the GPL: see the Apache licence version 2 or the Mozilla Public Licence version 1.1, both of which include non-bureaucratic patent licensing and anti-litigation clauses. Tony. -- f.a.n.finch http://dotat.at/ LUNDY FASTNET IRISH SEA: EAST OR SOUTHEAST 3 OR 4. SLIGHT OR MODERATE. FAIR. MODERATE OR GOOD. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf es this is a useful way that may have more general utility. Scott K _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 24 15:21:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IklXM-0000PB-8o; Wed, 24 Oct 2007 15:05:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IklXK-0000Ou-UU for ietf@ietf.org; Wed, 24 Oct 2007 15:05:02 -0400 Received: from ppsw-4.csi.cam.ac.uk ([131.111.8.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IklXE-00026g-Oe for ietf@ietf.org; Wed, 24 Oct 2007 15:05:02 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:53490) by ppsw-4.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.154]:25) with esmtpa (EXTERNAL:fanf2) id 1IklWy-0000wd-Cy (Exim 4.63) (return-path ); Wed, 24 Oct 2007 20:04:40 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1IklWy-0002vv-07 (Exim 4.67) (return-path ); Wed, 24 Oct 2007 20:04:40 +0100 Date: Wed, 24 Oct 2007 20:04:40 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: "Hallam-Baker, Phillip" In-Reply-To: <2788466ED3E31C418E9ACC5C31661557084F05@mou1wnexmb09.vcorp.ad.vrsn.com> Message-ID: References: <8138-SnapperMsgD8DB99B6C3444D0A@[70.195.169.164]><20071024105010.90F0622024E@quill.bollow.ch> <200710241133.41148.scott@kitterman.com> <2788466ED3E31C418E9ACC5C31661557084F05@mou1wnexmb09.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ietf@ietf.org Subject: RE: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Wed, 24 Oct 2007, Hallam-Baker, Phillip wrote: > GPL would not be a criterion I would consider reasonable. And in > particular I would not accept the idea that the IETF or any other body > be committed to whatever notions insert themselves into RMS in the > future. There are plenty of much less rabid open source licences which have similar approaches to patents as the GPL: see the Apache licence version 2 or the Mozilla Public Licence version 1.1, both of which include non-bureaucratic patent licensing and anti-litigation clauses. Tony. -- f.a.n.finch http://dotat.at/ LUNDY FASTNET IRISH SEA: EAST OR SOUTHEAST 3 OR 4. SLIGHT OR MODERATE. FAIR. MODERATE OR GOOD. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 24 15:44:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IklyI-00046m-Ua; Wed, 24 Oct 2007 15:32:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IklyE-0003zp-Jl for ietf@ietf.org; Wed, 24 Oct 2007 15:32:51 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikly8-00032g-Bc for ietf@ietf.org; Wed, 24 Oct 2007 15:32:50 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9OJWWAe023895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Oct 2007 12:32:33 -0700 Received: from [98.207.5.180] (carbuncle.qualcomm.com [129.46.226.27]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9OJWWGt023695; Wed, 24 Oct 2007 12:32:32 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <007001c8165f$a6007090$6401a8c0@LROSENTOSHIBA> References: <8138-SnapperMsgD8DB99B6C3444D0A@[70. 195.169.164]><20071024105010.90F0622024E@quill.bollow.ch><200710241133.411 48.scott@kitterman.com> <007001c8165f$a6007090$6401a8c0@LROSENTOSHIBA> Date: Wed, 24 Oct 2007 12:32:31 -0700 To: lrosen@rosenlaw.com, From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Subject: RE: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 10:02 AM -0700 10/24/07, Lawrence Rosen wrote: >Ted Hardie wrote: >> The point being, of course, that there is a world of difference between >> "many" and "all" here. If there is no development community using >> the GPL in an area, forcing the IPR restrictions to meet a GPL test >> may hinder development rather than enhance it, especially in >> cases where the only requirement in a license is to request it. >> For many development communities, that is not an issue since it >> requires no monetary outlay. > >Will you please stop talking about GPL as if it is the only open source >license relevant here! Sorry, but the context in this part of the thread was specific to the GPL. To refresh your memory on the bits the Brian, Norbert, and Scott put forward that set that context: > >>Norbert wrote: > >> How about: 'Should be possible to implement without having to ask for > >> permission or pay a fee'? > >Brian replied: > >That will never fly. For good reason, many patent holders insist > >on reciprocity conditions, and that seems to require an explicit > >request and acknowledgement. >Scott add: >And that will never fly (IANAL) with the GPL and so here we sit at an >impasse again. So either a GPL implementation is important to >interoperability in a given space or it is not. If it is important to >interoperabilty, then this is a showstopper. If not, maybe not. Hope that helps restore context for you. >My concern is that *all* free and open source >licensors be able to implement IETF specifications without patent >encumbrances. And *all* proprietary licensors too, for that matter. There >ought to be no "GPL test" for IETF specifications, other than that our >specifications be implementable and distributable under the GPL *and any >other* license. The world as it is now simply does include licenses that aren't compatible. As Brian pointed out, reciprocity conditions are common, as are From ietf-bounces@ietf.org Wed Oct 24 15:44:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IklyI-00046m-Ua; Wed, 24 Oct 2007 15:32:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IklyE-0003zp-Jl for ietf@ietf.org; Wed, 24 Oct 2007 15:32:51 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikly8-00032g-Bc for ietf@ietf.org; Wed, 24 Oct 2007 15:32:50 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9OJWWAe023895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Oct 2007 12:32:33 -0700 Received: from [98.207.5.180] (carbuncle.qualcomm.com [129.46.226.27]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9OJWWGt023695; Wed, 24 Oct 2007 12:32:32 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <007001c8165f$a6007090$6401a8c0@LROSENTOSHIBA> References: <8138-SnapperMsgD8DB99B6C3444D0A@[70. 195.169.164]><20071024105010.90F0622024E@quill.bollow.ch><200710241133.411 48.scott@kitterman.com> <007001c8165f$a6007090$6401a8c0@LROSENTOSHIBA> Date: Wed, 24 Oct 2007 12:32:31 -0700 To: lrosen@rosenlaw.com, From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Subject: RE: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 10:02 AM -0700 10/24/07, Lawrence Rosen wrote: >Ted Hardie wrote: >> The point being, of course, that there is a world of difference between >> "many" and "all" here. If there is no development community using >> the GPL in an area, forcing the IPR restrictions to meet a GPL test >> may hinder development rather than enhance it, especially in >> cases where the only requirement in a license is to request it. >> For many development communities, that is not an issue since it >> requires no monetary outlay. > >Will you please stop talking about GPL as if it is the only open source >license relevant here! Sorry, but the context in this part of the thread was specific to the GPL. To refresh your memory on the bits the Brian, Norbert, and Scott put forward that set that context: > >>Norbert wrote: > >> How about: 'Should be possible to implement without having to ask for > >> permission or pay a fee'? > >Brian replied: > >That will never fly. For good reason, many patent holders insist > >on reciprocity conditions, and that seems to require an explicit > >request and acknowledgement. >Scott add: >And that will never fly (IANAL) with the GPL and so here we sit at an >impasse again. So either a GPL implementation is important to >interoperability in a given space or it is not. If it is important to >interoperabilty, then this is a showstopper. If not, maybe not. Hope that helps restore context for you. >My concern is that *all* free and open source >licensors be able to implement IETF specifications without patent >encumbrances. And *all* proprietary licensors too, for that matter. There >ought to be no "GPL test" for IETF specifications, other than that our >specifications be implementable and distributable under the GPL *and any >other* license. The world as it is now simply does include licenses that aren't compatible. As Brian pointed out, reciprocity conditions are common, as are requests to acknowledge. If Scott is right and these won't work with the GPL, working groups will have choices to make about the implementation and deployment communities' needs. This is why we keep pushing the decision into the working groups, rather than making a priori IPR choices: it's the place most likely to know whether a reciprocal license/royalty-bearing license/piece of GPL'ed code in the standards document is actually likely to cause a problem. regards, Ted _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 24 15:44:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iklu9-00039O-Ub; Wed, 24 Oct 2007 15:28:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iklu8-0002oL-DW for ietf@ietf.org; Wed, 24 Oct 2007 15:28:36 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikltr-0002rD-DM for ietf@ietf.org; Wed, 24 Oct 2007 15:28:25 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l9OJO5Wk029838; Wed, 24 Oct 2007 12:24:05 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Oct 2007 12:27:07 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 24 Oct 2007 12:25:36 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557084F09@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A priori IPR choices Thread-Index: AcgWcLFiTai2BRdrSPqgY8vQ9hIIigAAvY9h References: <8138-SnapperMsgD8DB99B6C3444D0A@[70.195.169.164]><20071024105010.90F0622024E@quill.bollow.ch> <200710241133.41148.scott@kitterman.com> <2788466ED3E31C418E9ACC5C31661557084F05@mou1wnexmb09.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: "Tony Finch" X-OriginalArrivalTime: 24 Oct 2007 19:27:07.0333 (UTC) FILETIME=[DD810750:01C81673] X-Spam-Score: -2.2 (--) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ietf@ietf.org Subject: RE: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0474830312==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============0474830312== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81673.DD5587A9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81673.DD5587A9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would accept GPL 2.0, but not GPL without any qualifier such that the = IETF was required to comply with whatever scheme RMS has thought up this = week to reinsert himself at the center of attention. ________________________________ From: Tony Finch on behalf of Tony Finch Sent: Wed 24/10/2007 3:04 PM To: Hallam-Baker, Phillip Cc: ietf@ietf.org Subject: RE: A priori IPR choices On Wed, 24 Oct 2007, Hallam-Baker, Phillip wrote: > GPL would not be a criterion I would consider reasonable. And in > particular I would not accept the idea that the IETF or any other body > be committed to whatever notions insert themselves into RMS in the >requests to acknowledge. If Scott is right and these won't work with the GPL, working groups will have choices to make about the implementation and deployment communities' needs. This is why we keep pushing the decision into the working groups, rather than making a priori IPR choices: it's the place most likely to know whether a reciprocal license/royalty-bearing license/piece of GPL'ed code in the standards document is actually likely to cause a problem. regards, Ted _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 24 15:44:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iklu9-00039O-Ub; Wed, 24 Oct 2007 15:28:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iklu8-0002oL-DW for ietf@ietf.org; Wed, 24 Oct 2007 15:28:36 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikltr-0002rD-DM for ietf@ietf.org; Wed, 24 Oct 2007 15:28:25 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l9OJO5Wk029838; Wed, 24 Oct 2007 12:24:05 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Oct 2007 12:27:07 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 24 Oct 2007 12:25:36 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557084F09@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A priori IPR choices Thread-Index: AcgWcLFiTai2BRdrSPqgY8vQ9hIIigAAvY9h References: <8138-SnapperMsgD8DB99B6C3444D0A@[70.195.169.164]><20071024105010.90F0622024E@quill.bollow.ch> <200710241133.41148.scott@kitterman.com> <2788466ED3E31C418E9ACC5C31661557084F05@mou1wnexmb09.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: "Tony Finch" X-OriginalArrivalTime: 24 Oct 2007 19:27:07.0333 (UTC) FILETIME=[DD810750:01C81673] X-Spam-Score: -2.2 (--) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ietf@ietf.org Subject: RE: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0474830312==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============0474830312== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81673.DD5587A9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81673.DD5587A9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would accept GPL 2.0, but not GPL without any qualifier such that the = IETF was required to comply with whatever scheme RMS has thought up this = week to reinsert himself at the center of attention. ________________________________ From: Tony Finch on behalf of Tony Finch Sent: Wed 24/10/2007 3:04 PM To: Hallam-Baker, Phillip Cc: ietf@ietf.org Subject: RE: A priori IPR choices On Wed, 24 Oct 2007, Hallam-Baker, Phillip wrote: > GPL would not be a criterion I would consider reasonable. And in > particular I would not accept the idea that the IETF or any other body > be committed to whatever notions insert themselves into RMS in the > future. There are plenty of much less rabid open source licences which have similar approaches to patents as the GPL: see the Apache licence version 2 or the Mozilla Public Licence version 1.1, both of which include non-bureaucratic patent licensing and anti-litigation clauses. Tony. -- f.a.n.finch http://dotat.at/ LUNDY FASTNET IRISH SEA: EAST OR SOUTHEAST 3 OR 4. SLIGHT OR MODERATE. = FAIR. MODERATE OR GOOD. ------_=_NextPart_001_01C81673.DD5587A9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: A priori IPR choices=0A= =0A= =0A= =0A=
=0A=
I would = accept GPL 2.0, but not GPL without any qualifier such that the IETF was = required to comply with whatever scheme RMS has thought up this week to = reinsert himself at the center of attention.
=0A=

=0A=
=0A= From: Tony Finch on behalf of Tony = Finch
Sent: Wed 24/10/2007 3:04 PM
To: Hallam-Baker, = Phillip
Cc: ietf@ietf.org
Subject: RE: A priori IPR = choices

=0A=
=0A=

On Wed, 24 Oct 2007, Hallam-Baker, Phillip = wrote:

> GPL would not be a criterion I would consider = reasonable. And in
> particular I would not accept the idea that = the IETF or any other body
> be committed to whatever notions = insert themselves into RMS in the
> future.

There are = plenty of much less rabid open source licences which have
similar = approaches to patents as the GPL: see the Apache licence version
2 or = the Mozilla Public Licence version 1.1, both of which = include
non-bureaucratic patent licensing and anti-litigation = clauses.

Tony.
--
f.a.n.finch  = <dot@dotat.at>  http://dotat.at/
LUNDY FASTNET IRISH = SEA: EAST OR SOUTHEAST 3 OR 4. SLIGHT OR MODERATE. FAIR.
MODERATE OR = GOOD.

------_=_NextPart_001_01C81673.DD5587A9-- --===============0474830312== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0474830312==-- future. There are plenty of much less rabid open source licences which have similar approaches to patents as the GPL: see the Apache licence version 2 or the Mozilla Public Licence version 1.1, both of which include non-bureaucratic patent licensing and anti-litigation clauses. Tony. -- f.a.n.finch http://dotat.at/ LUNDY FASTNET IRISH SEA: EAST OR SOUTHEAST 3 OR 4. SLIGHT OR MODERATE. = FAIR. MODERATE OR GOOD. ------_=_NextPart_001_01C81673.DD5587A9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: A priori IPR choices=0A= =0A= =0A= =0A=
=0A=
I would = accept GPL 2.0, but not GPL without any qualifier such that the IETF was = required to comply with whatever scheme RMS has thought up this week to = reinsert himself at the center of attention.
=0A=

=0A=
=0A= From: Tony Finch on behalf of Tony = Finch
Sent: Wed 24/10/2007 3:04 PM
To: Hallam-Baker, = Phillip
Cc: ietf@ietf.org
Subject: RE: A priori IPR = choices

=0A=
=0A=

On Wed, 24 Oct 2007, Hallam-Baker, Phillip = wrote:

> GPL would not be a criterion I would consider = reasonable. And in
> particular I would not accept the idea that = the IETF or any other body
> be committed to whatever notions = insert themselves into RMS in the
> future.

There are = plenty of much less rabid open source licences which have
similar = approaches to patents as the GPL: see the Apache licence version
2 or = the Mozilla Public Licence version 1.1, both of which = include
non-bureaucratic patent licensing and anti-litigation = clauses.

Tony.
--
f.a.n.finch  = <dot@dotat.at>  http://dotat.at/
LUNDY FASTNET IRISH = SEA: EAST OR SOUTHEAST 3 OR 4. SLIGHT OR MODERATE. FAIR.
MODERATE OR = GOOD.

------_=_NextPart_001_01C81673.DD5587A9-- --===============0474830312== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0474830312==-- From ietf-bounces@ietf.org Wed Oct 24 17:04:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikn84-0003ur-I4; Wed, 24 Oct 2007 16:47:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikn83-0003ch-04 for ietf@ietf.org; Wed, 24 Oct 2007 16:47:03 -0400 Received: from tarsus.bollow.ch ([82.195.230.222]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikn7t-0005VO-PW for ietf@ietf.org; Wed, 24 Oct 2007 16:46:59 -0400 Received: from tarsus.bollow.ch (localhost [127.0.0.1]) by tarsus.bollow.ch (Postfix) with ESMTP id 9EEB9B2802B for ; Wed, 24 Oct 2007 23:22:43 +0200 (CEST) Authentication-Results: tarsus.bollow.ch from=nb@bollow.ch; domainkey=neutral (no signature; no policy for bollow.ch) Received: from quill.bollow.ch (215-4.0-85.cust.bluewin.ch [85.0.4.215]) by tarsus.bollow.ch (Postfix) with ESMTP for ; Wed, 24 Oct 2007 23:22:43 +0200 (CEST) Received: by quill.bollow.ch (Postfix, from userid 1000) id 288C922024E; Wed, 24 Oct 2007 22:49:59 +0200 (CEST) From: Norbert Bollow Organization: Bollow Software Economics Research MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=iso-8859-1 To: ietf@ietf.org In-reply-to: <2788466ED3E31C418E9ACC5C31661557084F09@mou1wnexmb09.vcorp.ad.vrsn.com> (pbaker@verisign.com) References: <8138-SnapperMsgD8DB99B6C3444D0A@[70.195.169.164]><20071024105010.90F0622024E@quill.bollow.ch> <200710241133.41148.scott@kitterman.com> <2788466ED3E31C418E9ACC5C31661557084F05@mou1wnexmb09.vcorp.ad.vrsn.com> <2788466ED3E31C418E9ACC5C31661557084F09@mou1wnexmb09.vcorp.ad.vrsn.com> Message-Id: <20071024204959.288C922024E@quill.bollow.ch> Date: Wed, 24 Oct 2007 22:49:59 +0200 (CEST) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Phillip Hallam-Baker wrote: > I would accept GPL 2.0, but not GPL without any qualifier such that the > IETF was required to comply with whatever scheme RMS has thought up thi= s > week to reinsert himself at the center of attention. I wouldn't have any objections to a policy which establishes the criterion of GPLv2 compatibility in addition to compatibility with proprietary closed-source software. It would IMO be better however to formulate the criterion in a way which avoids explicitly mentioning GPLv2. Rather, I would suggest to adopt a policy formulation that tells as explicitly as possible how to check whether the terms of a patent license or patent non-assertion promise are acceptable. =20 Greetings, Norbert. --=20 Norbert Bollow http://Norbert.ch President of the Swiss Internet User Group SIUG http://SIUG.ch Working on establishing a non-corrupt and truly /open/ international standards organization http://OpenISO.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 24 17:15:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IknPR-0001bN-U6; Wed, 24 Oct 2007 17:05:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IknPQ-0001Zm-CU for ietf@ietf.org; Wed, 24 Oct 2007 17:05:00 -0400 Received: from tarsus.bollow.ch ([82.195.230.222]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IknPO-000657-II for ietf@ietf.org; Wed, 24 Oct 2007 17:05:00 -0400 Received: from tarsus.bollow.ch (localhost [127.0.0.1]) by tarsus.bollow.ch (Postfix) with ESMTP id 68C4EB2807F for ; Wed, 24 Oct 2007 23:41:12 +0200 (CEST) Authentication-Results: tarsus.bollow.ch from=nb@bollow.ch; domainkey=neutral (no signature; no policy for bollow.ch) Received: from quill.bollow.ch (215-4.0-85.cust.bluewin.ch [85.0.4.215]) by tarsus.bollow.ch (Postfix) with ESMTP for ; Wed, 24 Oct 2007 23:41:12 +0200 (CEST) Received: by quill.bollow.ch (Postfix, from userid 1000) id 2545B22024E; Wed, 24 Oct 2007 23:08:28 +0200 (CEST) From: Norbert Bollow Organization: Bollow Software Economics Research MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=iso-8859-1 To: ietf@ietf.org In-reply-to: (message from Ted Hardie on Wed, 24 Oct 2007 09:16:39 -0700) References: <8138-SnapperMsgD8DB99B6C3444D0A@[70.195.169.164]> <20071024105010.90F0622024E@quill.bollow.ch> <200710241133.41148.scott@kitterman.com> Message-Id: <20071024210828.2545B22024E@quill.bollow.ch> Date: Wed, 24 Oct 2007 23:08:28 +0200 (CEST) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Ted Hardie wrote: > >No. My point was that for the IETF, interoperability is the goal, not = some > >general statement about goodness of Free software. In many/most/maybe= all > >cases, this will require any IPR restrictions to be GPL compatible. >=20 > Can you think of an open-source project interested in the work of CCAMP= ? I don't know of an existing open-source project interested in this, but I would suggest that it is very important that it must be possible to start one. Otherwise we deny in particular people in developing countries the freedom to develop, by means of an open-source / free software project, the ability to extend purchased networking equipment with systems of their own design. Greetings, Norbert. --=20 Norbert Bollow http://Norbert.ch President of the Swiss Internet User Group SIUG http://SIUG.ch Working on establishing a non-corrupt and truly /open/ international standards organization http://OpenISO.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 24 17:32:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IknaU-0003Fy-9k; Wed, 24 Oct 2007 17:16:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IknaS-0003Fn-GG for ietf@ietf.org; Wed, 24 Oct 2007 17:16:24 -0400 Received: from rv-out-0910.google.com ([209.85.198.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IknaM-0006Pk-AZ for ietf@ietf.org; Wed, 24 Oct 2007 17:16:24 -0400 Received: by rv-out-0910.google.com with SMTP id l15so259026rvb for ; Wed, 24 Oct 2007 14:16:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=EK/W/7ATNpjGNxGrKpVUekGfgKI7wssH/a69xMWpSm8=; b=CHNF5gPiIsquYh1Osy4yprWngVLR0wJpKf2mUAhFiRQwohPKOL+Y/vLM5eZBnf+fIs6WTVAm2zWp4+3SzXLrPFZTsxKvQOhVK25KtALcdR6FSNkLGYZJgABQouYaB9lBLxTKJsvS0TOfLzxohZdVztxCZB1kyeDqTb6g0zgIwB8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Tvq0O8cG6/ThbaUjdoO0JALu7XNsvS/C9iVvGiBOsQ6GlWr+ld69rGK8iwDHiwDoYIQB/M9K9Jq7m1CLA5ZLXFmIganuIB7na6NWAiLYSdNkS/8IiZurcPuUlBmFLOYoJ5Iy/l4MSokKncZGIFEAFdTLLpCLFA4ccA4bjxB+ftg= Received: by 10.115.76.1 with SMTP id d1mr1158719wal.1193260562637; Wed, 24 Oct 2007 14:16:02 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id l23sm2275996waf.2007.10.24.14.15.59 (version=SSLv3 cipher=RC4-MD5); Wed, 24 Oct 2007 14:16:02 -0700 (PDT) Message-ID: <471FB60B.3070304@gmail.com> Date: Thu, 25 Oct 2007 10:15:55 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sam Hartman References: <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> <87fy00vn1l.fsf@mocca.josefsson.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Simon Josefsson , ietf@ietf.org Subject: Re: When is using patented technology appropriate? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-25 04:30, Sam Hartman wrote: ... > Simon> If you replace IBM with 'A Patent Troll', do you think the > Simon> same holds? > > I think that such behavior should be presumed not to be a patent > troll. Patent trolls are not known forpromising to give away > royalty-free licenses. They are also, in general, known for *not* particpating in the standards process, precisely to avoid falling under patent disclosure requirements. As far as non-participants are concerned, nothing in our rules matters. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 24 18:03:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iko3P-0004BS-VN; Wed, 24 Oct 2007 17:46:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iko3O-0004AP-9H for ietf@ietf.org; Wed, 24 Oct 2007 17:46:18 -0400 Received: from machshav.com ([198.180.150.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iko3I-00078t-4a for ietf@ietf.org; Wed, 24 Oct 2007 17:46:18 -0400 Received: by machshav.com (Postfix, from userid 512) id EFB03573; Wed, 24 Oct 2007 21:46:02 +0000 (GMT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6BA0216E; Wed, 24 Oct 2007 21:46:02 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 41754766153; Wed, 24 Oct 2007 17:46:02 -0400 (EDT) Date: Wed, 24 Oct 2007 21:46:01 +0000 From: "Steven M. Bellovin" To: Brian E Carpenter Message-ID: <20071024214601.28e866ce@cs.columbia.edu> In-Reply-To: <471FB60B.3070304@gmail.com> References: <18199.55877.791858.498365@swbmbp.local> <03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA> <877iljv6ed.fsf@mocca.josefsson.org> <042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA> <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> <87fy00vn1l.fsf@mocca.josefsson.org> <471FB60B.3070304@gmail.com> Organization: Columbia University X-Mailer: Claws Mail 3.0.2 (GTK+ 2.10.14; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Simon Josefsson , Sam Hartman , ietf@ietf.org Subject: Re: When is using patented technology appropriate? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Thu, 25 Oct 2007 10:15:55 +1300 Brian E Carpenter wrote: > On 2007-10-25 04:30, Sam Hartman wrote: > > ... > > Simon> If you replace IBM with 'A Patent Troll', do you think > > Simon> the same holds? > > I think that such behavior should > > Simon> be presumed not to be a patent > > troll. Patent trolls are not known forpromising to give away > > royalty-free licenses. > > They are also, in general, known for *not* particpating in > the standards process, precisely to avoid falling under > patent disclosure requirements. As far as non-participants > are concerned, nothing in our rules matters. > Right. Any IPR policy has to acknowledge the fact that relevant patents can be owned by non-troll non-participants. (Too many negatives there -- what I'm saying is that IETFers don't know of all patents in the space, and there are real patent owners who care about their patents, even though they aren't trolls.) --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 24 18:12:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkoFl-00080v-Ve; Wed, 24 Oct 2007 17:59:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkoFk-00080q-QS for ietf@ietf.org; Wed, 24 Oct 2007 17:59:04 -0400 Received: from wa-out-1112.google.com ([209.85.146.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkoFf-0007Sa-AD for ietf@ietf.org; Wed, 24 Oct 2007 17:59:04 -0400 Received: by wa-out-1112.google.com with SMTP id k40so564425wah for ; Wed, 24 Oct 2007 14:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=3fMELr4emi3m7r5jy/8cPlqoOrSho48DcX1DaClWcFs=; b=IU9I7Kwl6gNy30idb8mA6TEVskwXLrVHfoQTEdFueYgqZ8Weq7eLQd67FCAO3TS2Vky57n2J3FZ6ZXPKN8QWl58JmaBEqC+PKkxLRlCYImUtJQfJkR+M5r0dpFS6UekMWM1VmMnMdPzSXsWkU0hyLYj5u7tne+HFYXbll4aThwA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=IoOsnNYTs3jJD6xQ1TeaPlPqON/ftMQ2vEo5c5oQjVgeorL/vYAgqas7nuIp/JVS/sAfZHv+WhDvtWkvuD420dg+qgcKWxkQWQXwB41gU+pix7HCwcT+TvtrLfsodI1i+BHGZaQY3x69DDxP6U7Rip0bFr1UlkNtNlWBJKDfWM8= Received: by 10.114.194.1 with SMTP id r1mr1228198waf.1193263120943; Wed, 24 Oct 2007 14:58:40 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id k39sm2321515wah.2007.10.24.14.58.37 (version=SSLv3 cipher=RC4-MD5); Wed, 24 Oct 2007 14:58:39 -0700 (PDT) Message-ID: <471FC008.7070901@gmail.com> Date: Thu, 25 Oct 2007 10:58:32 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ietf@ietf.org References: <8138-SnapperMsgD8DB99B6C3444D0A@[70. 195.169.164]><20071024105010.90F0622024E@quill.bollow.ch><200710241133.411 48.scott@kitterman.com> <007001c8165f$a6007090$6401a8c0@LROSENTOSHIBA> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-25 08:32, Ted Hardie wrote: > At 10:02 AM -0700 10/24/07, Lawrence Rosen wrote: >> Ted Hardie wrote: >>> The point being, of course, that there is a world of difference between >>> "many" and "all" here. If there is no development community using >>> the GPL in an area, forcing the IPR restrictions to meet a GPL test >>> may hinder development rather than enhance it, especially in >>> cases where the only requirement in a license is to request it. >>> For many development communities, that is not an issue since it >>> requires no monetary outlay. >> Will you please stop talking about GPL as if it is the only open source >> license relevant here! > > Sorry, but the context in this part of the thread was specific to the GPL. > To refresh your memory on the bits the Brian, Norbert, and Scott > put forward that set that context: > >>>> Norbert wrote: >>>> How about: 'Should be possible to implement without having to ask for >>>> permission or pay a fee'? >>> Brian replied: >>> That will never fly. For good reason, many patent holders insist >>> on reciprocity conditions, and that seems to require an explicit >>> request and acknowledgement. >> Scott add: >> And that will never fly (IANAL) with the GPL and so here we sit at an >> impasse again. So either a GPL implementation is important to >> interoperability in a given space or it is not. If it is important to >> interoperabilty, then this is a showstopper. If not, maybe not. > > Hope that helps restore context for you. > >> My concern is that *all* free and open source >> licensors be able to implement IETF specifications without patent >> encumbrances. And *all* proprietary licensors too, for that matter. There >> ought to be no "GPL test" for IETF specifications, other than that our >> specifications be implementable and distributable under the GPL *and any >> other* license. > > The world as it is now simply does include licenses that aren't compatible. > As Brian pointed out, reciprocity conditions are common, as are requests > to acknowledge. If Scott is right and these won't work with the > GPL, working groups will have choices to make about the > implementation and deployment communities' needs. This is why we > keep pushing the decision into the working groups, rather than making > a priori IPR choices: it's the place most likely to know whether a > reciprocal license/royalty-bearing license/piece of GPL'ed code in the standards > document is actually likely to cause a problem. > regards, > Ted I think this completes the thread of argument. As long as some open source licenses contain language that asserts that the code is not encumbered by additional patent licensing requirements, *and* there is no change in the legal and economic reasons for companies to insist on reciprocity and acknowledgement even for RF licenses, we (the IETF) simply cannot find a better compromise than deciding case by case. I do like Sam's suggestion of giving the availability of free software weight in the Proposed Standard decision, but that is not a discontinuity in IETF practice. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 24 18:14:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkoNB-00069U-05; Wed, 24 Oct 2007 18:06:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkoNA-0005wD-7f for ietf@ietf.org; Wed, 24 Oct 2007 18:06:44 -0400 Received: from mail26i.sbc-webhosting.com ([216.173.236.230]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IkoMz-0007df-W6 for ietf@ietf.org; Wed, 24 Oct 2007 18:06:40 -0400 Received: from mx109.stngva01.us.mxservers.net (198.173.112.15) by mail26i.sbc-webhosting.com (RS ver 1.0.95vs) with SMTP id 2-0788253582 for ; Wed, 24 Oct 2007 18:06:23 -0400 (EDT) Received: from mmm2630.sbc-webhosting.com [216.173.237.89] (EHLO mmm2630.sbc-webhosting.com) by mx109.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id 9a1cf174.26976.336.mx109.stngva01.us.mxservers.net; Wed, 24 Oct 2007 18:05:29 -0400 (EDT) Received: (qmail 2606 invoked from network); 24 Oct 2007 22:06:21 -0000 Received: from unknown (HELO LROSENTOSHIBA) (lrosen@208.106.45.202) by with ESMTPA; 24 Oct 2007 22:06:21 -0000 From: "Lawrence Rosen" To: References: <18199.55877.791858.498365@swbmbp.local><03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA><877iljv6ed.fsf@mocca.josefsson.org><042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA><2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com><471A5668.8060505@gmail.com><048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA><20071022195723.4D9A22202DA@quill.bollow.ch><20071023105651.8D9AC2202DA@quill.bollow.ch><87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> <87fy00vn1l.fsf@mocca.josefsson.org> <471FB60B.3070304@gmail.com> <20071024214601.28e866ce@cs.columbia.edu> Date: Wed, 24 Oct 2007 15:05:17 -0700 Organization: Rosenlaw & Einschlag Message-ID: <00d801c81689$f64c5f30$6401a8c0@LROSENTOSHIBA> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20071024214601.28e866ce@cs.columbia.edu> Thread-Index: AcgWiTEXmQM0PJojQ7K0BckHlS1RVwAABqqw X-Spam: [F=0.0043103448; heur=0.500(-26100); stat=0.010; spamtraq-heur=0.300(2007101727)] X-MAIL-FROM: X-SOURCE-IP: [216.173.237.89] X-SF-Loop: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: RE: When is using patented technology appropriate? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lrosen@rosenlaw.com List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Steven Bellovin wrote: > Right. Any IPR policy has to acknowledge the fact that relevant > patents can be owned by non-troll non-participants. (Too many > negatives there -- what I'm saying is that IETFers don't know of all > patents in the space, and there are real patent owners who care about > their patents, even though they aren't trolls.) I agree, but I suggest that our new IPR policy ought to set expectations for how we deal procedurally with such outside encumbrances when discovered. The defensive termination provision in most contributors' IETF patent grants can also help to protect our specifications from trolls and some third-party patent owners, depending upon how those grants are worded. /Larry > -----Original Message----- > From: Steven M. Bellovin [mailto:smb@cs.columbia.edu] > Sent: Wednesday, October 24, 2007 2:46 PM > To: Brian E Carpenter > Cc: Simon Josefsson; Sam Hartman; ietf@ietf.org > Subject: Re: When is using patented technology appropriate? > > On Thu, 25 Oct 2007 10:15:55 +1300 > Brian E Carpenter wrote: > > > On 2007-10-25 04:30, Sam Hartman wrote: > > > > ... > > > Simon> If you replace IBM with 'A Patent Troll', do you think > > > Simon> the same holds? > > I think that such behavior should > > > Simon> be presumed not to be a patent > > > troll. Patent trolls are not known forpromising to give away > > > royalty-free licenses. > > > > They are also, in general, known for *not* particpating in > > the standards process, precisely to avoid falling under > > patent disclosure requirements. As far as non-participants > > are concerned, nothing in our rules matters. > > > Right. Any IPR policy has to acknowledge the fact that relevant > patents can be owned by non-troll non-participants. (Too many > negatives there -- what I'm saying is that IETFers don't know of all > patents in the space, and there are real patent owners who care about > their patents, even though they aren't trolls.) > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 05:30:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkydT-0007k6-U4; Thu, 25 Oct 2007 05:04:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkydS-0007ab-P9 for ietf@ietf.org; Thu, 25 Oct 2007 05:04:14 -0400 Received: from yxa.extundo.com ([83.241.177.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkydQ-00009T-6A for ietf@ietf.org; Thu, 25 Oct 2007 05:04:12 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l9P945eo017069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Oct 2007 11:04:06 +0200 From: Simon Josefsson To: Ted Hardie References: <8138-SnapperMsgD8DB99B6C3444D0A@[70.195.169.164]> <20071024105010.90F0622024E@quill.bollow.ch> <200710241133.41148.scott@kitterman.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071025:ietf@ietf.org::38gp4wfptbVT/mtP:0Hsz X-Hashcash: 1:22:071025:hardie@qualcomm.com::FN7sin7b8Nhp+1+F:27U0 X-Hashcash: 1:22:071025:scott@kitterman.com::OqvdN9A3B5gkAKQw:L/4m Date: Thu, 25 Oct 2007 11:04:05 +0200 In-Reply-To: (Ted Hardie's message of "Wed\, 24 Oct 2007 09\:16\:39 -0700") Message-ID: <87640v5zwa.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Scott Kitterman , ietf@ietf.org Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Ted Hardie writes: >>No. My point was that for the IETF, interoperability is the goal, not some >>general statement about goodness of Free software. In many/most/maybe all >>cases, this will require any IPR restrictions to be GPL compatible. > > Can you think of an open-source project interested in the work of > CCAMP? GNU Zebra, Quagga, and MPLS-linux are three projects that come up by searching for relevant technology. I think you are missing the point, though. The point is to make sure that a free software implementation of IETF technology is _possible_. That doesn't necessarily mean that you won't be able to find an IETF WG with technical work that may not have been implemented already in free software. /Simon _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 08:47:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il1td-00065v-CN; Thu, 25 Oct 2007 08:33:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il1tb-00064j-Ud; Thu, 25 Oct 2007 08:33:07 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il1tb-0005Ke-Fd; Thu, 25 Oct 2007 08:33:07 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 84789259712; Thu, 25 Oct 2007 14:33:06 +0200 (CEST) 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 32280-02; Thu, 25 Oct 2007 14:33:01 +0200 (CEST) Received: from htat43p-no.corp.google.com (uio-guest-193-157-187-0-24-49.uio.no [193.157.187.49]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5780A25970D; Thu, 25 Oct 2007 14:33:01 +0200 (CEST) Date: Thu, 25 Oct 2007 14:30:49 +0200 From: Harald Tveit Alvestrand To: ietf@ietf.org, ipr-wg@ietf.org Message-ID: <9F8D3FB94DE343A4A29A8D86@B50854F0A9192E8EC6CDA126> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: Offer of time on the IPR WG agenda for rechartering X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org As it looks now, the IPR WG's meeting in Vancouver will not be extremely contentious. So, while priority MUST be given to finishing the WG's current work (copyrights), it seems reasonable to offer a time slot to proposals to recharter the WG to deal with patent issues. I think we can offer at least some time for face-to-face discussion of the issues - but in order to have a more focused discussion than a general discussion on whether or not anything needs to be done, The outcomes I see possible of such a discussion are: - No changes are necessary. The IPR WG can shut down. - A change is necessary, and a specific proposal is deemed closest to what the community wants. We can process a recharter request soon after the IETF meeting. - A change is necessary, but no consensus on what change exists. More discussion is necessary. - No consensus can be reached on whether or not a change is necessary. I'd like the people who want time on the agenda to supply a text (preferably published as an I-D), which summarizes, as clearly as possible: - What they think has changed since the last IPR WG evaluation of patent policy - What changes in overall direction they think the WG should address - What the charter for this activity should look like If more than one such proposal should appear, I'd suggest giving each submitter a 5-10 minute slot for making their argument, and leaving at least half an hour for general discussion. Please submit I-Ds with the name pattern of draft--ipr-patent- - that would make it easy for us to find them all. The timeslot for the WG is Tuesday morning from 0900 to 1130; the rechartering discussion would be within the time from 1030 to 1130. Harald _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 08:47:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il1oz-0005e5-EB; Thu, 25 Oct 2007 08:28:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il1ot-0005UB-Tr for ietf@ietf.org; Thu, 25 Oct 2007 08:28:16 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il1oo-00057L-A1 for ietf@ietf.org; Thu, 25 Oct 2007 08:28:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 25 Oct 2007 14:29:35 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C0501B822@IsrExch01.israel.polycom.com> In-Reply-To: <001501c809b6$a1f9a710$5d00a8c0@Codalogic> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-levin-mmusic-xml-media-control (XML Schema for Media Control) to Informational RFC Thread-Index: AcgJttiXYh+FocjRR8y1vcE7nBfRgAK3CjzQ From: "Even, Roni" To: "Pete Cordell" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 914259abaa14125df0511c5458bea061 Cc: Cullen Jennings , oritl@microsoft.com, pierre@radvision.com, jo@acm.org, jf.mule@cablelabs.com, Colin Perkins Subject: RE: Last Call: draft-levin-mmusic-xml-media-control (XML Schema for Media Control) to Informational RFC X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0095827320==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============0095827320== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81702.BA56BAC8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81702.BA56BAC8 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pete, After consulting with my co-authors our view is that industry = implemented the solution as specified in the example, so we need to = revise the schema based on Pete's suggestion to =20 =20 =20 This also means that we will not have the target name space so we do not = need to register it with IANA as specified in section 9.2. =20 If this is correct I will submit a revised revsion. =20 Thanks Roni Even =20 =20 =20 > -----Original Message----- > From: Pete Cordell [mailto:pete@codalogic.com] > Sent: Monday, October 08, 2007 4:22 PM > To: ietf@ietf.org > Cc: oritl@microsoft.com; Even, Roni; pierre@radvision.com > Subject: Re: Last Call: draft-levin-mmusic-xml-media-control (XML = Schema > for Media Control) to Informational RFC >=20 > I quickly looked at this and noticed that the XML instance examples = don't > match the schema because the instance does not make reference to the > namespace. i.e., to match the schema, the example should be: >=20 > >=20 > > > > > >=20 > >=20 > My expectation is that the instance is actually more authorative in = terms > of > what the authors are looking for. If that is the case, the schema = should > be > modified along the lines of: >=20 > xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema"> > ... >=20 > i.e. remove the targetNamespace declarations. >=20 > You may have your reasons not to, but if not, you may want to consider > using > schema's documentation features instead of the XML comments; e.g.: >=20 > > > Video control primitive. > >=20 > > ... >=20 > HTH, >=20 > Pete. > -- > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Pete Cordell > Codalogic > for XML Schema to C++ data binding visit > http://www.codalogic.com/lmx/ > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > ----- Original Message ----- > From: "The IESG" > To: "IETF-Announce" > Sent: Monday, October 08, 2007 2:29 PM > Subject: Last Call: draft-levin-mmusic-xml-media-control (XML Schema = for > Media Control) to Informational RFC >=20 >=20 > > The IESG has received a request from an individual submitter to = consider > > the following document: > > > > - 'XML Schema for Media Control ' > > as an Informational = RFC > > > > The IESG plans to make a decision in the next few weeks, and = solicits > > final comments on this action. Please send substantive comments to = the > > ietf@ietf.org mailing lists by 2007-11-05. Exceptionally, > > comments may be sent to iesg@ietf.org instead. In either case, = please > > retain the beginning of the Subject line to allow automated sorting. > > > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-levin-mmusic-xml-media- > control-11.txt > > > > > > IESG discussion can be tracked via > > > = https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D93 > 91&rfc_flag=3D0 > > > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf-announce > > >=20 =20 ------_=_NextPart_001_01C81702.BA56BAC8 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Pete,

After consulting with my co-authors our view is that industry implemented the solution as specified in the example, so we need to = revise the schema based on Pete's suggestion to

 

<?xml version=3D"1.0" = encoding=3D"utf-8"?>

<xs:schema = xmlns:xs=3D"http://www.w3.org/2001/XMLSchema" elementFormDefault=3D"qualified" = id=3D"TightMediaControl">

      <xs:element name=3D"media_control">

            <xs:complexType>

                  = <xs:sequence>

                        = <xs:element name=3D"vc_primitive" type=3D"vc_primitive" minOccurs=3D"0" = maxOccurs=3D"unbounded"/>

                        = <xs:element name=3D"general_error" type=3D"xs:string" minOccurs=3D"0" = maxOccurs=3D"unbounded"/>

                  = </xs:sequence>

            </xs:complexType>

      = </xs:element>

      <!-- Video control = primitive.  -->

      <xs:complexType name=3D"vc_primitive">

            <xs:sequence>

                  <xs:element = name=3D"to_encoder" type=3D"to_encoder"/>

                  <xs:element = name=3D"stream_id" type=3D"xs:string" minOccurs=3D"0" = maxOccurs=3D"unbounded"/>

            </xs:sequence>

      = </xs:complexType>

      <!-- Encoder = Command:

               &= nbsp;Picture Fast Update

           = -->

      <xs:complexType name=3D"to_encoder">

            <xs:choice>

                  <xs:element = name=3D"picture_fast_update"/>

            </xs:choice>

      = </xs:complexType>

</xs:schema>

 

 

This also means that we will not have the target name space so = we do not need to register it with IANA as specified in section = 9.2.

 

If this is correct I will submit a revised = revsion.

 

Thanks

Roni = Even

 

 

 

> -----Original Message-----

> From: Pete Cordell = [mailto:pete@codalogic.com]

> Sent: Monday, October 08, 2007 4:22 = PM

> To: ietf@ietf.org

> Cc: oritl@microsoft.com; Even, Roni; = pierre@radvision.com

> Subject: Re: Last Call: = draft-levin-mmusic-xml-media-control (XML Schema

> for Media Control) to Informational = RFC

>

> I quickly looked at this and noticed that the XML instance examples don't

> match the schema because the instance does not make = reference to the

> namespace.  i.e., to match the schema, the example = should be:

>

>    <media_control xmlns=3D"urn:ietf:params:xml:ns:media_control">

>

> =       <vc_primitive>

> =        <to_encoder>

>          <picture_fast_up= date/>

> =        </to_encoder><= /span>

> =      </vc_primitive>

>

> =    </media_control>

>

> My expectation is that the instance is actually more = authorative in terms

> of

> what the authors are looking for. If that is the case, the = schema should

> be

> modified along the lines of:

>

>    <xsd:schema = id=3D"TightMediaControl"

>     xmlns:xsd=3D"http://www.w3.org/2001/XMLSchem= a">

>     ...

>

> i.e. remove the targetNamespace = declarations.

>

> You may have your reasons not to, but if not, you may want = to consider

> using

> schema's documentation features instead of the XML = comments; e.g.:

>

> <xsd:complexType = name=3D"vc_primitive">

>     <xsd:annotation><xsd:documentation>

>         Video = control primitive.

>     </xsd:documentation></xsd:annotation>=

>

> =     <xsd:sequence>

=

> =      ...

>

> HTH,

>

> Pete.

> --

> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

> Pete Cordell

> Codalogic

> for XML Schema to C++ data binding = visit

> =  http://www.codalogic.com/lmx/

> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

> ----- Original Message -----

> From: "The IESG" = <iesg-secretary@ietf.org>

> To: "IETF-Announce" = <ietf-announce@ietf.org>

> Sent: Monday, October 08, 2007 2:29 = PM

> Subject: Last Call: draft-levin-mmusic-xml-media-control = (XML Schema for

> Media Control) to Informational = RFC

>

>

> > The IESG has received a request from an individual = submitter to consider

> > the following document:

> >

> > - 'XML Schema for Media Control = '

> >   <draft-levin-mmusic-xml-media-control-11.txt> as an Informational = RFC

> >

> > The IESG plans to make a decision in the next few = weeks, and solicits

> > final comments on this action.  Please send = substantive comments to the

> > ietf@ietf.org mailing lists by 2007-11-05. = Exceptionally,

> > comments may be sent to iesg@ietf.org instead. In = either case, please

> > retain the beginning of the Subject line to allow = automated sorting.

> >

> > The file can be obtained = via

> > http://www.ietf.org/internet-drafts/draft-levin-mmusic-xml-media-

> control-11.txt

> >

> >

> > IESG discussion can be tracked = via

> >

> = https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&= dTag=3D93

> 91&rfc_flag=3D0

> >

> >

> > = _______________________________________________<= /p>

> > IETF-Announce mailing = list

> > IETF-Announce@ietf.org

> > = https://www1.ietf.org/mailman/listinfo/ietf-announce

> >

>

 

------_=_NextPart_001_01C81702.BA56BAC8-- --===============0095827320== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0095827320==-- From ietf-bounces@ietf.org Thu Oct 25 11:29:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4NM-0005i9-JU; Thu, 25 Oct 2007 11:12:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4NK-0005dG-S7 for ietf@ietf.org; Thu, 25 Oct 2007 11:11:58 -0400 Received: from mail26j.sbc-webhosting.com ([216.173.236.231]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Il4NI-0001kr-9L for ietf@ietf.org; Thu, 25 Oct 2007 11:11:56 -0400 Received: from mx21.stngva01.us.mxservers.net (204.202.242.71) by mail26j.sbc-webhosting.com (RS ver 1.0.95vs) with SMTP id 4-0968045114 for ; Thu, 25 Oct 2007 11:11:55 -0400 (EDT) Received: from mmm2630.sbc-webhosting.com [216.173.237.89] (EHLO mmm2630.sbc-webhosting.com) by mx21.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id a32b0274.15610.358.mx21.stngva01.us.mxservers.net; Thu, 25 Oct 2007 11:11:54 -0400 (EDT) Received: (qmail 50360 invoked from network); 25 Oct 2007 15:11:53 -0000 Received: from unknown (HELO LROSENTOSHIBA) (lrosen@208.106.45.202) by with ESMTPA; 25 Oct 2007 15:11:53 -0000 From: "Lawrence Rosen" To: , References: <9F8D3FB94DE343A4A29A8D86@B50854F0A9192E8EC6CDA126> Date: Thu, 25 Oct 2007 08:10:48 -0700 Organization: Rosenlaw & Einschlag Message-ID: <013901c81719$39b4f180$6401a8c0@LROSENTOSHIBA> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <9F8D3FB94DE343A4A29A8D86@B50854F0A9192E8EC6CDA126> Thread-Index: AcgXA7F6qmRvHW/oSeGknYm50TTIBAAFMx7Q X-Spam: [F=0.0230263158; heur=0.500(-19500); stat=0.010; spamtraq-heur=0.700(2007051601)] X-MAIL-FROM: X-SOURCE-IP: [216.173.237.89] X-SF-Loop: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Subject: RE: Offer of time on the IPR WG agenda for rechartering X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lrosen@rosenlaw.com List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Harald, I am unable to be in Vancouver for the meeting, but I hope that someone else there will support the re-charter of the IPR WG as I suggested in my earlier email: *************** I request that we charter the IETF IPR-WG to propose policies and procedures, consistent with the worldwide mission of IETF, which will result in IETF specifications unencumbered by restrictive, non-free patents. *************** I also hope that a decision on this will not be based simply on who attends in Vancouver, but on a wider representative vote of IETF participants. /Larry Rosen > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: Thursday, October 25, 2007 5:31 AM > To: ietf@ietf.org; ipr-wg@ietf.org > Subject: Offer of time on the IPR WG agenda for rechartering > > As it looks now, the IPR WG's meeting in Vancouver will not be extremely > contentious. > > So, while priority MUST be given to finishing the WG's current work > (copyrights), it seems reasonable to offer a time slot to proposals to > recharter the WG to deal with patent issues. > > I think we can offer at least some time for face-to-face discussion of the > issues - but in order to have a more focused discussion than a general > discussion on whether or not anything needs to be done, > > The outcomes I see possible of such a discussion are: > > - No changes are necessary. The IPR WG can shut down. > > - A change is necessary, and a specific proposal is deemed closest to what > the community wants. We can process a recharter request soon after the > IETF > meeting. > > - A change is necessary, but no consensus on what change exists. More > discussion is necessary. > > - No consensus can be reached on whether or not a change is necessary. > > I'd like the people who want time on the agenda to supply a text > (preferably published as an I-D), which summarizes, as clearly as > possible: > > - What they think has changed since the last IPR WG evaluation of patent > policy > > - What changes in overall direction they think the WG should address > > - What the charter for this activity should look like > > If more than one such proposal should appear, I'd suggest giving each > submitter a 5-10 minute slot for making their argument, and leaving at > least half an hour for general discussion. > > Please submit I-Ds with the name pattern of > draft--ipr-patent- - that would make it easy for us > to find them all. > > The timeslot for the WG is Tuesday morning from 0900 to 1130; the > rechartering discussion would be within the time from 1030 to 1130. > > Harald > > > _______________________________________________ > Ipr-wg mailing list > Ipr-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/ipr-wg _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 11:41:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4jX-0008FL-Jf; Thu, 25 Oct 2007 11:34:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4jW-0008Bz-51 for ietf@ietf.org; Thu, 25 Oct 2007 11:34:54 -0400 Received: from [2002:4519:c427:1:220:edff:fe18:5794] (helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il4jT-0008Np-S9 for ietf@ietf.org; Thu, 25 Oct 2007 11:34:52 -0400 Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtps (tls_cipher TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50 #1 (Debian)) id 1Il4si-0005qX-7c; Thu, 25 Oct 2007 11:44:24 -0400 Received: from tytso by closure.thunk.org with local (Exim 4.67) (envelope-from ) id 1Il4iQ-0007dM-He; Thu, 25 Oct 2007 11:33:46 -0400 Date: Thu, 25 Oct 2007 11:33:46 -0400 From: Theodore Tso To: ietf@ietf.org Bcc: tytso@mit.edu Message-ID: <20071025153346.GC22103@thunk.org> References: <007001c8165f$a6007090$6401a8c0@LROSENTOSHIBA> <471FC008.7070901@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <471FC008.7070901@gmail.com> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false X-Spam-Score: -0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Thu, Oct 25, 2007 at 10:58:32AM +1300, Brian E Carpenter wrote: > On 2007-10-25 08:32, Ted Hardie wrote: >> At 10:02 AM -0700 10/24/07, Lawrence Rosen wrote: >>> Ted Hardie wrote: >>> And that will never fly (IANAL) with the GPL and so here we sit at an >>> impasse again. So either a GPL implementation is important to >>> interoperability in a given space or it is not. If it is important to >>> interoperabilty, then this is a showstopper. If not, maybe not. >> Hope that helps restore context for you. I would argue that a GPL implemention is not important to interoperability testing as long as there is a BSD-licensed implementation. In fact, to the extent that all or most of the commercial products are based off of the same BSD-licensed code base, this can actually *improve* interoperability. (I may have been awarded the 2006 FSF Award for the Advancement of Free Software, but if my goal were to make sure that specification was going to get widely adopted, I'd use a BSD license, not a GPl license, for the reference implementation.) Of course there can be are problems when the reference implementation doesn't quite jibe with the formal printed specification, but that is true regardless how the reference implementation is licensed. - Ted _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 12:09:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il55R-00017A-Rc; Thu, 25 Oct 2007 11:57:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il55P-00012M-6v for ietf@ietf.org; Thu, 25 Oct 2007 11:57:31 -0400 Received: from tarsus.bollow.ch ([82.195.230.222]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il55O-0003n2-Li for ietf@ietf.org; Thu, 25 Oct 2007 11:57:31 -0400 Received: from tarsus.bollow.ch (localhost [127.0.0.1]) by tarsus.bollow.ch (Postfix) with ESMTP id 354A2B28186 for ; Thu, 25 Oct 2007 18:33:22 +0200 (CEST) Authentication-Results: tarsus.bollow.ch from=nb@bollow.ch; domainkey=temperror (DNS query timeout for ._domainkey.bollow.ch) Received: from quill.bollow.ch (167-0.0-85.cust.bluewin.ch [85.0.0.167]) by tarsus.bollow.ch (Postfix) with ESMTP for ; Thu, 25 Oct 2007 18:33:22 +0200 (CEST) Received: by quill.bollow.ch (Postfix, from userid 1000) id C8E8F22024E; Thu, 25 Oct 2007 18:00:42 +0200 (CEST) From: Norbert Bollow Organization: Bollow Software Economics Research MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=iso-8859-1 To: ietf@ietf.org In-reply-to: <20071025153346.GC22103@thunk.org> (message from Theodore Tso on Thu, 25 Oct 2007 11:33:46 -0400) References: <007001c8165f$a6007090$6401a8c0@LROSENTOSHIBA> <471FC008.7070901@gmail.com> <20071025153346.GC22103@thunk.org> Message-Id: <20071025160042.C8E8F22024E@quill.bollow.ch> Date: Thu, 25 Oct 2007 18:00:42 +0200 (CEST) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Theodore Tso wrote: > On Thu, Oct 25, 2007 at 10:58:32AM +1300, Brian E Carpenter wrote: > > On 2007-10-25 08:32, Ted Hardie wrote: > >> At 10:02 AM -0700 10/24/07, Lawrence Rosen wrote: > >>> Ted Hardie wrote: > >>> And that will never fly (IANAL) with the GPL and so here we sit at = an > >>> impasse again. So either a GPL implementation is important to > >>> interoperability in a given space or it is not. If it is important= to > >>> interoperabilty, then this is a showstopper. If not, maybe not. > >> Hope that helps restore context for you. >=20 > I would argue that a GPL implemention is not important to > interoperability testing as long as there is a BSD-licensed > implementation. In fact, to the extent that all or most of the > commercial products are based off of the same BSD-licensed code base, > this can actually *improve* interoperability. (I may have been > awarded the 2006 FSF Award for the Advancement of Free Software, but > if my goal were to make sure that specification was going to get > widely adopted, I'd use a BSD license, not a GPl license, for the > reference implementation.) I don't disagree with anything that you wrote, but the point here is that if there's a patent with GPL-incompatible licensing, you don't have permission to link that BSD-licensed code into a GPL-licensed program and distribute the result. Greetings, Norbert. --=20 Norbert Bollow http://Norbert.ch President of the Swiss Internet User Group SIUG http://SIUG.ch Working on establishing a non-corrupt and truly /open/ international standards organization http://OpenISO.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 12:09:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il55l-0001GR-Qy; Thu, 25 Oct 2007 11:57:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il55k-0001ER-DA for ietf@ietf.org; Thu, 25 Oct 2007 11:57:52 -0400 Received: from mailout00.controlledmail.com ([72.81.252.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il55k-0003nt-1r for ietf@ietf.org; Thu, 25 Oct 2007 11:57:52 -0400 Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id ABF185CC0FE for ; Thu, 25 Oct 2007 15:57:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1193327871; bh=YEPtfgob/wZBcWe1F6NxysaQTdgiAcm/yZwN+rY gPvI=; h=Received:From:Organization:To:Subject:Date:User-Agent: References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-Disposition:Message-Id: X-AV-Checked; b=cxngzbeHduvKENYTToO7FHdLnM0me2ZTpa7sUMAVcwFbV3PPfy KQCJEjgv8YHzY4jz5Kpwl731Xsu8XA7aXHuvPR2A6VbFWCzLDIqMlPzIgDbLuSxZKM3 005ztJq3+ZgGB5kU7VgjNRTEZD/GgJ8yZn2OF5xM6QIUoTHHFnR3Zw= Received: from [192.168.111.102] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by mailout00.controlledmail.com (Postfix) with ESMTP id 8145F5CC0EF for ; Thu, 25 Oct 2007 15:57:51 +0000 (UTC) From: Scott Kitterman Organization: Kitterman Technical Services To: ietf@ietf.org Date: Thu, 25 Oct 2007 11:57:47 -0400 User-Agent: KMail/1.9.5 References: <471FC008.7070901@gmail.com> <20071025153346.GC22103@thunk.org> In-Reply-To: <20071025153346.GC22103@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710251157.48772.scott@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Thursday 25 October 2007 11:33, Theodore Tso wrote: > On Thu, Oct 25, 2007 at 10:58:32AM +1300, Brian E Carpenter wrote: > > On 2007-10-25 08:32, Ted Hardie wrote: > >> At 10:02 AM -0700 10/24/07, Lawrence Rosen wrote: > >>> Ted Hardie wrote: > >>> And that will never fly (IANAL) with the GPL and so here we sit at an > >>> impasse again. So either a GPL implementation is important to > >>> interoperability in a given space or it is not. If it is important to > >>> interoperabilty, then this is a showstopper. If not, maybe not. > >> > >> Hope that helps restore context for you. > > I would argue that a GPL implemention is not important to > interoperability testing as long as there is a BSD-licensed > implementation. In fact, to the extent that all or most of the > commercial products are based off of the same BSD-licensed code base, > this can actually *improve* interoperability. (I may have been > awarded the 2006 FSF Award for the Advancement of Free Software, but > if my goal were to make sure that specification was going to get > widely adopted, I'd use a BSD license, not a GPl license, for the > reference implementation.) > > Of course there can be are problems when the reference implementation > doesn't quite jibe with the formal printed specification, but that is > true regardless how the reference implementation is licensed. > The context wasn't reference implementations, but deployment in the real world where interoperability among different implementations (some with GPL licensing) is desired. Scott K _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 12:09:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il55R-00017A-Rc; Thu, 25 Oct 2007 11:57:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il55P-00012M-6v for ietf@ietf.org; Thu, 25 Oct 2007 11:57:31 -0400 Received: from tarsus.bollow.ch ([82.195.230.222]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il55O-0003n2-Li for ietf@ietf.org; Thu, 25 Oct 2007 11:57:31 -0400 Received: from tarsus.bollow.ch (localhost [127.0.0.1]) by tarsus.bollow.ch (Postfix) with ESMTP id 354A2B28186 for ; Thu, 25 Oct 2007 18:33:22 +0200 (CEST) Authentication-Results: tarsus.bollow.ch from=nb@bollow.ch; domainkey=temperror (DNS query timeout for ._domainkey.bollow.ch) Received: from quill.bollow.ch (167-0.0-85.cust.bluewin.ch [85.0.0.167]) by tarsus.bollow.ch (Postfix) with ESMTP for ; Thu, 25 Oct 2007 18:33:22 +0200 (CEST) Received: by quill.bollow.ch (Postfix, from userid 1000) id C8E8F22024E; Thu, 25 Oct 2007 18:00:42 +0200 (CEST) From: Norbert Bollow Organization: Bollow Software Economics Research MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=iso-8859-1 To: ietf@ietf.org In-reply-to: <20071025153346.GC22103@thunk.org> (message from Theodore Tso on Thu, 25 Oct 2007 11:33:46 -0400) References: <007001c8165f$a6007090$6401a8c0@LROSENTOSHIBA> <471FC008.7070901@gmail.com> <20071025153346.GC22103@thunk.org> Message-Id: <20071025160042.C8E8F22024E@quill.bollow.ch> Date: Thu, 25 Oct 2007 18:00:42 +0200 (CEST) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Theodore Tso wrote: > On Thu, Oct 25, 2007 at 10:58:32AM +1300, Brian E Carpenter wrote: > > On 2007-10-25 08:32, Ted Hardie wrote: > >> At 10:02 AM -0700 10/24/07, Lawrence Rosen wrote: > >>> Ted Hardie wrote: > >>> And that will never fly (IANAL) with the GPL and so here we sit at = an > >>> impasse again. So either a GPL implementation is important to > >>> interoperability in a given space or it is not. If it is important= to > >>> interoperabilty, then this is a showstopper. If not, maybe not. > >> Hope that helps restore context for you. >=20 > I would argue that a GPL implemention is not important to > interoperability testing as long as there is a BSD-licensed > implementation. In fact, to the extent that all or most of the > commercial products are based off of the same BSD-licensed code base, > this can actually *improve* interoperability. (I may have been > awarded the 2006 FSF Award for the Advancement of Free Software, but > if my goal were to make sure that specification was going to get > widely adopted, I'd use a BSD license, not a GPl license, for the > reference implementation.) I don't disagree with anything that you wrote, but the point here is that if there's a patent with GPL-incompatible licensing, you don't have permission to link that BSD-licensed code into a GPL-licensed program and distribute the result. Greetings, Norbert. --=20 Norbert Bollow http://Norbert.ch President of the Swiss Internet User Group SIUG http://SIUG.ch Working on establishing a non-corrupt and truly /open/ international standards organization http://OpenISO.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 12:09:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il55l-0001GR-Qy; Thu, 25 Oct 2007 11:57:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il55k-0001ER-DA for ietf@ietf.org; Thu, 25 Oct 2007 11:57:52 -0400 Received: from mailout00.controlledmail.com ([72.81.252.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il55k-0003nt-1r for ietf@ietf.org; Thu, 25 Oct 2007 11:57:52 -0400 Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id ABF185CC0FE for ; Thu, 25 Oct 2007 15:57:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1193327871; bh=YEPtfgob/wZBcWe1F6NxysaQTdgiAcm/yZwN+rY gPvI=; h=Received:From:Organization:To:Subject:Date:User-Agent: References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-Disposition:Message-Id: X-AV-Checked; b=cxngzbeHduvKENYTToO7FHdLnM0me2ZTpa7sUMAVcwFbV3PPfy KQCJEjgv8YHzY4jz5Kpwl731Xsu8XA7aXHuvPR2A6VbFWCzLDIqMlPzIgDbLuSxZKM3 005ztJq3+ZgGB5kU7VgjNRTEZD/GgJ8yZn2OF5xM6QIUoTHHFnR3Zw= Received: from [192.168.111.102] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by mailout00.controlledmail.com (Postfix) with ESMTP id 8145F5CC0EF for ; Thu, 25 Oct 2007 15:57:51 +0000 (UTC) From: Scott Kitterman Organization: Kitterman Technical Services To: ietf@ietf.org Date: Thu, 25 Oct 2007 11:57:47 -0400 User-Agent: KMail/1.9.5 References: <471FC008.7070901@gmail.com> <20071025153346.GC22103@thunk.org> In-Reply-To: <20071025153346.GC22103@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710251157.48772.scott@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Thursday 25 October 2007 11:33, Theodore Tso wrote: > On Thu, Oct 25, 2007 at 10:58:32AM +1300, Brian E Carpenter wrote: > > On 2007-10-25 08:32, Ted Hardie wrote: > >> At 10:02 AM -0700 10/24/07, Lawrence Rosen wrote: > >>> Ted Hardie wrote: > >>> And that will never fly (IANAL) with the GPL and so here we sit at an > >>> impasse again. So either a GPL implementation is important to > >>> interoperability in a given space or it is not. If it is important to > >>> interoperabilty, then this is a showstopper. If not, maybe not. > >> > >> Hope that helps restore context for you. > > I would argue that a GPL implemention is not important to > interoperability testing as long as there is a BSD-licensed > implementation. In fact, to the extent that all or most of the > commercial products are based off of the same BSD-licensed code base, > this can actually *improve* interoperability. (I may have been > awarded the 2006 FSF Award for the Advancement of Free Software, but > if my goal were to make sure that specification was going to get > widely adopted, I'd use a BSD license, not a GPl license, for the > reference implementation.) > > Of course there can be are problems when the reference implementation > doesn't quite jibe with the formal printed specification, but that is > true regardless how the reference implementation is licensed. > The context wasn't reference implementations, but deployment in the real world where interoperability among different implementations (some with GPL licensing) is desired. Scott K _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 12:37:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il5UN-0007SX-Iq; Thu, 25 Oct 2007 12:23:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il5UM-0007FG-B1 for ietf@ietf.org; Thu, 25 Oct 2007 12:23:18 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il5UC-0002CZ-PJ for ietf@ietf.org; Thu, 25 Oct 2007 12:23:18 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9PGMwug016142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 Oct 2007 09:22:59 -0700 Received: from [98.207.5.180] (vpn-10-50-16-143.qualcomm.com [10.50.16.143]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9PGMv3Z006415; Thu, 25 Oct 2007 09:22:58 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <87640v5zwa.fsf@mocca.josefsson.org> References: <8138-SnapperMsgD8DB99B6C3444D0A@[70.195.169.164]> <20071024105010.90F0622024E@quill.bollow.ch> <200710241133.41148.scott@kitterman.com> <87640v5zwa.fsf@mocca.josefsson.org> Date: Thu, 25 Oct 2007 09:22:58 -0700 To: Simon Josefsson From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Scott Kitterman , ietf@ietf.org Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 11:04 AM +0200 10/25/07, Simon Josefsson wrote: >Ted Hardie writes: > >>>No. My point was that for the IETF, interoperability is the goal, not some >>>general statement about goodness of Free software. In many/most/maybe all >>>cases, this will require any IPR restrictions to be GPL compatible. >> >> Can you think of an open-source project interested in the work of >> CCAMP? > >GNU Zebra, Quagga, and MPLS-linux are three projects that come up by >searching for relevant technology. I'm actually fairly familiar with Quagga, having used it in route-server mode, and it's mind understanding that it and Zebra don't really match the control plane uses of CCAMP. I'm not familiar with MPLS-linux, but I'll take a look at it; thanks for the pointer. >I think you are missing the point, though. The point is to make sure >that a free software implementation of IETF technology is _possible_. >That doesn't necessarily mean that you won't be able to find an IETF WG >with technical work that may not have been implemented already in free >software. The point I'm making, though, is that there really are different development communities working in the IETF. The GMPLS work in CCAMP is control plane work for wavelength, TDMA, and spatial switching networks. Though clearly important to keeping many networks running, it doesn't have the same reach of development interest as many of the other technologies in the IETF. If you were to compare it to the development communities involved in apps groups like CALSIFY or LEMONADE, you would find a very small overlap. Those development communities may well have different priorities in evaluating a license; some may find it problematic to include something that is royalty bearing or requires a reciprocal agreement and some may not. Privileging a development community which might someday arise and whose work might someday get deployment over the folks actually already spending time and effort on developing and deploying a standard is an odd position. Our aim is to make the Internet work, not to advance one kind of license over another. If the Internet will work better using a technology that requires a license incompatible with the GPL or even BSD licenses, then we should let the folks working in that area make that decision. In other words, this is about engineering trade-offs, not ideology. regards, Ted _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 12:48:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il5l2-0006bA-4l; Thu, 25 Oct 2007 12:40:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il5l0-0006Ys-UC for ietf@ietf.org; Thu, 25 Oct 2007 12:40:30 -0400 Received: from [2002:4519:c427:1:220:edff:fe18:5794] (helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il5kz-00033E-TX for ietf@ietf.org; Thu, 25 Oct 2007 12:40:30 -0400 Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtps (tls_cipher TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50 #1 (Debian)) id 1Il5uJ-0006o0-1m; Thu, 25 Oct 2007 12:50:07 -0400 Received: from tytso by closure.thunk.org with local (Exim 4.67) (envelope-from ) id 1Il5jy-00070f-7Y; Thu, 25 Oct 2007 12:39:26 -0400 Date: Thu, 25 Oct 2007 12:39:25 -0400 From: Theodore Tso To: Norbert Bollow Bcc: tytso@mit.edu Message-ID: <20071025163925.GA6456@thunk.org> References: <007001c8165f$a6007090$6401a8c0@LROSENTOSHIBA> <471FC008.7070901@gmail.com> <20071025153346.GC22103@thunk.org> <20071025160042.C8E8F22024E@quill.bollow.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071025160042.C8E8F22024E@quill.bollow.ch> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false X-Spam-Score: -0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ietf@ietf.org Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Thu, Oct 25, 2007 at 06:00:42PM +0200, Norbert Bollow wrote: > > I would argue that a GPL implemention is not important to > > interoperability testing as long as there is a BSD-licensed > > implementation. In fact, to the extent that all or most of the > > commercial products are based off of the same BSD-licensed code base, > > this can actually *improve* interoperability. (I may have been > > awarded the 2006 FSF Award for the Advancement of Free Software, but > > if my goal were to make sure that specification was going to get > > widely adopted, I'd use a BSD license, not a GPl license, for the > > reference implementation.) > > I don't disagree with anything that you wrote, but the point here > is that if there's a patent with GPL-incompatible licensing, you > don't have permission to link that BSD-licensed code into a > GPL-licensed program and distribute the result. And I would argue that the above issue is not a matter of concern to the IETF. Having a reference implementation to encourage adoption of the spec, that is of IETF's concern. The issue of GPL requirements is, I would argue, Not Our Problem. - Ted _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 12:51:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il5rT-0007fz-7j; Thu, 25 Oct 2007 12:47:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il5rR-0007fZ-LE for ietf@ietf.org; Thu, 25 Oct 2007 12:47:09 -0400 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il5rL-0003L2-Gt for ietf@ietf.org; Thu, 25 Oct 2007 12:47:09 -0400 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1Il5rB-0003G5-7A for ietf@ietf.org; Thu, 25 Oct 2007 12:46:53 -0400 Message-ID: <4720C85F.4000303@ca.afilias.info> Date: Thu, 25 Oct 2007 12:46:23 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ietf@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: -4.0 (----) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: IETF 70 - meeting conflict - any way to juggle schedule to accommodate? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org There is a scheduling conflict between two WG meetings, at IETF-70 in Vancouver. I consider them to both be very important, as both concern the essential elements of short and long term development of technologies for the Internet itself - IPv6 and Routing Research. The actual WG designations are: rrg (routing research group) and 6man (IPv6 maintenance WG) Both are currently scheduled for Wednesday Morning (I). If at all possible, can one of these be moved to *any* other slot? (I'm hoping to present at the 6man meeting, and desperately want to attend the RRG meeting as well.) Thanks, Brian Dickson _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 13:17:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il69v-0004gJ-BW; Thu, 25 Oct 2007 13:06:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il69t-0004g7-6g for ietf@ietf.org; Thu, 25 Oct 2007 13:06:13 -0400 Received: from tarsus.bollow.ch ([82.195.230.222]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il69s-0006OO-QL for ietf@ietf.org; Thu, 25 Oct 2007 13:06:13 -0400 Received: from tarsus.bollow.ch (localhost [127.0.0.1]) by tarsus.bollow.ch (Postfix) with ESMTP id BE6A7B28158 for ; Thu, 25 Oct 2007 19:42:33 +0200 (CEST) Authentication-Results: tarsus.bollow.ch from=nb@bollow.ch; domainkey=neutral (no signature; no policy for bollow.ch) Received: from quill.bollow.ch (167-0.0-85.cust.bluewin.ch [85.0.0.167]) by tarsus.bollow.ch (Postfix) with ESMTP for ; Thu, 25 Oct 2007 19:42:33 +0200 (CEST) Received: by quill.bollow.ch (Postfix, from userid 1000) id 72B2422024E; Thu, 25 Oct 2007 19:09:54 +0200 (CEST) From: Norbert Bollow Organization: Bollow Software Economics Research MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=iso-8859-1 To: ietf@ietf.org In-reply-to: <20071025163925.GA6456@thunk.org> (message from Theodore Tso on Thu, 25 Oct 2007 12:39:25 -0400) References: <007001c8165f$a6007090$6401a8c0@LROSENTOSHIBA> <471FC008.7070901@gmail.com> <20071025153346.GC22103@thunk.org> <20071025160042.C8E8F22024E@quill.bollow.ch> <20071025163925.GA6456@thunk.org> Message-Id: <20071025170954.72B2422024E@quill.bollow.ch> Date: Thu, 25 Oct 2007 19:09:54 +0200 (CEST) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Theodore Tso wrote: > > I don't disagree with anything that you wrote, but the point here > > is that if there's a patent with GPL-incompatible licensing, you > > don't have permission to link that BSD-licensed code into a > > GPL-licensed program and distribute the result. >=20 > And I would argue that the above issue is not a matter of concern to > the IETF. Having a reference implementation to encourage adoption of > the spec, that is of IETF's concern. The issue of GPL requirements > is, I would argue, Not Our Problem. Is it really your position that that is in no case a concern that IETF should consider??? For an extreme example, consider hypothetically the case that an essential part of the IPv6 protocol stack had such a patent issue. Greetings, Norbert. --=20 Norbert Bollow http://Norbert.ch President of the Swiss Internet User Group SIUG http://SIUG.ch Working on establishing a non-corrupt and truly /open/ international standards organization http://OpenISO.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 13:58:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il6mR-0006lz-0F; Thu, 25 Oct 2007 13:46:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il6mO-0006Ph-Ij for ietf@ietf.org; Thu, 25 Oct 2007 13:46:00 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il6mI-0006Je-C5 for ietf@ietf.org; Thu, 25 Oct 2007 13:46:00 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7537D198683; Thu, 25 Oct 2007 20:45:48 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id DB5C8198670; Thu, 25 Oct 2007 20:45:47 +0300 (EEST) Message-ID: <4720D63B.8000403@piuha.net> Date: Thu, 25 Oct 2007 19:45:31 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: Brian Dickson References: <4720C85F.4000303@ca.afilias.info> In-Reply-To: <4720C85F.4000303@ca.afilias.info> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ietf@ietf.org Subject: Re: IETF 70 - meeting conflict - any way to juggle schedule to accommodate? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Yes, this is unfortunate. I'll see what the secretary can do. Jari Brian Dickson kirjoitti: > There is a scheduling conflict between two WG meetings, at IETF-70 in > Vancouver. > > I consider them to both be very important, as both concern the > essential elements of short and long term development of technologies > for the Internet itself - IPv6 and Routing Research. > > The actual WG designations are: > rrg (routing research group) > and > 6man (IPv6 maintenance WG) > > Both are currently scheduled for Wednesday Morning (I). > > If at all possible, can one of these be moved to *any* other slot? > (I'm hoping to present at the 6man meeting, and desperately want to > attend the RRG meeting as well.) > > Thanks, > > Brian Dickson > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 13:58:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il6lp-0004Og-1a; Thu, 25 Oct 2007 13:45:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il6ln-0004JS-NQ for ietf@ietf.org; Thu, 25 Oct 2007 13:45:23 -0400 Received: from email.xpasc.com ([65.85.17.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il6lg-0006Hc-HD for ietf@ietf.org; Thu, 25 Oct 2007 13:45:23 -0400 Received: from bslepgate.xpasc.com (localhost.localdomain [127.0.0.1]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id 7F7E6100584 for ; Thu, 25 Oct 2007 10:45:01 -0700 (PDT) X-Propel-Return-Path: Received: from email.xpasc.com ([10.1.2.88]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 2.1.7.8167-src $Rev: 8148 $) id iz6Ur7aphJ10; Thu, 25 Oct 2007 10:45:01 -0700 Received: from xpasc.com (egate.xpasc.com [10.1.2.49]) by bslepgate.xpasc.com (Postfix-out) with ESMTPFrom ietf-bounces@ietf.org Thu Oct 25 13:58:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il6mR-0006lz-0F; Thu, 25 Oct 2007 13:46:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il6mO-0006Ph-Ij for ietf@ietf.org; Thu, 25 Oct 2007 13:46:00 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il6mI-0006Je-C5 for ietf@ietf.org; Thu, 25 Oct 2007 13:46:00 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7537D198683; Thu, 25 Oct 2007 20:45:48 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id DB5C8198670; Thu, 25 Oct 2007 20:45:47 +0300 (EEST) Message-ID: <4720D63B.8000403@piuha.net> Date: Thu, 25 Oct 2007 19:45:31 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: Brian Dickson References: <4720C85F.4000303@ca.afilias.info> In-Reply-To: <4720C85F.4000303@ca.afilias.info> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ietf@ietf.org Subject: Re: IETF 70 - meeting conflict - any way to juggle schedule to accommodate? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Yes, this is unfortunate. I'll see what the secretary can do. Jari Brian Dickson kirjoitti: > There is a scheduling conflict between two WG meetings, at IETF-70 in > Vancouver. > > I consider them to both be very important, as both concern the > essential elements of short and long term development of technologies > for the Internet itself - IPv6 and Routing Research. > > The actual WG designations are: > rrg (routing research group) > and > 6man (IPv6 maintenance WG) > > Both are currently scheduled for Wednesday Morning (I). > > If at all possible, can one of these be moved to *any* other slot? > (I'm hoping to present at the 6man meeting, and desperately want to > attend the RRG meeting as well.) > > Thanks, > > Brian Dickson > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 13:58:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il6lp-0004Og-1a; Thu, 25 Oct 2007 13:45:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il6ln-0004JS-NQ for ietf@ietf.org; Thu, 25 Oct 2007 13:45:23 -0400 Received: from email.xpasc.com ([65.85.17.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il6lg-0006Hc-HD for ietf@ietf.org; Thu, 25 Oct 2007 13:45:23 -0400 Received: from bslepgate.xpasc.com (localhost.localdomain [127.0.0.1]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id 7F7E6100584 for ; Thu, 25 Oct 2007 10:45:01 -0700 (PDT) X-Propel-Return-Path: Received: from email.xpasc.com ([10.1.2.88]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 2.1.7.8167-src $Rev: 8148 $) id iz6Ur7aphJ10; Thu, 25 Oct 2007 10:45:01 -0700 Received: from xpasc.com (egate.xpasc.com [10.1.2.49]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id 0E5F5100091 for ; Thu, 25 Oct 2007 10:45:01 -0700 (PDT) Received: from egate.xpasc.com (egate.xpasc.com [10.1.2.49]) by xpasc.com (8.11.2/8.11.2) with ESMTP id l9PHix727590 for ; Thu, 25 Oct 2007 10:45:00 -0700 Date: Thu, 25 Oct 2007 10:44:59 -0700 (PDT) From: David Morris cc: In-Reply-To: <20071025170954.72B2422024E@quill.bollow.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Propel-ID: iz6Ur7aphJ10 X-Spam-Score: 1.6 (+) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Thu, 25 Oct 2007, Norbert Bollow wrote: > For an extreme example, consider hypothetically the case that an > essential part of the IPv6 protocol stack had such a patent issue. Well, by the time the world is ready for IPv6 I expect that patent would have expired ;-:) _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf id 0E5F5100091 for ; Thu, 25 Oct 2007 10:45:01 -0700 (PDT) Received: from egate.xpasc.com (egate.xpasc.com [10.1.2.49]) by xpasc.com (8.11.2/8.11.2) with ESMTP id l9PHix727590 for ; Thu, 25 Oct 2007 10:45:00 -0700 Date: Thu, 25 Oct 2007 10:44:59 -0700 (PDT) From: David Morris cc: In-Reply-To: <20071025170954.72B2422024E@quill.bollow.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Propel-ID: iz6Ur7aphJ10 X-Spam-Score: 1.6 (+) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Thu, 25 Oct 2007, Norbert Bollow wrote: > For an extreme example, consider hypothetically the case that an > essential part of the IPv6 protocol stack had such a patent issue. Well, by the time the world is ready for IPv6 I expect that patent would have expired ;-:) _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 14:22:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il77c-0003lF-AQ; Thu, 25 Oct 2007 14:07:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il77a-0003fj-QO; Thu, 25 Oct 2007 14:07:54 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il77a-0000rN-Ci; Thu, 25 Oct 2007 14:07:54 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9PI7nFh010936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 Oct 2007 11:07:50 -0700 Received: from [98.207.5.180] (carbuncle.qualcomm.com [129.46.226.27]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9PI7lE0019149; Thu, 25 Oct 2007 11:07:48 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <9F8D3FB94DE343A4A29A8D86@B50854F0A9192E8EC6CDA126> References: <9F8D3FB94DE343A4A29A8D86@B50854F0A9192E8EC6CDA126> Date: Thu, 25 Oct 2007 11:07:48 -0700 To: Harald Tveit Alvestrand , ietf@ietf.org, ipr-wg@ietf.org From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: Re: Offer of time on the IPR WG agenda for rechartering X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >I'd like the people who want time on the agenda to supply a text (preferably published as an I-D), which summarizes, as clearly as possible: > >- What they think has changed since the last IPR WG evaluation of patent policy > >- What changes in overall direction they think the WG should address > >- What the charter for this activity should look like > >If more than one such proposal should appear, I'd suggest giving each submitter a 5-10 minute slot for making their argument, and leaving at least half an hour for general discussion. > >Please submit I-Ds with the name pattern of draft--ipr-patent- - that would make it easy for us to find them all. > >The timeslot for the WG is Tuesday morning from 0900 to 1130; the rechartering discussion would be within the time from 1030 to 1130. Just to be clear, if someone has the view that documents like Simon's how-to should be within the charter of the working group, but that there are no changes needed to the base policy, do you still want an I-D? Or is a rationale submitted as a short statement enough? Ted _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 14:32:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il7Nk-0008Vx-50; Thu, 25 Oct 2007 14:24:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il7Ni-0008Vn-FI; Thu, 25 Oct 2007 14:24:34 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il7Ni-0001QI-1c; Thu, 25 Oct 2007 14:24:34 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1AB91259738; Thu, 25 Oct 2007 20:24:33 +0200 (CEST) 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 08883-01; Thu, 25 Oct 2007 20:24:27 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id B9B1925972E; Thu, 25 Oct 2007 20:24:27 +0200 (CEST) Message-ID: <4720DF73.5000106@alvestrand.no> Date: Thu, 25 Oct 2007 20:24:51 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Ted Hardie References: <9F8D3FB94DE343A4A29A8D86@B50854F0A9192E8EC6CDA126> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ietf@ietf.org, ipr-wg@ietf.org Subject: Re: Offer of time on the IPR WG agenda for rechartering X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Ted Hardie skrev: >> I'd like the people who want time on the agenda to supply a text (preferably published as an I-D), which summarizes, as clearly as possible: >> >> - What they think has changed since the last IPR WG evaluation of patent policy >> >> - What changes in overall direction they think the WG should address >> >> - What the charter for this activity should look like >> >> If more than one such proposal should appear, I'd suggest giving each submitter a 5-10 minute slot for making their argument, and leaving at least half an hour for general discussion. >> >> Please submit I-Ds with the name pattern of draft--ipr-patent- - that would make it easy for us to find them all. >> >> The timeslot for the WG is Tuesday morning from 0900 to 1130; the rechartering discussion would be within the time from 1030 to 1130. >> > > Just to be clear, if someone has the view that documents like Simon's > how-to should be within the charter of the working group, but that there > are no changes needed to the base policy, do you still want an I-D? Or > is a rationale submitted as a short statement enough? > In the case of Simon's I-D, there is already an existing I-D, which (if I remember rightly - it's been a long time since I've read it) explains its rationale fairly well. So a simple request to have that placed on the agenda, with a brief statement of what the desired outcome is, should be enough. Harald _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 16:14:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il8mA-0008HD-4W; Thu, 25 Oct 2007 15:53:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il8m4-0008Gy-KD; Thu, 25 Oct 2007 15:53:48 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il8lz-0002tP-AY; Thu, 25 Oct 2007 15:53:48 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9F214259750; Thu, 25 Oct 2007 21:53:42 +0200 (CEST) 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 10909-05; Thu, 25 Oct 2007 21:53:37 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5D9C825970D; Thu, 25 Oct 2007 21:53:37 +0200 (CEST) Message-ID: <4720F459.2020201@alvestrand.no> Date: Thu, 25 Oct 2007 21:54:01 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: lrosen@rosenlaw.com References: <9F8D3FB94DE343A4A29A8D86@B50854F0A9192E8EC6CDA126> <013901c81719$39b4f180$6401a8c0@LROSENTOSHIBA> In-Reply-To: <013901c81719$39b4f180$6401a8c0@LROSENTOSHIBA> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ietf@ietf.org, ipr-wg@ietf.org Subject: Re: Offer of time on the IPR WG agenda for rechartering X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Lawrence Rosen skrev: > Harald, > > I am unable to be in Vancouver for the meeting, but I hope that someone else > there will support the re-charter of the IPR WG as I suggested in my earlier > email: > > *************** > > I request that we charter the IETF IPR-WG to propose policies and > procedures, consistent with the worldwide mission of IETF, which will result > in IETF specifications unencumbered by restrictive, non-free patents. > > *************** > Thanks for the comment. I look forward to seeing your I-D, and hope you will find someone to present it in Vancouver. > I also hope that a decision on this will not be based simply on who attends > in Vancouver, but on a wider representative vote of IETF participants. > Since we don't vote, it won't be decided by a vote. I don't rule out opinion polls... _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 16:38:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il9Ff-0004xa-GU; Thu, 25 Oct 2007 16:24:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il9FU-0004vy-1n for ietf@ietf.org; Thu, 25 Oct 2007 16:24:12 -0400 Received: from [2002:4519:c427:1:220:edff:fe18:5794] (helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il9FT-0003yP-QQ for ietf@ietf.org; Thu, 25 Oct 2007 16:24:12 -0400 Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtps (tls_cipher TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50 #1 (Debian)) id 1Il9Oi-0002CT-1W; Thu, 25 Oct 2007 16:33:45 -0400 Received: from tytso by closure.thunk.org with local (Exim 4.67) (envelope-from ) id 1Il9D2-0003bZ-1m; Thu, 25 Oct 2007 16:21:40 -0400 Date: Thu, 25 Oct 2007 16:21:40 -0400 From: Theodore Tso To: Norbert Bollow Bcc: tytso@mit.edu Message-ID: <20071025202139.GA12393@thunk.org> References: <007001c8165f$a6007090$6401a8c0@LROSENTOSHIBA> <471FC008.7070901@gmail.com> <20071025153346.GC22103@thunk.org> <20071025160042.C8E8F22024E@quill.bollow.ch> <20071025163925.GA6456@thunk.org> <20071025170954.72B2422024E@quill.bollow.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071025170954.72B2422024E@quill.bollow.ch> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false X-Spam-Score: -0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ietf@ietf.org Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Thu, Oct 25, 2007 at 07:09:54PM +0200, Norbert Bollow wrote: > > And I would argue that the above issue is not a matter of concern to > > the IETF. Having a reference implementation to encourage adoption of > > the spec, that is of IETF's concern. The issue of GPL requirements > > is, I would argue, Not Our Problem. > > Is it really your position that that is in no case a concern that IETF > should consider??? > > For an extreme example, consider hypothetically the case that an > essential part of the IPv6 protocol stack had such a patent issue. I was thinking mainly about protocols used by application programs. I agree that something essential needed for IPv6, that might be something that an individual wg might want to consider. But in terms of a blanket policy that would apply to *ALL* IETF protocols? That would something that is really NOT an IETF-wide concern. - Ted _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 16:38:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il9Lu-0003Ne-KE; Thu, 25 Oct 2007 16:30:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il9Lt-0003Mu-Gf for ietf@ietf.org; Thu, 25 Oct 2007 16:30:49 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il9Ls-0005QQ-W2 for ietf@ietf.org; Thu, 25 Oct 2007 16:30:49 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 8AF121EE30F; Thu, 25 Oct 2007 16:30:48 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euu1e+ch-RHd; Thu, 25 Oct 2007 16:30:46 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 0051B1EE305; Thu, 25 Oct 2007 16:30:41 -0400 (EDT) Message-ID: <4720FCFA.7080009@cs.utk.edu> Date: Thu, 25 Oct 2007 16:30:50 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: lrosen@rosenlaw.com References: <18199.55877.791858.498365@swbmbp.local><03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA><877iljv6ed.fsf@mocca.josefsson.org><042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA><2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com><471A5668.8060505@gmail.com><048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA><20071022195723.4D9A22202DA@quill.bollow.ch><20071023105651.8D9AC2202DA@quill.bollow.ch><87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> <87fy00vn1l.fsf@mocca.josefsson.org> <471FB60B.3070304@gmail.com> <20071024214601.28e866ce@cs.columbia.edu> <00d801c81689$f64c5f30$6401a8c0@LROSENTOSHIBA> In-Reply-To: <00d801c81689$f64c5f30$6401a8c0@LROSENTOSHIBA> X-Enigmail-Version: 0.95.4 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ietf@ietf.org Subject: Re: When is using patented technology appropriate? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Lawrence Rosen wrote: > Steven Bellovin wrote: > >> Right. Any IPR policy has to acknowledge the fact that relevant >> patents can be owned by non-troll non-participants. (Too many >> negatives there -- what I'm saying is that IETFers don't know of all >> patents in the space, and there are real patent owners who care about >> their patents, even though they aren't trolls.) >> > > I agree, but I suggest that our new IPR policy ought to set expectations for > how we deal procedurally with such outside encumbrances when discovered. The > defensive termination provision in most contributors' IETF patent grants can > also help to protect our specifications from trolls and some third-party > patent owners, depending upon how those grants are worded. > For several reasons, it is difficult to imagine an IETF-wide procedure that allows the existence of a patent to trump other considerations of protocol feasibility and deployability: - Many patents are believed to be invalid or indefensible. IETF as an organization cannot get in a position of deciding whether a patent is valid or defensible, both because it doesn't really have the resources or in-house expertise to do this, and because the only way to know for sure is to go through a lengthy court process, perhaps in several different countries. And yet, if there is a consensus among those who are invested in the technology that a particular patent isn't going to present an actual obstacle to deployment, it makes sense to let it go forward. The alternative - letting a dubious patent block or significantly delay approval of an IETF standard - gives dubious patents much more power than they deserve. - A similar argument can be made for patents that are valid and defensible, but for which the applicability to a given protocol is dubious. - There have been cases in the past where apparently valid and applicable patents, existed but would expire soon. Some of our standards appear have a useful lifetime of many decades. From that point of view, a patent that has been in force for a few years might be a short-term concern. Whether this is the case depends on many factors, including the remaining lifetime of the patent and the nature of the protocol under discussion. An IETF-wide policy doesn't seem to make sense here, especially if the effect of that policy were to delay work on a protocol that probably wouldn't be ready for deployment until the patent had expired, or nearly so, anyway. - There are cases for which a patent with an RAND license presents an insignificant barrier to deployment, because a substantial monetary investment would be required in any event to implement a protocol. For instance, a protocol that inherently requires expensive hardware to implement, but for which the license fee is a small portion of that required to pay for the hardware. Again, this is something that needs to be evaluated on a case-by-case basis. - Just because it appears at first that a protocol might be impaired by the existence of a patent, doesn't mean that a workaround won't be found as the protocol is developed. This has happened many times. Also, patent holders have been known to make licenses available under more attractive terms precisely because the technology was being considered for an IETF standard. That kind of pressure/encouragement might well be more effective at making useful technology available to the Internet community than a blanket patent policy. Speaking as someone who has been involved in IETF for about 17 years now, by far the best way to ensure that IETF protocols to be safe for open source implementors is for open source implementors to participate in IETF working groups. IETF's policy of rough consensus means that every interested party has a strong voice when it comes to objecting to things that will hamper implementation or deployment. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 16:38:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il9Ff-0004xa-GU; Thu, 25 Oct 2007 16:24:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il9FU-0004vy-1n for ietf@ietf.org; Thu, 25 Oct 2007 16:24:12 -0400 Received: from [2002:4519:c427:1:220:edff:fe18:5794] (helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il9FT-0003yP-QQ for ietf@ietf.org; Thu, 25 Oct 2007 16:24:12 -0400 Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtps (tls_cipher TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50 #1 (Debian)) id 1Il9Oi-0002CT-1W; Thu, 25 Oct 2007 16:33:45 -0400 Received: from tytso by closure.thunk.org with local (Exim 4.67) (envelope-from ) id 1Il9D2-0003bZ-1m; Thu, 25 Oct 2007 16:21:40 -0400 Date: Thu, 25 Oct 2007 16:21:40 -0400 From: Theodore Tso To: Norbert Bollow Bcc: tytso@mit.edu Message-ID: <20071025202139.GA12393@thunk.org> References: <007001c8165f$a6007090$6401a8c0@LROSENTOSHIBA> <471FC008.7070901@gmail.com> <20071025153346.GC22103@thunk.org> <20071025160042.C8E8F22024E@quill.bollow.ch> <20071025163925.GA6456@thunk.org> <20071025170954.72B2422024E@quill.bollow.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071025170954.72B2422024E@quill.bollow.ch> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false X-Spam-Score: -0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ietf@ietf.org Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Thu, Oct 25, 2007 at 07:09:54PM +0200, Norbert Bollow wrote: > > And I would argue that the above issue is not a matter of concern to > > the IETF. Having a reference implementation to encourage adoption of > > the spec, that is of IETF's concern. The issue of GPL requirements > > is, I would argue, Not Our Problem. > > Is it really your position that that is in no case a concern that IETF > should consider??? > > For an extreme example, consider hypothetically the case that an > essential part of the IPv6 protocol stack had such a patent issue. I was thinking mainly about protocols used by application programs. I agree that something essential needed for IPv6, that might be something that an individual wg might want to consider. But in terms of a blanket policy that would apply to *ALL* IETF protocols? That would something that is really NOT an IETF-wide concern. - Ted _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 16:38:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il9Lu-0003Ne-KE; Thu, 25 Oct 2007 16:30:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il9Lt-0003Mu-Gf for ietf@ietf.org; Thu, 25 Oct 2007 16:30:49 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il9Ls-0005QQ-W2 for ietf@ietf.org; Thu, 25 Oct 2007 16:30:49 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 8AF121EE30F; Thu, 25 Oct 2007 16:30:48 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euu1e+ch-RHd; Thu, 25 Oct 2007 16:30:46 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 0051B1EE305; Thu, 25 Oct 2007 16:30:41 -0400 (EDT) Message-ID: <4720FCFA.7080009@cs.utk.edu> Date: Thu, 25 Oct 2007 16:30:50 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: lrosen@rosenlaw.com References: <18199.55877.791858.498365@swbmbp.local><03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA><877iljv6ed.fsf@mocca.josefsson.org><042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA><2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com><471A5668.8060505@gmail.com><048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA><20071022195723.4D9A22202DA@quill.bollow.ch><20071023105651.8D9AC2202DA@quill.bollow.ch><87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> <87fy00vn1l.fsf@mocca.josefsson.org> <471FB60B.3070304@gmail.com> <20071024214601.28e866ce@cs.columbia.edu> <00d801c81689$f64c5f30$6401a8c0@LROSENTOSHIBA> In-Reply-To: <00d801c81689$f64c5f30$6401a8c0@LROSENTOSHIBA> X-Enigmail-Version: 0.95.4 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ietf@ietf.org Subject: Re: When is using patented technology appropriate? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Lawrence Rosen wrote: > Steven Bellovin wrote: > >> Right. Any IPR policy has to acknowledge the fact that relevant >> patents can be owned by non-troll non-participants. (Too many >> negatives there -- what I'm saying is that IETFers don't know of all >> patents in the space, and there are real patent owners who care about >> their patents, even though they aren't trolls.) >> > > I agree, but I suggest that our new IPR policy ought to set expectations for > how we deal procedurally with such outside encumbrances when discovered. The > defensive termination provision in most contributors' IETF patent grants can > also help to protect our specifications from trolls and some third-party > patent owners, depending upon how those grants are worded. > For several reasons, it is difficult to imagine an IETF-wide procedure that allows the existence of a patent to trump other considerations of protocol feasibility and deployability: - Many patents are believed to be invalid or indefensible. IETF as an organization cannot get in a position of deciding whether a patent is valid or defensible, both because it doesn't really have the resources or in-house expertise to do this, and because the only way to know for sure is to go through a lengthy court process, perhaps in several different countries. And yet, if there is a consensus among those who are invested in the technology that a particular patent isn't going to present an actual obstacle to deployment, it makes sense to let it go forward. The alternative - letting a dubious patent block or significantly delay approval of an IETF standard - gives dubious patents much more power than they deserve. - A similar argument can be made for patents that are valid and defensible, but for which the applicability to a given protocol is dubious. - There have been cases in the past where apparently valid and applicable patents, existed but would expire soon. Some of our standards appear have a useful lifetime of many decades. From that point of view, a patent that has been in force for a few years might be a short-term concern. Whether this is the case depends on many factors, including the remaining lifetime of the patent and the nature of the protocol under discussion. An IETF-wide policy doesn't seem to make sense here, especially if the effect of that policy were to delay work on a protocol that probably wouldn't be ready for deployment until the patent had expired, or nearly so, anyway. - There are cases for which a patent with an RAND license presents an insignificant barrier to deployment, because a substantial monetary investment would be required in any event to implement a protocol. For instance, a protocol that inherently requires expensive hardware to implement, but for which the license fee is a small portion of that required to pay for the hardware. Again, this is something that needs to be evaluated on a case-by-case basis. - Just because it appears at first that a protocol might be impaired by the existence of a patent, doesn't mean that a workaround won't be found as the protocol is developed. This has happened many times. Also, patent holders have been known to make licenses available under more attractive terms precisely because the technology was being considered for an IETF standard. That kind of pressure/encouragement might well be more effective at making useful technology available to the Internet community than a blanket patent policy. Speaking as someone who has been involved in IETF for about 17 years now, by far the best way to ensure that IETF protocols to be safe for open source implementors is for open source implementors to participate in IETF working groups. IETF's policy of rough consensus means that every interested party has a strong voice when it comes to objecting to things that will hamper implementation or deployment. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Thu Oct 25 16:59:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il9cy-0006Ku-NG; Thu, 25 Oct 2007 16:48:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il9cw-0006Kf-Pq for ietf@ietf.org; Thu, 25 Oct 2007 16:48:26 -0400 Received: from wa-out-1112.google.com ([209.85.146.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il9cq-0004vX-JU for ietf@ietf.org; Thu, 25 Oct 2007 16:48:26 -0400 Received: by wa-out-1112.google.com with SMTP id k40so1129423wah for ; Thu, 25 Oct 2007 13:47:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=5+5HYrcqfYOo+aK5o8J7AzfqmUCLW25VASjxvjz5saE=; b=GSGQMSFNxI4lje50FyEgxn2DT/p9NWIq9QuhRHu1S7rx9c7COBGEs72M7F9B13418eUgjNO3j/X2OVqhusEUIfmQaU8RimjHh6MMFTEPjHjGqfU8aG9ZFWQgolpAvJEgkt1RSl4taveCtzhUjDsfPMGizhcyxi0aY9l0mbccgWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=JyBV2iEMia13QBZQKj7ZZYCz6ohdE5d8WJpMJ5z1mkp8natXolamhuhS03sqTxnjGhWYTo4jAWSKUOaINFfQEHmWJxqeiNbOYKk3d4iXdp+BE+NPgOvJbfNJKNBGkxZfv2qPrR1ERPzqGuWSo3BSIX5eWSL6cbCBTwiMkl9H63g= Received: by 10.114.209.1 with SMTP id h1mr2526805wag.1193345275408; Thu, 25 Oct 2007 13:47:55 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id k39sm4727531wah.2007.10.25.13.47.53 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Oct 2007 13:47:55 -0700 (PDT) Message-ID: <472100F6.50200@gmail.com> Date: Fri, 26 Oct 2007 09:47:50 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Norbert Bollow References: <007001c8165f$a6007090$6401a8c0@LROSENTOSHIBA> <471FC008.7070901@gmail.com> <20071025153346.GC22103@thunk.org> <20071025160042.C8E8F22024E@quill.bollow.ch> <20071025163925.GA6456@thunk.org> <20071025170954.72B2422024E@quill.bollow.ch> In-Reply-To: <20071025170954.72B2422024E@quill.bollow.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ietf@ietf.org Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-26 06:09, Norbert Bollow wrote: > Theodore Tso wrote: > >>> I don't disagree with anything that you wrote, but the point here >>> is that if there's a patent with GPL-incompatible licensing, you >>> don't have permission to link that BSD-licensed code into a >>> GPL-licensed program and distribute the result. >> And I would argue that the above issue is not a matter of concern to >> the IETF. Having a reference implementation to encourage adoption of >> the spec, that is of IETF's concern. The issue of GPL requirements >> is, I would argue, Not Our Problem. > > Is it really your position that that is in no case a concern that IETF > should consider??? > > For an extreme example, consider hypothetically the case that an > essential part of the IPv6 protocol stack had such a patent issue. To be blunter than Ted, this is a problem that the GPL community has to solve, not the IETF. I don't mean the IETF shouldn't consider it as one factor among many when evaluating a technology choice, but the underlying issue is between the GPL and the patent regime. Our test has always been "has interoperability been demonstrated in the real world?" and that remains a pretty strong test. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 01:11:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlHC6-0002EG-BI; Fri, 26 Oct 2007 00:53:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlHC5-0001ta-8e for ietf@ietf.org; Fri, 26 Oct 2007 00:53:13 -0400 Received: from e35.co.us.ibm.com ([32.97.110.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlHBw-0002Zv-IV for ietf@ietf.org; Fri, 26 Oct 2007 00:53:04 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l9Q4r3Hd007864 for ; Fri, 26 Oct 2007 00:53:03 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9Q4r3kY125080 for ; Thu, 25 Oct 2007 22:53:03 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l9Q4r33f009733 for ; Thu, 25 Oct 2007 22:53:03 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l9Q4r272009700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 25 Oct 2007 22:53:03 -0600 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.14.1/8.12.5) with ESMTP id l9Q4r24A010910 for ; Fri, 26 Oct 2007 00:53:02 -0400 Received: (from narten@localhost) by rotala.raleigh.ibm.com (8.14.1/8.14.1/Submit) id l9Q4r25X010905 for ietf@ietf.org; Fri, 26 Oct 2007 00:53:02 -0400 Date: Fri, 26 Oct 2007 00:53:02 -0400 From: Thomas Narten Message-Id: <200710260453.l9Q4r25X010905@rotala.raleigh.ibm.com> To: ietf@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: Weekly posting summary for ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Total of 122 messages in the last 7 days. script run at: Fri Oct 26 00:53:02 EDT 2007 Messages | Bytes | Who --------+------+--------+----------+------------------------ 9.02% | 11 | 14.62% | 117248 | pbaker@verisign.com 10.66% | 13 | 9.64% | 77309 | hardie@qualcomm.com 7.38% | 9 | 8.84% | 70914 | lrosen@rosenlaw.com 8.20% | 10 | 7.42% | 59555 | hartmans-ietf@mit.edu 6.56% | 8 | 5.77% | 46263 | nb@bollow.ch 5.74% | 7 | 5.73% | 45958 | brian.e.carpenter@gmail.com 4.92% | 6 | 4.30% | 34502 | simon@josefsson.org 4.92% | 6 | 3.80% | 30450 | tytso@mit.edu 4.10% | 5 | 3.67% | 29459 | scott@kitterman.com 4.10% | 5 | 2.96% | 23717 | nobody@xyzzy.claranet.de 3.28% | 4 | 2.17% | 17418 | bortzmeyer@nic.fr 0.82% | 1 | 4.41% | 35394 | roni.even@polycom.co.il 2.46% | 3 | 2.35% | 18813 | john-ietf@jck.com 2.46% | 3 | 1.89% | 15197 | harald@alvestrand.no 1.64% | 2 | 1.69% | 13538 | petercon@microsoft.com 1.64% | 2 | 1.66% | 13280 | michael.dillon@bt.com 1.64% | 2 | 1.60% | 12803 | narten@us.ibm.com 1.64% | 2 | 1.49% | 11989 | dwm@xpasc.com 1.64% | 2 | 1.39% | 11167 | ietfdbh@comcast.net 1.64% | 2 | 1.31% | 10499 | smb@cs.columbia.edu 1.64% | 2 | 1.22% | 9795 | dot@dotat.at 0.82% | 1 | 1.15% | 9264 | lars.eggert@nokia.com 0.82% | 1 | 1.11% | 8904 | dromasca@avaya.com 0.82% | 1 | 1.06% | 8513 | moore@cs.utk.edu 0.82% | 1 | 0.79% | 6350 | swb@employees.org 0.82% | 1 | 0.78% | 6278 | jordi.palet@consulintel.es 0.82% | 1 | 0.78% | 6261 | jmh@joelhalpern.com 0.82% | 1 | 0.68% | 5463 | magnus.westerlund@ericsson.com 0.82% | 1 | 0.67% | 5351 | stephen.farrell@cs.tcd.ie 0.82% | 1 | 0.66% | 5314 | paul.hoffman@vpnc.org 0.82% | 1 | 0.64% | 5156 | hgs@cs.columbia.edu 0.82% | 1 | 0.59% | 4747 | tlyu@mit.edu 0.82% | 1 | 0.56% | 4506 | suresh.krishnan@ericsson.com 0.82% | 1 | 0.54% | 4360 | dhc2@dcrocker.net 0.82% | 1 | 0.54% | 4305 | jari.arkko@piuha.net 0.82% | 1 | 0.51% | 4087 | drc@virtualized.org 0.82% | 1 | 0.51% | 4069 | jabley@ca.afilias.info 0.82% | 1 | 0.49% | 3959 | briand@ca.afilias.info --------+------+--------+----------+------------------------ 100.00% | 122 |100.00% | 802155 | Total _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 01:44:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlHkj-0005ZP-2j; Fri, 26 Oct 2007 01:29:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlHkh-0005WV-EH for ietf@ietf.org; Fri, 26 Oct 2007 01:28:59 -0400 Received: from [2002:9be6:9d5d:1::1] (helo=izb.knu.ac.kr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlHkb-0004no-Ti for ietf@ietf.org; Fri, 26 Oct 2007 01:28:54 -0400 Received: by draba.izb.knu.ac.kr (Postfix, from userid 10001) id BB83E3EA7; Fri, 26 Oct 2007 14:28:34 +0900 (KST) Date: Fri, 26 Oct 2007 14:28:34 +0900 From: Byung-Hee HWANG To: Thomas Narten Message-ID: <20071026052834.GA12827@draba.izb.knu.ac.kr> References: <200710260453.l9Q4r25X010905@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <200710260453.l9Q4r25X010905@rotala.raleigh.ibm.com> User-Agent: Mutt/1.4.2.1i Organization: InZealBomb X-Spam-Score: -0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ietf@ietf.org Subject: Re: Weekly posting summary for ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Fri, 26 Oct 2007 00:53:02 -0400, Thomas Narten wrote: > Total of 122 messages in the last 7 days. > > script run at: Fri Oct 26 00:53:02 EDT 2007 > > Messages | Bytes | Who > --------+------+--------+----------+------------------------ > 9.02% | 11 | 14.62% | 117248 | pbaker@verisign.com > 10.66% | 13 | 9.64% | 77309 | hardie@qualcomm.com > 7.38% | 9 | 8.84% | 70914 | lrosen@rosenlaw.com > 8.20% | 10 | 7.42% | 59555 | hartmans-ietf@mit.edu > 6.56% | 8 | 5.77% | 46263 | nb@bollow.ch > 5.74% | 7 | 5.73% | 45958 | brian.e.carpenter@gmail.com > 4.92% | 6 | 4.30% | 34502 | simon@josefsson.org > 4.92% | 6 | 3.80% | 30450 | tytso@mit.edu > 4.10% | 5 | 3.67% | 29459 | scott@kitterman.com > 4.10% | 5 | 2.96% | 23717 | nobody@xyzzy.claranet.de > 3.28% | 4 | 2.17% | 17418 | bortzmeyer@nic.fr > 0.82% | 1 | 4.41% | 35394 | roni.even@polycom.co.il > 2.46% | 3 | 2.35% | 18813 | john-ietf@jck.com > 2.46% | 3 | 1.89% | 15197 | harald@alvestrand.no > 1.64% | 2 | 1.69% | 13538 | petercon@microsoft.com > 1.64% | 2 | 1.66% | 13280 | michael.dillon@bt.com > 1.64% | 2 | 1.60% | 12803 | narten@us.ibm.com > 1.64% | 2 | 1.49% | 11989 | dwm@xpasc.com > 1.64% | 2 | 1.39% | 11167 | ietfdbh@comcast.net > 1.64% | 2 | 1.31% | 10499 | smb@cs.columbia.edu > 1.64% | 2 | 1.22% | 9795 | dot@dotat.at > 0.82% | 1 | 1.15% | 9264 | lars.eggert@nokia.com > 0.82% | 1 | 1.11% | 8904 | dromasca@avaya.com > 0.82% | 1 | 1.06% | 8513 | moore@cs.utk.edu > 0.82% | 1 | 0.79% | 6350 | swb@employees.org > 0.82% | 1 | 0.78% | 6278 | jordi.palet@consulintel.es > 0.82% | 1 | 0.78% | 6261 | jmh@joelhalpern.com > 0.82% | 1 | 0.68% | 5463 | magnus.westerlund@ericsson.com > 0.82% | 1 | 0.67% | 5351 | stephen.farrell@cs.tcd.ie > 0.82% | 1 | 0.66% | 5314 | paul.hoffman@vpnc.org > 0.82% | 1 | 0.64% | 5156 | hgs@cs.columbia.edu > 0.82% | 1 | 0.59% | 4747 | tlyu@mit.edu > 0.82% | 1 | 0.56% | 4506 | suresh.krishnan@ericsson.com > 0.82% | 1 | 0.54% | 4360 | dhc2@dcrocker.net > 0.82% | 1 | 0.54% | 4305 | jari.arkko@piuha.net > 0.82% | 1 | 0.51% | 4087 | drc@virtualized.org > 0.82% | 1 | 0.51% | 4069 | jabley@ca.afilias.info > 0.82% | 1 | 0.49% | 3959 | briand@ca.afilias.info > --------+------+--------+----------+------------------------ > 100.00% | 122 |100.00% | 802155 | Total somebody has sent mail as html mass everytime. that's why pbaker@ is top lank as bytes order. -- May The DKIM Be With You! _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 01:48:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlHxf-0007Mf-9J; Fri, 26 Oct 2007 01:42:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlHxd-0007KG-RU for ietf@ietf.org; Fri, 26 Oct 2007 01:42:21 -0400 Received: from [2002:9be6:9d5d:1::1] (helo=izb.knu.ac.kr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlHxZ-0005FB-4p for ietf@ietf.org; Fri, 26 Oct 2007 01:42:21 -0400 Received: by draba.izb.knu.ac.kr (Postfix, from userid 10001) id 4B0A23EA4; Fri, 26 Oct 2007 14:42:14 +0900 (KST) Date: Fri, 26 Oct 2007 14:42:14 +0900 From: Byung-Hee HWANG To: ietf@ietf.org Message-ID: <20071026054214.GA13262@draba.izb.knu.ac.kr> References: <200710260453.l9Q4r25X010905@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <200710260453.l9Q4r25X010905@rotala.raleigh.ibm.com> User-Agent: Mutt/1.4.2.1i Organization: InZealBomb X-Spam-Score: -0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Thomas Narten Subject: Re: Weekly posting summary for ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Fri, 26 Oct 2007 00:53:02 -0400, Thomas Narten wrote: > Total of 122 messages in the last 7 days. > > script run at: Fri Oct 26 00:53:02 EDT 2007 > > Messages | Bytes | Who > --------+------+--------+----------+------------------------ > 9.02% | 11 | 14.62% | 117248 | pbaker@verisign.com > 10.66% | 13 | 9.64% | 77309 | hardie@qualcomm.com > 7.38% | 9 | 8.84% | 70914 | lrosen@rosenlaw.com > 8.20% | 10 | 7.42% | 59555 | hartmans-ietf@mit.edu > 6.56% | 8 | 5.77% | 46263 | nb@bollow.ch > 5.74% | 7 | 5.73% | 45958 | brian.e.carpenter@gmail.com > 4.92% | 6 | 4.30% | 34502 | simon@josefsson.org > 4.92% | 6 | 3.80% | 30450 | tytso@mit.edu > 4.10% | 5 | 3.67% | 29459 | scott@kitterman.com > 4.10% | 5 | 2.96% | 23717 | nobody@xyzzy.claranet.de > 3.28% | 4 | 2.17% | 17418 | bortzmeyer@nic.fr > 0.82% | 1 | 4.41% | 35394 | roni.even@polycom.co.il > 2.46% | 3 | 2.35% | 18813 | john-ietf@jck.com > 2.46% | 3 | 1.89% | 15197 | harald@alvestrand.no > 1.64% | 2 | 1.69% | 13538 | petercon@microsoft.com > 1.64% | 2 | 1.66% | 13280 | michael.dillon@bt.com > 1.64% | 2 | 1.60% | 12803 | narten@us.ibm.com > 1.64% | 2 | 1.49% | 11989 | dwm@xpasc.com > 1.64% | 2 | 1.39% | 11167 | ietfdbh@comcast.net > 1.64% | 2 | 1.31% | 10499 | smb@cs.columbia.edu > 1.64% | 2 | 1.22% | 9795 | dot@dotat.at > 0.82% | 1 | 1.15% | 9264 | lars.eggert@nokia.com > 0.82% | 1 | 1.11% | 8904 | dromasca@avaya.com > 0.82% | 1 | 1.06% | 8513 | moore@cs.utk.edu > 0.82% | 1 | 0.79% | 6350 | swb@employees.org > 0.82% | 1 | 0.78% | 6278 | jordi.palet@consulintel.es > 0.82% | 1 | 0.78% | 6261 | jmh@joelhalpern.com > 0.82% | 1 | 0.68% | 5463 | magnus.westerlund@ericsson.com > 0.82% | 1 | 0.67% | 5351 | stephen.farrell@cs.tcd.ie > 0.82% | 1 | 0.66% | 5314 | paul.hoffman@vpnc.org > 0.82% | 1 | 0.64% | 5156 | hgs@cs.columbia.edu > 0.82% | 1 | 0.59% | 4747 | tlyu@mit.edu > 0.82% | 1 | 0.56% | 4506 | suresh.krishnan@ericsson.com > 0.82% | 1 | 0.54% | 4360 | dhc2@dcrocker.net > 0.82% | 1 | 0.54% | 4305 | jari.arkko@piuha.net > 0.82% | 1 | 0.51% | 4087 | drc@virtualized.org > 0.82% | 1 | 0.51% | 4069 | jabley@ca.afilias.info > 0.82% | 1 | 0.49% | 3959 | briand@ca.afilias.info > --------+------+--------+----------+------------------------ > 100.00% | 122 |100.00% | 802155 | Total somebody has sent mail as html mass everytime. that's why pbaker@ is top lank by bytes order. -- "i love your daughter with all respect." -- Enzo _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 04:35:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlKGU-0003TV-KX; Fri, 26 Oct 2007 04:09:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlKGS-0003OT-J1 for ietf@ietf.org; Fri, 26 Oct 2007 04:09:56 -0400 Received: from tarsus.bollow.ch ([82.195.230.222]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlKGP-0000bp-To for ietf@ietf.org; Fri, 26 Oct 2007 04:09:54 -0400 Received: from tarsus.bollow.ch (localhost [127.0.0.1]) by tarsus.bollow.ch (Postfix) with ESMTP id B7F0AB28149 for ; Fri, 26 Oct 2007 10:46:21 +0200 (CEST) Authentication-Results: tarsus.bollow.ch from=nb@bollow.ch; domainkey=neutral (no signature; no policy for bollow.ch) Received: from quill.bollow.ch (48-30.203-62.cust.bluewin.ch [62.203.30.48]) by tarsus.bollow.ch (Postfix) with ESMTP for ; Fri, 26 Oct 2007 10:46:21 +0200 (CEST) Received: by quill.bollow.ch (Postfix, from userid 1000) id 8460D22024E; Fri, 26 Oct 2007 10:13:46 +0200 (CEST) From: Norbert Bollow Organization: Bollow Software Economics Research MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=iso-8859-1 To: ietf@ietf.org In-reply-to: <472100F6.50200@gmail.com> (message from Brian E Carpenter on Fri, 26 Oct 2007 09:47:50 +1300) References: <007001c8165f$a6007090$6401a8c0@LROSENTOSHIBA> <471FC008.7070901@gmail.com> <20071025153346.GC22103@thunk.org> <20071025160042.C8E8F22024E@quill.bollow.ch> <20071025163925.GA6456@thunk.org> <20071025170954.72B2422024E@quill.bollow.ch> <472100F6.50200@gmail.com> Message-Id: <20071026081346.8460D22024E@quill.bollow.ch> Date: Fri, 26 Oct 2007 10:13:46 +0200 (CEST) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Brian E Carpenter wrote: > On 2007-10-26 06:09, Norbert Bollow wrote: > > For an extreme example, consider hypothetically the case that an > > essential part of the IPv6 protocol stack had such a patent issue. >=20 > To be blunter than Ted, this is a problem that the GPL community > has to solve, not the IETF. *If* in some way a standard for patent licenses gets chosen which is strict enough to guarantee compatibility with the concept of copyleft open source / free software, but which however turns out not to guarantee compatibility with the GPL, then I agree that it is acceptable to say the remaining part of the problem is something that the GPL community has to solve, for example by creating a GPLv4 which is compatible with a larger set of patent licenses than GPLv3 is. However, in practice, incompatibility issues between patent licenses and any version of the GPL which has been published so far are not typically the result of specifics of how the GPL implements the concept of copyleft, but rather the incompatibility issues usually result from those patent licenses being incompatible already with the basic concept of open source / free software. Combining such a patent license with a copyright license of any kind for some program cannot possibly result in a program which is open source / free software. Therefore copyleft licenses must by definition be incompatible with such patent licenses. The question is this: Is copyleft open source / free software so unimportant with regard to any area of internet standards that it would be justifiable to adopt any specification with fundamentally incompatible patent situation as a standards-track RFC? I believe that the answer to this question very clearly is no! For justification of this position I point to the facts that Microsoft is clearly acting like it perceives copyleft open source / free software to be the main threat for their near-monopoly market position, and that in the domain of networking equipment where there is not a problem with a Microsoft near-monopoly, a very similar problem nevertheless exists from the perspective of developing countries. Greetings, Norbert. --=20 Norbert Bollow http://Norbert.ch President of the Swiss Internet User Group SIUG http://SIUG.ch Working on establishing a non-corrupt and truly /open/ international standards organization http://OpenISO.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 11:05:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQYM-0007vE-JW; Fri, 26 Oct 2007 10:52:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQYL-0007mU-6f for ietf@ietf.org; Fri, 26 Oct 2007 10:52:49 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlQY9-0007xL-7J for ietf@ietf.org; Fri, 26 Oct 2007 10:52:44 -0400 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l9QEmD56024738; Fri, 26 Oct 2007 07:48:15 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Oct 2007 15:51:46 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 26 Oct 2007 07:51:46 -0700 Message-ID: <2788466ED3E31C418E9ACC5C3166155707A473@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <20071025202139.GA12393@thunk.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A priori IPR choices Thread-Index: AcgXRrlBFaDplsB2RMmgVqiz3M6WUAAkAIsA From: "Hallam-Baker, Phillip" To: "Theodore Tso" , "Norbert Bollow" X-OriginalArrivalTime: 26 Oct 2007 14:51:46.0727 (UTC) FILETIME=[BB481B70:01C817DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: ietf@ietf.org Subject: RE: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I do not believe in a blanket policy, nor am I proposing one.=20 What I want to do is to establish an effective constraint against Patent = Weasels. A Patent Weasel is not the same as a Patent Troll. A Troll = waits till you have built the bridge and then tells you that he wants a = toll. A Weasel helps you to build the bridge by promising that they will give = you an open license but is deliberately vague as to what the actual = terms of the license will be. It is always something that will be = postponed into the future and meanwhile you continue to build the = bridge. This is of course what some people are concerned that F500 patent = powerhouses might do, or at least what some people will say is their = concern. I am not really worried about that, a large company with a real = business is always much more concerned about their brand and their = reputation and their ongoing business. The real concern in my view is two-fold. First there is the OpenMarket = problem, a company files a patent with a ridiculous claim in it, goes = bust and gets bought out. Second there is the patent weasel who is = really planning to become a troll.=20 The reason I would like to be able to put a RANDZ requirement in a WG = charter is that there are certain areas where I would like to see a = working group form, where there is a set of clearly unencumbered = technology that can be used and alternative technology that is owned by = a proprietary concern.=20 I want a WG to be able to make it clear to such rights holders from the = outset that their technology is going to be stripped from the documents = if they fail to deliver acceptable access terms before the start of last = call. For example, say were were going to develop an audio compression = standard (I choose this because its something we are not going to do and = thus clearly an example). The starting point candidates might be AC3, = AAC, OGG-Vorbis, MP3, TROLL, SPLUNGE, etc. Now there are many ways to compress audio and many ways to evaluate the = value of the result. Newer algorithms require less bandwidth, better = quality, whatever. But from my point of view I simply don't care. If the = SPLUNGE CODEC is acceptably compact and offers acceptable quality and is = out of patent (and thus definitively open) I simply do not care how = compact or efficient the proprietary contenders might be. Having chosen the SPLUNGE codec and thus guaranteed a level of basic = interoperability the value of the patents on the alternatives has been = diminished considerably. If the mandated codec in APP is TROLL, the = owner of the TROLL patents can charge an amount proportional to the = value of APP. If the mandated codec is SPLUNGE the owner of the TROLL = patent can only charge for the marginal increase in value it provides, = (APP(TROLL) - APP(SPLUNGE)). So when starting the CODEC WG it makes good sense to require RANDZ = upfront, in fact identifying an unencumbered CODEC might well be the = entire point of the exercise. Clearly if we are going to develop a standard for Content Rights = Management or the like it is pretty unlikely that a group could succeed = if its charter mandated RANDZ (although this might change as the patents = expire). > -----Original Message----- > From: Theodore Tso [mailto:tytso@mit.edu]=20 > Sent: Thursday, October 25, 2007 4:22 PM > To: Norbert Bollow > Cc: ietf@ietf.org > Subject: Re: A priori IPR choices >=20 > On Thu, Oct 25, 2007 at 07:09:54PM +0200, Norbert Bollow wrote: > > > And I would argue that the above issue is not a matter of=20 > concern to=20 > > > the IETF. Having a reference implementation to encourage=20 > adoption=20 > > > of the spec, that is of IETF's concern. The issue of GPL=20 > > > requirements is, I would argue, Not Our Problem. > >=20 > > Is it really your position that that is in no case a=20 > concern that IETF=20 > > should consider??? > >=20 > > For an extreme example, consider hypothetically the case that an=20 > > essential part of the IPv6 protocol stack had such a patent issue. >=20 > I was thinking mainly about protocols used by application=20 > programs. I agree that something essential needed for IPv6,=20 > that might be something that an individual wg might want to=20 > consider. But in terms of a blanket policy that would apply=20 > to *ALL* IETF protocols? That would something that is really=20 > NOT an IETF-wide concern. >=20 > - Ted >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 12:23:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlRoB-00077u-3Z; Fri, 26 Oct 2007 12:13:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlRo9-0006z0-9h for ietf@ietf.org; Fri, 26 Oct 2007 12:13:13 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlRo3-0002qG-50 for ietf@ietf.org; Fri, 26 Oct 2007 12:13:13 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQJ00EAN11FOO@usaga01-in.huawei.com> for ietf@ietf.org; Fri, 26 Oct 2007 09:12:51 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JQJ001UM11CUN@usaga01-in.huawei.com> for ietf@ietf.org; Fri, 26 Oct 2007 09:12:51 -0700 (PDT) Date: Fri, 26 Oct 2007 11:11:59 -0500 From: Spencer Dawkins To: ietf@ietf.org Message-id: <0f0001c817ea$f02a0190$6501a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <2788466ED3E31C418E9ACC5C3166155707A473@mou1wnexmb09.vcorp.ad.vrsn.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi, Phil, I'm not seeing anything in your proposal that requires changes to the IPR procedures in IETF - are you? I AM seeing something in your proposal that could reasonably be adopted by specific working groups, and I AM seeing something that might reasonably be developed into an Informational RFC(*) (heck, maybe even an ION) saying "some IETF participants worry about X, so we're explicitly pointing out that IETF working groups can do Y to reduce the chances of X happening, and here's how to do Y". If there's any gap between the tools we have and what you're suggesting, it's your wish to have this constraint IN THE WORKING GROUP CHARTER. Is that critical? and if so, is there any OTHER way to obtain WG consensus and document it, so the WG doesn't have to keep defending the choice? I AM thinking that including IPR constraints in the charter would set off IESG review for charter changes if the WG changes its mind - I'm not sure that's helpful, and it's certainly not required today. Thanks, Spencer (*) The IPR working group has developed Informational RFCs offered as guidance in the past - I'm sure Phil knows about http://www.ietf.org/rfc/rfc3669.txt, but others may not have noticed it. From: "Hallam-Baker, Phillip" To: "Theodore Tso" ; "Norbert Bollow" Cc: Sent: Friday, October 26, 2007 9:51 AM Subject: RE: A priori IPR choices The reason I would like to be able to put a RANDZ requirement in a WG charter is that there are certain areas where I would like to see a working group form, where there is a set of clearly unencumbered technology that can be used and alternative technology that is owned by a proprietary concern. I want a WG to be able to make it clear to such rights holders from the outset that their technology is going to be stripped from the documents if they fail to deliver acceptable access terms before the start of last call. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:46:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTA8-0000Nd-Bw; Fri, 26 Oct 2007 13:40:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iis0O-0007PU-3L for ietf@ietf.org; Fri, 19 Oct 2007 09:35:12 -0400 Received: from mail.baltimorecity.gov ([141.157.34.24] helo=balt-exfe01-srv.baltimore.city) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iis0D-000803-Us for ietf@ietf.org; Fri, 19 Oct 2007 09:35:08 -0400 Received: from balt-exch1-srv.baltimore.city ([169.156.54.200]) by balt-exfe01-srv.baltimore.city with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Oct 2007 09:34:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Oct 2007 09:34:40 -0400 Message-ID: <15BC669CF041394BA59CD172B9991DC10323FE45@balt-exch1-srv.baltimore.city> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Experimental TLS Authorization Standard Thread-Index: AcgSVM0XLCTYSz5vTwSMZQz6W1SriQ== From: "Craig, David" To: X-OriginalArrivalTime: 19 Oct 2007 13:34:41.0678 (UTC) FILETIME=[CDA562E0:01C81254] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-Mailman-Approved-At: Fri, 26 Oct 2007 13:39:36 -0400 Cc: campaigns@fsf.org, dlc@radix.net Subject: Experimental TLS Authorization Standard X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1353175865==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============1353175865== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81254.CD197A34" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81254.CD197A34 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I trust the IETF to not endorse any manner of "standard" that is encumbered by one or more patents. All standards must be implementable by whosoever will without the need to license technology. The provision of nonretractable royalty-free licensing available to whosoever will may be sufficient to adequately open such a standard but I feel it is better not to have IETF approval of proprietary technology. Please keep the Internet open. =20 ------_=_NextPart_001_01C81254.CD197A34 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I trust the IETF to not endorse any manner of = “standard” that is encumbered by one or more patents.  All standards must be implementable by whosoever will without the need to license = technology.  The provision of nonretractable royalty-free licensing available to = whosoever will may be sufficient to adequately open such a standard but I feel it is = better not to have IETF approval of proprietary technology.  Please keep = the Internet open. 

------_=_NextPart_001_01C81254.CD197A34-- --===============1353175865== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============1353175865==-- From ietf-bounces@ietf.org Fri Oct 26 13:47:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT1H-00035H-NO; Fri, 26 Oct 2007 13:30:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkKue-0003fT-0l for ietf@ietf.org; Tue, 23 Oct 2007 10:39:20 -0400 Received: from camaya.net ([80.190.253.160] helo=mail.camaya.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkKuT-0003LP-Q3 for ietf@ietf.org; Tue, 23 Oct 2007 10:39:15 -0400 Received: from [192.168.87.6] (unknown [192.168.87.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.camaya.net (Postfix) with ESMTP id 8247BD815F; Tue, 23 Oct 2007 16:49:14 +0200 (CEST) From: Jakob =?utf-8?q?Schr=C3=B6ter?= To: ietf@ietf.org Date: Tue, 23 Oct 2007 16:26:54 +0200 User-Agent: KMail/1.9.7 Organization: FIfF e.V. MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200710231626.54743.js@fiff.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:30:22 -0400 Cc: campaigns@fsf.org Subject: FIfF opposes making TLS-authz an experimental standard X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org The Forum Informatikerinnen und Informatiker fuer Frieden und=20 gesellschaftliche Verantwortung e.V. (FIfF) (Forum Computer Professionals f= or=20 Peace and Social Responsibility) opposes publication of=20 draft-housley-tls-authz-extns as an experimental standard. We believe that publication of patent-encumbered standards is unacceptable = and=20 we welcome the IETF's decision not to publish the draft on the standards=20 track. Patent-free standards are not only important for Free and Open-Source=20 Software, but for the entire software industry. We ask you to respect the consensus that has been reached and not to publis= h=20 this draft at all. The FIfF The Forum Informatikerinnen und Informatiker fuer Frieden und=20 gesellschaftliche Verantwortung e.V. (FIfF) is an association of computer=20 professionals, educating the public about a wide range of IT-related issues. Bremen, Germany October 23, 2007 Jakob Schr=C3=B6ter on behalf of the FIfF Board http://www.fiff.de _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:47:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTA9-0000Rw-Mz; Fri, 26 Oct 2007 13:40:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkHif-0001RJ-IJ for ietf@ietf.org; Tue, 23 Oct 2007 07:14:45 -0400 Received: from mailout.uni-due.de ([132.252.185.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkHia-0001is-0r for ietf@ietf.org; Tue, 23 Oct 2007 07:14:40 -0400 Received: from [132.252.79.233] (mond.dida.physik.uni-due.de [132.252.79.233]) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id l9NBEiub003359; Tue, 23 Oct 2007 13:14:47 +0200 Message-ID: <471DD798.5020406@uni-due.de> Date: Tue, 23 Oct 2007 13:14:32 +0200 From: Eike Lange User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: ietf@ietf.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Scanned: SpamAssassin: 3.001009 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 X-Spam-Score: 2.2 (++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:39:36 -0400 Cc: campaigns@fsf.org Subject: TLS Auth X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Dear Sirs, herewith, I would like to ask you to reject TLS authorization as some kind of standard. I, as a software developer, cannot implement this standard without dropping into the patent trap, having to pay the patent fees or, what is worse, cannot implement some kind of free software. Please keep standards free. Eike Lange University Duisburg-Essen Germany _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:47:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT7t-00075P-VW; Fri, 26 Oct 2007 13:37:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijefc-00078j-Kw for ietf@ietf.org; Sun, 21 Oct 2007 13:33:00 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjefU-0000XU-En for ietf@ietf.org; Sun, 21 Oct 2007 13:32:58 -0400 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.177.2; Sun, 21 Oct 2007 10:32:11 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk1-exhub-c104.redmond.corp.microsoft.com ([157.56.116.117]) with mapi; Sun, 21 Oct 2007 10:32:11 -0700 From: Peter Constable To: "ietf@ietf.org" Date: Sun, 21 Oct 2007 10:32:02 -0700 Thread-Topic: Re: Last Call: draft-klensin-unicode-escapes (ASCII Escaping ofUnicode Characters) to BCP Thread-Index: AcgUCEqi2OypWGDCQZeZV8tB9o5cLg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f X-Mailman-Approved-At: Fri, 26 Oct 2007 13:37:24 -0400 Subject: Re: Last Call: draft-klensin-unicode-escapes (ASCII Escaping ofUnicode Characters) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I have a terminological objection to this draft, mainly in section 2. I hav= e other comments regarding section 2 I'll mention. First, terminology: the heading for section 2 has "...Table Position...", a= nd the body refers to "code point position in the table". While the term "c= ode table" could have been used in the Unicode Standard to refer to the enc= oded entities and their encoding, it is not. The Unicode Standard uses these terms: - It uses "character set" and "character repertoire" for the collection of = elements being encoded, and "coded character set" for the set of pairs of s= uch elements and their encoded representations. - It uses "codespace" to refer to a range of numeric values used as encoded= representations, and specifically "Unicode codespace" for the range 0 to 1= 0FFFF (hex). - It uses "code point" or "code position" (synonyms) for values in the Unic= ode codespace. Thus, the appropriate term here is simply "code point" or "code position". = "Table position" and "position in the table" are not appropriate since the = Standard never uses "table" in this regard. And "code point position" is re= dundant. Perhaps the wording was attempting to differentiate between code p= oints and various encoded representations of code points. But the latter ar= e not code points, so there isn't really any ambiguity. A possible refinement might be to use "Unicode Scalar Value": this refers t= o code points other than surrogate code points. By definition in the Standa= rd, encoded characters can only be assigned to a Unicode Scalar Value. I do= n't see this as a necessary change in the draft, however. Now for other comments on section 2. The draft has: "However, when information about characters is to be processed by people, information about the Unicode code point is preferable to a further encoding of the encoded form of the character." Information about the code point? (It is numeric. It is an integer. It is n= on-negative. It is in the range 0 to 10FFFF. It is even. It is divisible by= 17. It is the same value as is found on the license plate of John Doe's ca= r.) I think it is the code point itself that is to be preferred. Also, "a f= urther encoding of the encoding form" isn't going to be clear to readers. (= I'm not sure myself what these words mean themselves; I can guess at what t= he author meant, though am not positive.) Thus, I'd change this text to: "However, when information about characters is to be processed by people, reference to the Unicode code point is preferable to encoded representations of the code point." Now, section 2 is talking about alternate representations of an encoded cha= racter, but the flow is a bit mixed up, IMO. The first paragraph says that = there are different equivalent representations but that the Unicode code po= int is preferred. Then the next paragraph revisits the same thing in more d= etail. The sentence from the first paragraph discussed above, once revised = so that it makes a clear statement, already says what paragraph two says in= greater detail. Whether a more succinct or more detailed statement is pref= erred, just say it once. Of course, if the more detailed paragraph two is kept, "code point position= in the table" should be changed to "code point". Also from paragraph two: "the UTF-8 encoding or some other short-form encoding" The term "short-form encoding" isn't explained here and may not be understo= od. I can only guess what is meant. If the intended meaning is what I think= (a reference to shortest-form versus non-shortest-form UTF-8), then I don'= t think it's really relevant. Either way, I'd change the wording to: "the UTF-8 encoding or some other encoding form" (Encoding form is a term defined in the Unicode Standard.) Also: "the other encodes the octets of" I don't think octets are encoded; they are simply referenced using some not= ational system. Thus, change to: "the other uses the octets of ... in some representation." (This gives parallel wording for the two kinds of reference.) Finally: "the Unicode code point forms" Drop "forms": "the Unicode code points" Peter Constable _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:47:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT7t-00075P-VW; Fri, 26 Oct 2007 13:37:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijefc-00078j-Kw for ietf@ietf.org; Sun, 21 Oct 2007 13:33:00 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjefU-0000XU-En for ietf@ietf.org; Sun, 21 Oct 2007 13:32:58 -0400 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.177.2; Sun, 21 Oct 2007 10:32:11 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk1-exhub-c104.redmond.corp.microsoft.com ([157.56.116.117]) with mapi; Sun, 21 Oct 2007 10:32:11 -0700 From: Peter Constable To: "ietf@ietf.org" Date: Sun, 21 Oct 2007 10:32:02 -0700 Thread-Topic: Re: Last Call: draft-klensin-unicode-escapes (ASCII Escaping ofUnicode Characters) to BCP Thread-Index: AcgUCEqi2OypWGDCQZeZV8tB9o5cLg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f X-Mailman-Approved-At: Fri, 26 Oct 2007 13:37:24 -0400 Subject: Re: Last Call: draft-klensin-unicode-escapes (ASCII Escaping ofUnicode Characters) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I have a terminological objection to this draft, mainly in section 2. I hav= e other comments regarding section 2 I'll mention. First, terminology: the heading for section 2 has "...Table Position...", a= nd the body refers to "code point position in the table". While the term "c= ode table" could have been used in the Unicode Standard to refer to the enc= oded entities and their encoding, it is not. The Unicode Standard uses these terms: - It uses "character set" and "character repertoire" for the collection of = elements being encoded, and "coded character set" for the set of pairs of s= uch elements and their encoded representations. - It uses "codespace" to refer to a range of numeric values used as encoded= representations, and specifically "Unicode codespace" for the range 0 to 1= 0FFFF (hex). - It uses "code point" or "code position" (synonyms) for values in the Unic= ode codespace. Thus, the appropriate term here is simply "code point" or "code position". = "Table position" and "position in the table" are not appropriate since the = Standard never uses "table" in this regard. And "code point position" is re= dundant. Perhaps the wording was attempting to differentiate between code p= oints and various encoded representations of code points. But the latter ar= e not code points, so there isn't really any ambiguity. A possible refinement might be to use "Unicode Scalar Value": this refers t= o code points other than surrogate code points. By definition in the Standa= rd, encoded characters can only be assigned to a Unicode Scalar Value. I do= n't see this as a necessary change in the draft, however. Now for other comments on section 2. The draft has: "However, when information about characters is to be processed by people, information about the Unicode code point is From ietf-bounces@ietf.org Fri Oct 26 13:47:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT7t-00075P-VW; Fri, 26 Oct 2007 13:37:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijefc-00078j-Kw for ietf@ietf.org; Sun, 21 Oct 2007 13:33:00 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjefU-0000XU-En for ietf@ietf.org; Sun, 21 Oct 2007 13:32:58 -0400 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.177.2; Sun, 21 Oct 2007 10:32:11 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk1-exhub-c104.redmond.corp.microsoft.com ([157.56.116.117]) with mapi; Sun, 21 Oct 2007 10:32:11 -0700 From: Peter Constable To: "ietf@ietf.org" Date: Sun, 21 Oct 2007 10:32:02 -0700 Thread-Topic: Re: Last Call: draft-klensin-unicode-escapes (ASCII Escaping ofUnicode Characters) to BCP Thread-Index: AcgUCEqi2OypWGDCQZeZV8tB9o5cLg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f X-Mailman-Approved-At: Fri, 26 Oct 2007 13:37:24 -0400 Subject: Re: Last Call: draft-klensin-unicode-escapes (ASCII Escaping ofUnicode Characters) to BCP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I have a terminological objection to this draft, mainly in section 2. I hav= e other comments regarding section 2 I'll mention. First, terminology: the heading for section 2 has "...Table Position...", a= nd the body refers to "code point position in the table". While the term "c= ode table" could have been used in the Unicode Standard to refer to the enc= oded entities and their encoding, it is not. The Unicode Standard uses these terms: - It uses "character set" and "character repertoire" for the collection of = elements being encoded, and "coded character set" for the set of pairs of s= uch elements and their encoded representations. - It uses "codespace" to refer to a range of numeric values used as encoded= representations, and specifically "Unicode codespace" for the range 0 to 1= 0FFFF (hex). - It uses "code point" or "code position" (synonyms) for values in the Unic= ode codespace. Thus, the appropriate term here is simply "code point" or "code position". = "Table position" and "position in the table" are not appropriate since the = Standard never uses "table" in this regard. And "code point position" is re= dundant. Perhaps the wording was attempting to differentiate between code p= oints and various encoded representations of code points. But the latter ar= e not code points, so there isn't really any ambiguity. A possible refinement might be to use "Unicode Scalar Value": this refers t= o code points other than surrogate code points. By definition in the Standa= rd, encoded characters can only be assigned to a Unicode Scalar Value. I do= n't see this as a necessary change in the draft, however. Now for other comments on section 2. The draft has: "However, when information about characters is to be processed by people, information about the Unicode code point is preferable to a further encoding of the encoded form of the character." Information about the code point? (It is numeric. It is an integer. It is n= on-negative. It is in the range 0 to 10FFFF. It is even. It is divisible by= 17. It is the same value as is found on the license plate of John Doe's ca= r.) I think it is the code point itself that is to be preferred. Also, "a f= urther encoding of the encoding form" isn't going to be clear to readers. (= I'm not sure myself what these words mean themselves; I can guess at what t= he author meant, though am not positive.) Thus, I'd change this text to: "However, when information about characters is to be processed by people, reference to the Unicode code point is preferable to encoded representations of the code point." Now, section 2 is talking about alternate representations of an encoded cha= racter, but the flow is a bit mixed up, IMO. The first paragraph says that = there are different equivalent representations but that the Unicode code po= int is preferred. Then the next paragraph revisits the same thing in more d= etail. The sentence from the first paragraph discussed above, once revised = so that it makes a clear statement, already says what paragraph two says in= greater detail. Whether a more succinct or more detailed statement is pref= erred, just say it once. Of course, if the more detailed paragraph two is kept, "code point position= in the table" should be changed to "code point". Also from paragraph two: "the UTF-8 encoding or some other short-form encoding" The term "short-form encoding" isn't explained here and may not be understo= od. I can only guess what is meant. If the intended meaning is what I think= (a reference to shortest-form versus non-shortest-form UTF-8), then I don'= t think it's really relevant. Either way, I'd change the wording to: "the UTF-8 encoding or some other encoding form" (Encoding form is a term defined in the Unicode Standard.) Also: "the other encodes the octets of" I don't think octets are encoded; they are simply referenced using some not= ational system. Thus, change to: "the other uses the octets of ... in some representation." (This gives parallel wording for the two kinds of reference.) Finally: "the Unicode code point forms" Drop "forms": "the Unicode code points" Peter Constable _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:47:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT1F-00033P-W1; Fri, 26 Oct 2007 13:30:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkHda-0001uY-7R for ietf@ietf.org; Tue, 23 Oct 2007 07:09:30 -0400 Received: from smtprelay10.ispgateway.de ([80.67.29.24]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkHdV-0001Yh-HI for ietf@ietf.org; Tue, 23 Oct 2007 07:09:25 -0400 Received: (qmail 26037 invoked from network); 23 Oct 2007 11:09:23 -0000 Received: from unknown (HELO ganesha.berlin.artnology.com) (400529@[195.143.217.178]) (envelope-sender ) by smtprelay10.ispgateway.de (qmail-ldap-1.03) with SMTP; 23 Oct 2007 11:09:23 -0000 From: "Diez B. Roggisch" To: ietf@ietf.org Date: Tue, 23 Oct 2007 13:09:23 +0200 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200710231309.23343.diez.roggisch@artnology.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:30:17 -0400 Cc: campaigns@fsf.org Subject: comment opposing TLS-authz "experimental" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hello, as a developer of FOSS and commercial software, I'd like to voice my opinio= n=20 against the passing of the TLS-authz-standard as informational.=20 It's important for us, the devolopers, as well as our customers or users th= at=20 the nuts and bolts of our application - internet standards - are kept open= =20 and free to access. Introduction of license-dependend technology there woul= d=20 introduce incalculable costs for even the tiniest of developments, stifflin= g=20 competition as well as innovation. So I sincerely hope that you will refrain from adding these informational=20 amendments to the standard. Regards, =2D-=20 >> Diez B. Roggisch >> Developer A Milastra=C3=9Fe 4 / D-10437 Berlin T +49 (30) 443 50 99 - 27 =46 +49 (30) 443 50 99 - 99 M +49 (179) 11 75 303 E diez.roggisch@artnology.com ____________________________________________________________________ Geschaeftsfuehrer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id. DE 217652550 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:47:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT1A-0002yz-Mp; Fri, 26 Oct 2007 13:30:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik0bU-0007Go-G6 for ietf@ietf.org; Mon, 22 Oct 2007 12:58:12 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ik0Zy-0005Ls-Ec for ietf@ietf.org; Mon, 22 Oct 2007 12:58:12 -0400 Received: from [192.168.1.28] (unknown [12.110.81.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 7ADB023E4A0; Mon, 22 Oct 2007 12:56:17 -0400 (EDT) Message-ID: <471CD62D.8090408@bouncingdog.com> Date: Mon, 22 Oct 2007 09:56:13 -0700 From: Chris MacGregor User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ietf@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:30:19 -0400 Subject: please REJECT tls-authz until it is patent-free! X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hello, As a software engineering professional, I have experienced first-hand the harm done by patents on software. I ask that you please REJECT any proposed standard (including those vying merely for "experimental" or "informational" status) which is encumbered by patents. (If the patent is made available for free use by anyone, with no restrictions, registration, payment, or further licensing, then that is fine - it is effectively the same, for this purpose, as if the technique was not patented.) There is no benefit to consumers, users, corporations, the software industry or art, or in fact anyone except the patent holder, when a standard is made to include patented techniques which must be licensed. It is the responsibility of a respected standards organization to resist pressure from those who seek to subvert the standardization processes for their own financial gain at the expense of EVERYONE else. Therefore, please DO NOT allow the patent-encumbered TLS-authz extension to become even an experimental or informational standard - please REJECT it outright, unless and until it is made completely free (in all senses). Thank you, Chris MacGregor Senior Software Engineer chris@bouncingdog.com _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf preferable to a further encoding of the encoded form of the character." Information about the code point? (It is numeric. It is an integer. It is n= on-negative. It is in the range 0 to 10FFFF. It is even. It is divisible by= 17. It is the same value as is found on the license plate of John Doe's ca= r.) I think it is the code point itself that is to be preferred. Also, "a f= urther encoding of the encoding form" isn't going to be clear to readers. (= I'm not sure myself what these words mean themselves; I can guess at what t= he author meant, though am not positive.) Thus, I'd change this text to: "However, when information about characters is to be processed by people, reference to the Unicode code point is preferable to encoded representations of the code point." Now, section 2 is talking about alternate representations of an encoded cha= racter, but the flow is a bit mixed up, IMO. The first paragraph says that = there are different equivalent representations but that the Unicode code po= int is preferred. Then the next paragraph revisits the same thing in more d= etail. The sentence from the first paragraph discussed above, once revised = so that it makes a clear statement, already says what paragraph two says in= greater detail. Whether a more succinct or more detailed statement is pref= erred, just say it once. Of course, if the more detailed paragraph two is kept, "code point position= in the table" should be changed to "code point". Also from paragraph two: "the UTF-8 encoding or some other short-form encoding" The term "short-form encoding" isn't explained here and may not be understo= od. I can only guess what is meant. If the intended meaning is what I think= (a reference to shortest-form versus non-shortest-form UTF-8), then I don'= t think it's really relevant. Either way, I'd change the wording to: "the UTF-8 encoding or some other encoding form" (Encoding form is a term defined in the Unicode Standard.) Also: "the other encodes the octets of" I don't think octets are encoded; they are simply referenced using some not= ational system. Thus, change to: "the other uses the octets of ... in some representation." (This gives parallel wording for the two kinds of reference.) Finally: "the Unicode code point forms" Drop "forms": "the Unicode code points" Peter Constable _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:47:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT1F-00033P-W1; Fri, 26 Oct 2007 13:30:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkHda-0001uY-7R for ietf@ietf.org; Tue, 23 Oct 2007 07:09:30 -0400 Received: from smtprelay10.ispgateway.de ([80.67.29.24]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkHdV-0001Yh-HI for ietf@ietf.org; Tue, 23 Oct 2007 07:09:25 -0400 Received: (qmail 26037 invoked from network); 23 Oct 2007 11:09:23 -0000 Received: from unknown (HELO ganesha.berlin.artnology.com) (400529@[195.143.217.178]) (envelope-sender ) by smtprelay10.ispgateway.de (qmail-ldap-1.03) with SMTP; 23 Oct 2007 11:09:23 -0000 From: "Diez B. Roggisch" To: ietf@ietf.org Date: Tue, 23 Oct 2007 13:09:23 +0200 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200710231309.23343.diez.roggisch@artnology.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:30:17 -0400 Cc: campaigns@fsf.org Subject: comment opposing TLS-authz "experimental" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hello, as a developer of FOSS and commercial software, I'd like to voice my opinio= n=20 against the passing of the TLS-authz-standard as informational.=20 It's important for us, the devolopers, as well as our customers or users th= at=20 the nuts and bolts of our application - internet standards - are kept open= =20 and free to access. Introduction of license-dependend technology there woul= d=20 introduce incalculable costs for even the tiniest of developments, stifflin= g=20 competition as well as innovation. So I sincerely hope that you will refrain from adding these informational=20 amendments to the standard. Regards, =2D-=20 >> Diez B. Roggisch >> Developer A Milastra=C3=9Fe 4 / D-10437 Berlin T +49 (30) 443 50 99 - 27 =46 +49 (30) 443 50 99 - 99 M +49 (179) 11 75 303 E diez.roggisch@artnology.com ____________________________________________________________________ Geschaeftsfuehrer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id. DE 217652550 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:47:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT1A-0002yz-Mp; Fri, 26 Oct 2007 13:30:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik0bU-0007Go-G6 for ietf@ietf.org; Mon, 22 Oct 2007 12:58:12 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ik0Zy-0005Ls-Ec for ietf@ietf.org; Mon, 22 Oct 2007 12:58:12 -0400 Received: from [192.168.1.28] (unknown [12.110.81.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 7ADB023E4A0; Mon, 22 Oct 2007 12:56:17 -0400 (EDT) Message-ID: <471CD62D.8090408@bouncingdog.com> Date: Mon, 22 Oct 2007 09:56:13 -0700 From: Chris MacGregor User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ietf@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:30:19 -0400 Subject: please REJECT tls-authz until it is patent-free! X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hello, As a software engineering professional, I have experienced first-hand the harm done by patents on software. I ask that you please REJECT any proposed standard (including those vying merely for "experimental" or "informational" status) which is encumbered by patents. (If the patent is made available for free use by anyone, with no restrictions, registration, payment, or further licensing, then that is fine - it is effectively the same, for this purpose, as if the technique was not patented.) There is no benefit to consumers, users, corporations, the software industry or art, or in fact anyone except the patent holder, when a standard is made to include patented techniques which must be licensed. It is the responsibility of a respected standards organization to resist pressure from those who seek to subvert the standardization processes for their own financial gain at the expense of EVERYONE else. Therefore, please DO NOT allow the patent-encumbered TLS-authz extension to become even an experimental or informational standard - please REJECT it outright, unless and until it is made completely free (in all senses). Thank you, Chris MacGregor Senior Software Engineer chris@bouncingdog.com _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:47:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT7w-00076C-Vf; Fri, 26 Oct 2007 13:37:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkHUV-0006Sm-4R for ietf@ietf.org; Tue, 23 Oct 2007 07:00:07 -0400 Received: from c.mx.oeko.net ([193.221.127.139] helo=w8.oeko.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkHUU-0001Dp-JI for ietf@ietf.org; Tue, 23 Oct 2007 07:00:07 -0400 Received: (qmail 25667 invoked from network); 23 Oct 2007 11:00:05 -0000 Received: from foo.oeko.net (HELO oak.oeko.net) ([193.221.127.48]) (envelope-sender ) by w8.oeko.net (qmail-ldap-1.03) with AES256-SHA encrypted compressed SMTP for ; 23 Oct 2007 11:00:05 -0000 Received: (qmail 2328 invoked by uid 2500); 23 Oct 2007 11:00:05 -0000 Message-ID: <20071023110005.2327.qmail@oak.oeko.net> Date: Tue, 23 Oct 2007 13:00:05 +0200 From: Toni Mueller To: ietf@ietf.org References: <20071023104346.2038.qmail@oak.oeko.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071023104346.2038.qmail@oak.oeko.net> X-Info: Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-Mailman-Approved-At: Fri, 26 Oct 2007 13:37:22 -0400 Cc: support@oeko.net Subject: Re: Please reject draft-housley-tls-authz-extns (supplementary note) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hello, I've just read the claim of of RedPhone Security as laid out here: https://datatracker.ietf.org/ipr/833/ There, they say that they will grant general, royalty-free licenses to their part, but they also say that they'll "retain" rights for certain classes of authorization and access control. This, effectively, means that they will not grant a license to the whole of the functionality where they laid a patent claim on, but only on parts of it. So, the interoperability issue, depicted in my earlier email, is still valid. As to the side node, I'm very much aware of the fact that such a policy can't be enforced without supporting legislation in jurisdictions around the world. So that leaves us with the position to generally reject patented material. But at least something should be done (if it's not done already) to avoid someone sneaking patented stuff into standards, and someone (someone else? daughter company? investor who purchases the remains?) tries to rip everyone off and thus break the standard, as in the JPEG case. Kind Regards, Toni Mueller. -------- AS29394 TM28-RIPE Oeko.neT Mueller & Brandt GbR sales: info@oeko.net v: +49 2261 979364 f: +49 2261 979366 http://www.oeko.net consulting, systems administration, software development, Python, Perl, networking, Unix, Debian Linux, OpenBSD, Internet services, trainings GPG: 1024D/68BDA342; FP=3312 D609 AD2E 8C05 D494 139E 8419 E0DB 68BD A342 A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? $ echo "creationism" | tr -d "holy godly goal" _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:47:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTAD-0000ib-Am; Fri, 26 Oct 2007 13:40:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkruK-0006e9-To for ietf@ietf.org; Wed, 24 Oct 2007 21:53:12 -0400 Received: from el-out-1112.google.com ([209.85.162.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikru7-0003fF-OH for ietf@ietf.org; Wed, 24 Oct 2007 21:53:04 -0400 Received: by el-out-1112.google.com with SMTP id s27so192644ele for ; Wed, 24 Oct 2007 18:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; bh=x41qQmtFEuYL1UkBnu45Bli0iG3rm+FYEY18hE22SPI=; b=CBKnCpfovcPnind5806xDUquF+VWHr5N16O6MnSHbiHHzZx2djxTHEe+Kgnz3+Cew4VCVehovjlAb6E6Zmpie1XEhKif1KwfV7LzODXF4fCPIqyGjufYJTXiouc410axZVsAjWt/h4jN5WQji//CUOIc5g+AtL2FYFGvCzXn5GU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=KS0IYunfJixBOSNmCeRBpBrL4q1Wxl/7Cq/vZBFj/cNmlD10pDrOLMDdHlp6ylZJ7kJ+c3Hg6F0T6/RVfqQyhmTkY5NOf1kk/fWvYNqRpbTbfksjLZfLvSh5J1NW8y8ZH/NgNuJf/TktudUQxWTX33ad/77qWq9xYeS9aidussI= Received: by 10.142.128.6 with SMTP id a6mr376384wfd.1193277140082; Wed, 24 Oct 2007 18:52:20 -0700 (PDT) Received: by 10.142.47.9 with HTTP; Wed, 24 Oct 2007 18:52:20 -0700 (PDT) Message-ID: <2e117fdb0710241852p5baeabfdx54c66514ef467a9d@mail.gmail.com> Date: Wed, 24 Oct 2007 21:52:20 -0400 From: "Bryan Quigley" To: ietf@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Fri, 26 Oct 2007 13:39:35 -0400 Cc: campaigns@fsf.org Subject: TLS Authorization X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0458399045==" Errors-To: ietf-bounces@ietf.org --===============0458399045== Content-Type: multipart/alternative; boundary="----=_Part_8276_19902440.1193277140119" ------=_Part_8276_19902440.1193277140119 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear IETF, I would like to echo the comments of the FSF in regards to patents in standards. I believe MPEG is a good example of standards and patents working horribly together. Please do not make that same mistake with TLS Authorization. Thank You, Bryan Quigley -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html ------=_Part_8276_19902440.1193277140119 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear IETF,
I would like to echo the comments of the FSF in regards to patents in standards.  I believe MPEG is a good example of standards and patents working horribly together.
Please do not make that same mistake with TLS Authorization.
Thank You,
Bryan Quigley

--
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html ------=_Part_8276_19902440.1193277140119-- --===============0458399045== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0458399045==-- From ietf-bounces@ietf.org Fri Oct 26 13:47:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTA4-0000Hz-Sn; Fri, 26 Oct 2007 13:39:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IigRJ-0005Vh-So for ietf@ietf.org; Thu, 18 Oct 2007 21:14:13 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IigQe-0000fI-Be for ietf@ietf.org; Thu, 18 Oct 2007 21:14:13 -0400 Received: by py-out-1112.google.com with SMTP id d32so1243440pye for ; Thu, 18 Oct 2007 18:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; bh=XeTYfMYxb8g90/2FfXYKOHdvAiTcEuXuqssISteRwv8=; b=m2MKX9ASCt01TLq10V8ZbHdmjDvwfDiws842sZGwvXCbpWYOfaRZEzVGFwwnGVP3qwZtcu6Kz6Gh3BjnjrRneZ6cc8WSoZYNU+6NrlLkyRcs0fd+K2plyjcgvGl25cCE5F8X/ZzMEVWs/VX11GZr2g3XNXdMVf9qM/DVBzjVsdU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=c/sJ9TCK1Mn1QVr+XCdoWjGJIJxjG6VPnZ58vRj+YckHe2CGuYBEEtqGOSa1ofgSPXcnd9njTRdeVhZSTg7lBwaQ+kDzk+RiLDyA9BJ+28V+HDbudVdovVq7p/8Ux+zuYJuU1rjwnvklgoiH85JbFLUeuCgJgjgXrmpvtpgKjSc= Received: by 10.65.96.6 with SMTP id y6mr2310909qbl.1192756379816; Thu, 18 Oct 2007 18:12:59 -0700 (PDT) Received: by 10.65.95.8 with HTTP; Thu, 18 Oct 2007 18:12:59 -0700 (PDT) Message-ID: Date: Thu, 18 Oct 2007 21:12:59 -0400 From: "Jeffrey Hankins" To: ietf@ietf.org MIME-Version: 1.0 X-Spam-Score: 2.2 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:39:34 -0400 Cc: Andreas Hizkiah Conant , campaigns@fsf.org Subject: No bad TLS authorization standards X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0921260049==" Errors-To: ietf-bounces@ietf.org --===============0921260049== Content-Type: multipart/alternative; boundary="----=_Part_4250_19516341.1192756379817" ------=_Part_4250_19516341.1192756379817 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Sir or Madam: Please do not harm free software interests by supporting the "experimental" TLS standard. Thank you for your time and consideration. -Jeff Hankins ------=_Part_4250_19516341.1192756379817 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Sir or Madam:

Please do not harm free software interests by supporting the "experimental" TLS standard. Thank you for your time and consideration.

-Jeff Hankins
------=_Part_4250_19516341.1192756379817-- --===============0921260049== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0921260049==-- From ietf-bounces@ietf.org Fri Oct 26 13:47:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTAB-0000Yi-Da; Fri, 26 Oct 2007 13:40:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkRNv-0003P8-OH for ietf@ietf.org; Tue, 23 Oct 2007 17:33:59 -0400 Received: from grace.univie.ac.at ([2001:62a:4:25::25:115]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkRNg-0006du-Jq for ietf@ietf.org; Tue, 23 Oct 2007 17:33:55 -0400 Received: from joan.univie.ac.at ([131.130.3.110] helo=joan.univie.ac.at) by grace.univie.ac.at with esmtp (Exim 4.68) (envelope-from ) id 1IkRNa-00015O-VA; Tue, 23 Oct 2007 23:33:38 +0200 Received: from chello213047161152.15.14.univie.teleweb.at ([213.47.161.152] helo=[192.168.1.10]) by joan.univie.ac.at with esmtp (Exim 4.68) (envelope-from ) id 1IkRNa-0004p8-TP; Tue, 23 Oct 2007 23:33:38 +0200 Message-ID: <471E68AD.9030807@vcpc.univie.ac.at> Date: Tue, 23 Oct 2007 23:33:33 +0200 From: Willy Weisz User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: ietf@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:39:36 -0400 Cc: campaigns@fsf.org Subject: TLS Authorisation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org To whom it may concern. Having been informed that the proposed IETF document "TLS Authorisation" contains proprietary technique for which a patent has been filed, I strongly oppose its registration as IETF document even as an "experimental" or "informational" one. Such a document, even without being an official standard, would encourage the use of a technique which would entail the need to pay license fees to the patent holder. Sincerely yours Willy Weisz ----------------------------------------------------------- Willy Weisz European Centre for Parallel Computing at Vienna (VCPC) Institute of Scientific Computing University of Vienna Nordbergstrasse 15/C312 A-1090 Wien Tel: (+43 1) 4277 - 39424 Fax: (+43 1) 4277 - 9394 e-mail: weisz@vcpc.univie.ac.at _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:47:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT19-0002vz-IE; Fri, 26 Oct 2007 13:30:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjxzT-00063R-If for ietf@ietf.org; Mon, 22 Oct 2007 10:10:48 -0400 Received: from smtp106.biz.mail.re2.yahoo.com ([206.190.52.175]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IjxzQ-0003Hw-7W for ietf@ietf.org; Mon, 22 Oct 2007 10:10:44 -0400 Received: (qmail 31936 invoked from network); 22 Oct 2007 14:10:44 -0000 Received: from unknown (HELO ?192.168.1.64?) (contactme@koinoniahouse.biz@86.142.251.179 with plain) by smtp106.biz.mail.re2.yahoo.com with SMTP; 22 Oct 2007 14:10:43 -0000 X-YMail-OSG: QlmvZlEVM1mM4Yo5Y0eGp3.E3awYW2woctmH3axu4BNBLvtM4a68wo1wdpILc8JBQL1kRbc07oRLOFg2IOWfEC7y01e2JgVHn8XyKMdfCfRB1OLFTpSs9A-- From: Jo To: ietf@ietf.org Content-Type: text/plain Date: Mon, 22 Oct 2007 15:10:34 +0100 Message-Id: <1193062234.7263.36.camel@gnu-linux> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.2 (++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-Mailman-Approved-At: Fri, 26 Oct 2007 13:30:18 -0400 Subject: We oppose TLS-authz. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jo@koinoniahouse.biz List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Dear Sir/Madam. "Much of the communication on the Internet happens between computers according to standards that define common languages. If we are going to live in a free world using free software, our software must be allowed to speak these languages". "Unfortunately, discussions about possible new standards are tempting opportunities for people who would prefer to profit by extending proprietary control over our communities. If someone holds a software patent on a technique that a programmer has to use in order to implement a standard, then no one is free to implement that standard without getting permission from and paying the patent holder. If we are not careful, standards can become major barriers to computer users having and exercising their freedom". "We depend on organisations like the Internet Engineering Task Force (IETF) and the Internet Engineering Steering Group (IESG) to evaluate new proposals for standards and make sure that they are not encumbered by patents or any other sort of restriction that would prevent free software users and programmers from participating in the world they define". We and the "Free Software Foundation and the GNU Project" oppose publication of draft-housley-tls-authz-extns as an experimental standard. You can see by the above "Quotes" that every poor and jobless person who are very blessed by being allowed to use Gnu/Linux & Free Software, and the ability to interact with other people all over the earth, and yet there are "People/Company's" that want to take that God Given Right and abuse the freedom for a Human being to be able to express His or Her thoughts/feelings/laughter/dreams to other people who share a common goal. Will you please help us to stop this, "TLS-authz an experimental standard" Sincerely Mrs Jo & Brian Hadley. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:47:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTA3-0000Cz-2G; Fri, 26 Oct 2007 13:39:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iifhy-0001Du-TI for ietf@ietf.org; Thu, 18 Oct 2007 20:27:22 -0400 Received: from rv-out-0910.google.com ([209.85.198.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IifhL-0007lt-Fy for ietf@ietf.org; Thu, 18 Oct 2007 20:27:14 -0400 Received: by rv-out-0910.google.com with SMTP id l15so266685rvb for ; Thu, 18 Oct 2007 17:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=j3oRU20/xLNhMSux+QaGvX2obBFGf3yYivhy6kOgQEE=; b=SiWG+JwmW7m50OkRbmjnBPjp52lNSbjGutCjYIujJryfmUd3WPFYRX9whQDfI4fgkCzCAKmkAFeXSR8zRVOnxweLmeUixxmB+C3gYOz5mRpkfUgNo1XBcj3pVE+Kz09k/+HpZ1+szhsLnyR5t4zpP3kuX6SXxzP/FVeeByZLlBI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=RD0LLsWzggTDgrPkLiuDeHAJUxWY8kLsBjhFUmlPAgEsLpcNtzfpb2TbPgHRrjYrIiG0RT9gEIN6blQMZBh6WR7mTsUkyvxx/Gst6MSWE3+LXy/LUl1iSI705RFO04OrfUwYHz0bzMQol0UQsF7Hj0eRAHUtudwh9uEEZw5cW9Y= Received: by 10.141.203.7 with SMTP id f7mr664999rvq.1192753580538; Thu, 18 Oct 2007 17:26:20 -0700 (PDT) Received: by 10.141.75.15 with HTTP; Thu, 18 Oct 2007 17:26:20 -0700 (PDT) Message-ID: <3922422b0710181726m5549108tf4f1b1c52259ed90@mail.gmail.com> Date: Thu, 18 Oct 2007 20:26:20 -0400 From: "Ringo Kamens" <2600denver@gmail.com> To: ietf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:39:35 -0400 Subject: TLS Authorization X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Please do not allow TLS-authorization to become a standard or even an experimental one. Standards need to be open, and it isn't. Alex Bryan Centennial, Colorado 80015 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:47:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT1H-000355-3Z; Fri, 26 Oct 2007 13:30:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJzg-0003Tf-Eo for ietf@ietf.org; Tue, 23 Oct 2007 09:40:28 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IkJzZ-0007cH-TM for ietf@ietf.org; Tue, 23 Oct 2007 09:40:22 -0400 Received: (qmail 22420 invoked by uid 0); 23 Oct 2007 13:40:17 -0000 Received: from 213.86.111.10 by www176.gmx.net with HTTP; Tue, 23 Oct 2007 15:40:17 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Oct 2007 15:40:17 +0200 From: "Darko Ivancan" Message-ID: <20071023134017.46540@gmx.net> MIME-Version: 1.0 To: ietf@ietf.org X-Authenticated: #1386885 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 1 X-Provags-ID: V01U2FsdGVkX1/cHSZiVHncZcf70zd0jT/TNgDwEAFy0ZMzrP2CBb k+kTYLdomkSzaiIZsofEXc+B+gA17oppNqsg== Content-Transfer-Encoding: 7bit X-GMX-UID: rox0dGNceWUkJ/dPfG9nnigjL0tsZk0Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Fri, 26 Oct 2007 13:30:20 -0400 Cc: campaigns@fsf.org Subject: Opposing making TLS-authz an experimental standard X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I oppose publication of draft-housley-tls-authz-extns as an experimental standard. The patent application disclosed by RedPhone Security has put any free software attempting to implement these extensions in a very difficult position. Free software developers cannot safely code to the specifications without risking infringement on RedPhone's patents. As a result of these concerns and the uncertain situation they create, GnuTLS has removed support for them in its latest release -- and no other software maintained by the GNU Project will be written to them. We know that the IETF and IESG largely share our view that patent-encumbered standards are unacceptable. We believe that the process has reached the proper conclusion -- the draft has been rejected as a standard. Please do not allow this decision to be negated by publishing it on the experimental track. We agree with Sam Hartman that "often it seems that we use informational as a way to publish things we cannot build a strong consensus behind. I think that process is generally problematic and would like to avoid it in this instance," and with Simon Josefsson that "[g]iven that the initial last call was to put the document on the standards track, my impression would be that this last call request for the experimental track is indeed intended to circumvent the normal process." In the long term, widespread adoption of something published on this track would put software authors in the same bad position as if the document were approved as a standard. Please respect the consensus that has been reached and do not publish this draft. Thanks, Darko Ivancan -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:47:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT7x-00076I-HO; Fri, 26 Oct 2007 13:37:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkPnL-0005u7-NU for ietf@ietf.org; Tue, 23 Oct 2007 15:52:07 -0400 Received: from smtprelay03.ispgateway.de ([80.67.18.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkPnG-0007DI-Uh for ietf@ietf.org; Tue, 23 Oct 2007 15:52:03 -0400 Received: (qmail 4844 invoked from network); 23 Oct 2007 19:52:00 -0000 Received: from unknown (HELO [77.128.74.193]) (544451@[77.128.74.193]) (envelope-sender ) by smtprelay03.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP; 23 Oct 2007 19:52:00 -0000 Message-ID: <471E50DF.4030604@v.loewis.de> Date: Tue, 23 Oct 2007 21:51:59 +0200 From: =?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: IceDove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: ietf@ietf.org X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:37:23 -0400 Cc: campaigns@fsf.org Subject: Comment on draft-housley-tls-authz-extns-07.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Please consider rejecting the draft mentioned above, even as an experimental protocol, for the IPR (patent) reasons that got recently disclosed. I believe that the objective of this memo is valuable, and to have such a mechanism available in TLS would be useful for the community. At the same time, the patent claim on the specific solution to the stated problem would exclude free software from exercising the proposed protocol. Instead, the community should seek solutions to the problem that don't require exercising the patent. If such a solution is found at some point, it would compete to the then-established experimental protocol; users would need to make a difficult choice of using the older, proprietary protocol or the newer, open protocol. Because of this possible scenario, accepting the memo now as experimental may cause confusion and non-interoperability in the future. Thank you for your consideration, Martin v. Löwis _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:47:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT16-0002q4-Iz; Fri, 26 Oct 2007 13:30:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iim1z-000363-4i for ietf@ietf.org; Fri, 19 Oct 2007 03:12:27 -0400 Received: from in1.fundp.ac.be ([138.48.4.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iim1q-0001Ts-SE for ietf@ietf.org; Fri, 19 Oct 2007 03:12:25 -0400 Received: from kyara.siu.fundp.ac.be (kyara.siu.fundp.ac.be [138.48.48.51]) (authenticated bits=0) by in1.fundp.ac.be (8.13.1/8.13.1) with ESMTP id l9J7Bio3029038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2007 09:11:51 +0200 Message-ID: <471858B0.3090605@fundp.ac.be> Date: Fri, 19 Oct 2007 09:11:44 +0200 From: Bruno Delcourt User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: ietf@ietf.org, campaigns@fsf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-FUNDP-MailScanner-Information: Please contact the ISP for more information X-FUNDP-MailScanner: Found to be clean X-FUNDP-MailScanner-From: bruno.delcourt@fundp.ac.be X-Spam-Status: No Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by in1.fundp.ac.be id l9J7Bio3029038 X-Spam-Score: 2.2 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-Mailman-Approved-At: Fri, 26 Oct 2007 13:30:20 -0400 Cc: Subject: opposing TLS-authz "experimental" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Dear Sir, As a network administrator of the University computing services at th= e FUNDP University (Namur, Belgium), and as an individual, I oppose the publication of draft-housley-tls-authz-extns as an experimental standard. The patent application disclosed by RedPhone Security has put any free software attempting to implement these extensions in a very difficult position. Free software developers cannot safely code to the specifications without risking infringement on RedPhone's patents. For example, as a result of these concerns and the uncertain situation they create, GnuTLS has removed support for them in its latest release -- and no other software maintained by the GNU Project will be written to them. I understand that the IETF and IESG largely share my view that patent-encumbered standards are unacceptable. I believe that the process has reached the proper conclusion -- the draft has been rejected as a standard. Please do not allow this decision to be negated by publishing it on the experimental track. I agree with Sam Hartman that "often it seems that we use informational as a way to publish things we cannot build a strong consensus behind. I think that process is generally problematic and would like to avoid it in this instance," and with Simon Josefsson that "[g]iven that the initial last call was to put the document on the standards track, my impression would be that this last call request for the experimental track is indeed intended to circumvent the normal process." In the long term, widespread adoption of something published on this track would put software authors in the same bad position as if the document were approved as a standard. Please respect the consensus that has been reached and do not publish this draft. Yours truly, -- *Bruno Delcourt* 36, Rue Ren=E9 Rubay B-5032 Isnes - Belgique T=E9l. +32 (81) 56 92 37 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:47:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT1E-00032m-Vn; Fri, 26 Oct 2007 13:30:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkHbF-0006Me-VY for ietf@ietf.org; Tue, 23 Oct 2007 07:07:06 -0400 Received: from mailfe02.tele2.ch ([212.247.154.40] helo=swip.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkHb6-0001qK-I9 for ietf@ietf.org; Tue, 23 Oct 2007 07:07:01 -0400 X-Cloudmark-Score: 0.000000 [] Received: from aae63.unibe.ch (account cxu-8cd-hm6@tele2.ch [130.92.79.63] verified) by mailfe02.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 663904447; Tue, 23 Oct 2007 13:06:36 +0200 Message-ID: <471DD5B5.1090002@weitling.net> Date: Tue, 23 Oct 2007 13:06:29 +0200 From: Dev at weitling User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: ietf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Fri, 26 Oct 2007 13:30:23 -0400 Cc: campaigns@fsf.org Subject: Opposing making TLS-authz an experimental standard X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Dear IETF, besides patent nonsense driven by third parties there's more to oppose to. The currently at IETF discussed TLS-authz is a candidate because RedPhone Security hinders reaching the basic goal of the IETF: Creating standards for common languages. While standardizing a technique like TSL-authz might look desirable, spreading this technique and taking money from all people who used it in past and today is not. In fact it is the opposite of IETF's goal. Please don't betray your ideals! Stop making TLS-authz even an experimental standard. Yours sincerely, Florian Weitling _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:47:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT7p-00073i-Cm; Fri, 26 Oct 2007 13:37:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiuvx-0001Bv-6u for ietf@ietf.org; Fri, 19 Oct 2007 12:42:49 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iiuvp-0007Ki-QL for ietf@ietf.org; Fri, 19 Oct 2007 12:42:49 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 17:42:25 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 17:42:25 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1192812144863; Fri, 19 Oct 2007 17:42:24 +0100 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l9JGfsQW020095; Fri, 19 Oct 2007 17:42:07 +0100 Message-Id: <5.2.1.1.2.20071019165431.018d18c8@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 19 Oct 2007 17:41:46 +0100 To: Tom Yu From: Bob Briscoe In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 19 Oct 2007 16:42:25.0798 (UTC) FILETIME=[0795B260:01C8126F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:37:20 -0400 Cc: secdir@MIT.EDU, ietf@ietf.org, bsd@cisco.com, tsvwg-chairs@tools.ietf.org Subject: Re: secdir review of draft-ietf-tsvwg-ecn-mpls-02.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Tom, You're analysis of the impact on the ECN nonce is accurate. Below is our reasoning for not including the ECN nonce capability in this proposal... An ECN nonce capability could be provided within the MPLS EXP field by using one more of the 8 available codepoints for each DSCP requiring the facility. This could be defined in a future RFC, because neither our ECN proposal nor the use of the EXP field for Diffserv preclude other uses of the EXP codepoints. Of course, an operator who uses Diffserv & ECN will tend to have to preclude other uses like this by consuming all 8 codepoints, but they do have the option of using Labels for Diffserv (LLSP), which leaves more space in the EXP field for ECN & ECN nonces. However, we decided not to bundle the ECN nonce into this proposal, as it would have required extra standards text with little chance of it being used - the RFC3540 ECN nonce has been experimental status since Jun 2003 and there have been no implementations. But we haven't precluded an MPLS ECN nonce being added later. In particular, it would be very unlikely that an operator would use up one more of its scarce MPLS EXP codepoints to validate that its own LSRs weren't removing markings added by other LSRs in the same MPLS tunnel (whether maliciously or accidentally). The case for the ECN nonce is much stronger as a protection against misbehaving receivers than network nodes - particularly given MPLS protection would typically only protect one domain from itself. But even then, the ECN nonce only enables a *data sender* to establish whether congestion notifications have been removed. If a network operator wanted to use the ECN nonce as proposed to detect removal of congestion notifications, it would have to trust data senders to act on its behalf. Counter to what I've just said about only the sender being able to use the nonce, Sally Floyd suggested on the tsvwg list (can't find it at the mo) that a tunnel egress could use an ECN nonce-like capability to check if the nonce in the outer was different to that in the inner, which would imply a congestion marking had been removed. This would certainly work, but only if the tunnel ingress encrypted the inner nonce - otherwise whoever removed an outer notification could just reset the outer header back to what it used to be by reading the inner header. Having started to invent more complicated possible uses of something that already wasn't used, we decided not to spend too much more time on this, given we weren't precluding someone doing all this later. Bob At 03:44 19/10/2007, Tom Yu wrote: >This is a review of draft-ietf-tsvwg-ecn-mpls-02.txt. > >I have reviewed this document as part of the security directorate's >ongoing effort to review all IETF documents being processed by the >IESG. These comments were written primarily for the benefit of the >security area directors. Document editors and WG chairs should treat >these comments just like any other last call comments. > >I am not very familiar with MPLS or Diffserv, but I did read some of >the cited MPLS and ECN references in order to understand this >document. > >I mostly agree with the claim in the Security Considerations that this >proposal introduces no additional vulnerabilities. However, although >this document indicates that using a RFC3540 ECN nonce to detect >misbehaving receivers continues to work under this proposal, a RFC3540 >nonce can also be used to detect disruption of the end-to-end >continuity of ECN signaling. This proposal can compromise the >detection of disruptions of end-to-end ECN signaling continuity which >occur within a given MPLS domain. I lack the context to determine >whether this is a serious problem. > >The procedure described in RFC3540 relies on the existence of two >distinct ECT indications to convey a single bit's worth of nonce data >to the receiving transport endpoint. This proposal functionally uses >only a single bit to indicate a CM state. If a malicious or >malfunctioning element within the MPLS domain clears a CM state set by >some LSR, the egress LSR will not set the CE state in the >unencapsulated IP packet. Consequently, the receiving transport >endpoint acts as if the packet did not have a CE state marked at all, >and the sending transport endpoint receives no indication that a >problem exists with end-to-end ECN signaling. > >In effect, the MPLS domain behaves as a single black box router from >the perspective of RFC3540, masking any ECN signaling anomalies >internal to the MPLS domain. This may be an acceptable consequence of >this proposal, but it would be useful to know whether this consequence >has been considered. > >---Tom ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:47:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT7q-00073o-Dd; Fri, 26 Oct 2007 13:37:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il2QJ-0007GF-Sb for ietf@ietf.org; Thu, 25 Oct 2007 09:06:55 -0400 Received: from smtp3.wanadoo.co.uk ([193.252.22.156] helo=smtp3.freeserve.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il2QE-0006Bi-To for ietf@ietf.org; Thu, 25 Oct 2007 09:06:51 -0400 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3211.me.freeserve.com (SMTP Server) with ESMTP id E05A21C00088; Thu, 25 Oct 2007 15:06:49 +0200 (CEST) Received: from Codalogic (user-5447e8d0.wfd93.dsl.pol.co.uk [84.71.232.208]) by mwinf3211.me.freeserve.com (SMTP Server) with SMTP id 494271C00081; Thu, 25 Oct 2007 15:06:49 +0200 (CEST) X-ME-UUID: 20071025130649300.494271C00081@mwinf3211.me.freeserve.com Message-ID: <000a01c81707$f265b1e0$5d00a8c0@Codalogic> From: "Pete Cordell" To: "Even, Roni" , References: <144ED8561CE90C41A3E5908EDECE315C0501B822@IsrExch01.israel.polycom.com> Date: Thu, 25 Oct 2007 14:07:05 +0100 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:37:20 -0400 Cc: Cullen Jennings , oritl@microsoft.com, pierre@radvision.com, jo@acm.org, jf.mule@cablelabs.com, Colin Perkins Subject: Re: Last Call: draft-levin-mmusic-xml-media-control (XML Schema for Media Control) to Informational RFC X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi Roni, This looks fine to me. The only thing I would say is that I think the elementFormDefault="qualified" is redundant because there is no namespace to qualify the elements with. Pete. P.S. Sorry for the delay in responding to this. I have been away for a few days. -- ============================================= Pete Cordell Codalogic for XML Schema to C++ data binding visit http://www.codalogic.com/lmx/ ============================================= ----- Original Message ----- From: "Even, Roni" To: "Pete Cordell" ; Cc: ; ; "Colin Perkins" ; "Cullen Jennings" ; ; Sent: Thursday, October 25, 2007 1:29 PM Subject: RE: Last Call: draft-levin-mmusic-xml-media-control (XML Schema for Media Control) to Informational RFC Hi Pete, After consulting with my co-authors our view is that industry implemented the solution as specified in the example, so we need to revise the schema based on Pete's suggestion to This also means that we will not have the target name space so we do not need to register it with IANA as specified in section 9.2. If this is correct I will submit a revised revsion. Thanks Roni Even > -----Original Message----- > From: Pete Cordell [mailto:pete@codalogic.com] > Sent: Monday, October 08, 2007 4:22 PM > To: ietf@ietf.org > Cc: oritl@microsoft.com; Even, Roni; pierre@radvision.com > Subject: Re: Last Call: draft-levin-mmusic-xml-media-control (XML Schema > for Media Control) to Informational RFC > > I quickly looked at this and noticed that the XML instance examples don't > match the schema because the instance does not make reference to the > namespace. i.e., to match the schema, the example should be: > > > > > > > > > > > > My expectation is that the instance is actually more authorative in terms > of > what the authors are looking for. If that is the case, the schema should > be > modified along the lines of: > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"> > ... > > i.e. remove the targetNamespace declarations. > > You may have your reasons not to, but if not, you may want to consider > using > schema's documentation features instead of the XML comments; e.g.: > > > > Video control primitive. > > > > ... > > HTH, > > Pete. > -- > ============================================= > Pete Cordell > Codalogic > for XML Schema to C++ data binding visit > http://www.codalogic.com/lmx/ > ============================================= > ----- Original Message ----- > From: "The IESG" > To: "IETF-Announce" > Sent: Monday, October 08, 2007 2:29 PM > Subject: Last Call: draft-levin-mmusic-xml-media-control (XML Schema for > Media Control) to Informational RFC > > > > The IESG has received a request from an individual submitter to consider > > the following document: > > > > - 'XML Schema for Media Control ' > > as an Informational RFC > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2007-11-05. Exceptionally, > > comments may be sent to iesg@ietf.org instead. In either case, please > > retain the beginning of the Subject line to allow automated sorting. > > > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-levin-mmusic-xml-media- > control-11.txt > > > > > > IESG discussion can be tracked via > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=93 > 91&rfc_flag=0 > > > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf-announce > > > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:47:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT7p-00073i-Cm; Fri, 26 Oct 2007 13:37:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiuvx-0001Bv-6u for ietf@ietf.org; Fri, 19 Oct 2007 12:42:49 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iiuvp-0007Ki-QL for ietf@ietf.org; Fri, 19 Oct 2007 12:42:49 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 17:42:25 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 17:42:25 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1192812144863; Fri, 19 Oct 2007 17:42:24 +0100 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l9JGfsQW020095; Fri, 19 Oct 2007 17:42:07 +0100 Message-Id: <5.2.1.1.2.20071019165431.018d18c8@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 19 Oct 2007 17:41:46 +0100 To: Tom Yu From: Bob Briscoe In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 19 Oct 2007 16:42:25.0798 (UTC) FILETIME=[0795B260:01C8126F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:37:20 -0400 Cc: secdir@MIT.EDU, ietf@ietf.org, bsd@cisco.com, tsvwg-chairs@tools.ietf.org Subject: Re: secdir review of draft-ietf-tsvwg-ecn-mpls-02.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Tom, You're analysis of the impact on the ECN nonce is accurate. Below is our reasoning for not including the ECN nonce capability in this proposal... An ECN nonce capability could be provided within the MPLS EXP field by using one more of the 8 available codepoints for each DSCP requiring the facility. This could be defined in a future RFC, because neither our ECN proposal nor the use of the EXP field for Diffserv preclude other uses of the EXP codepoints. Of course, an operator who uses Diffserv & ECN will tend to have to preclude other uses like this by consuming all 8 codepoints, but they do have the option of using Labels for Diffserv (LLSP), which leaves more space in the EXP field for ECN & ECN nonces. However, we decided not to bundle the ECN nonce into this proposal, as it would have required extra standards text with little chance of it being used - the RFC3540 ECN nonce has been experimental status since Jun 2003 and there have been no implementations. But we haven't precluded an MPLS ECN nonce being added later. In particular, it would be very unlikely that an operator would use up one more of its scarce MPLS EXP codepoints to validate that its own LSRs weren't removing markings added by other LSRs in the same MPLS tunnel (whether maliciously or accidentally). The case for the ECN nonce is much stronger as a protection against misbehaving receivers than network nodes - particularly given MPLS protection would typically only protect one domain from itself. But even then, the ECN nonce only enables a *data sender* to establish whether congestion notifications have been removed. If a network operator wanted to use the ECN nonce as proposed to detect removal of congestion notifications, it would have to trust data senders to act on its behalf. Counter to what I've just said about only the sender being able to use the nonce, Sally Floyd suggested on the tsvwg list (can't find it at the mo) that a tunnel egress could use an ECN nonce-like capability to check if the nonce in the outer was different to that in the inner, which would imply a congestion marking had been removed. This would certainly work, but only if the tunnel ingress encrypted the inner nonce - otherwise whoever removed an outer notification could just reset the outer header back to what it used to be by reading the inner header. Having started to invent more complicated possible uses of something that already wasn't used, we decided not to spend too much more time on this, given we weren't precluding someone doing all this later. Bob At 03:44 19/10/2007, Tom Yu wrote: >This is a review of draft-ietf-tsvwg-ecn-mpls-02.txt. > >I have reviewed this document as part of the security directorate's >ongoing effort to review all IETF documents being processed by the >IESG. These comments were written primarily for the benefit of the >security area directors. Document editors and WG chairs should treat >these comments just like any other last call comments. > >I am not very familiar with MPLS or Diffserv, but I did read some of >the cited MPLS and ECN references in order to understand this >document. > >I mostly agree with the claim in the Security Considerations that this >proposal introduces no additional vulnerabilities. However, although >this document indicates that using a RFC3540 ECN nonce to detect >misbehaving receivers continues to work under this proposal, a RFC3540 >nonce can also be used to detect disruption of the end-to-end >continuity of ECN signaling. This proposal can compromise the >detection of disruptions of end-to-end ECN signaling continuity which >occur within a given MPLS domain. I lack the context to determine >whether this is a serious problem. > >The procedure described in RFC3540 relies on the existence of two >distinct ECT indications to convey a single bit's worth of nonce data >to the receiving transport endpoint. This proposal functionally uses >only a single bit to indicate a CM state. If a malicious or >malfunctioning element within the MPLS domain clears a CM state set by >some LSR, the egress LSR will not set the CE state in the >unencapsulated IP packet. Consequently, the receiving transport >endpoint acts as if the packet did not have a CE state marked at all, >and the sending transport endpoint receives no indication that a >problem exists with end-to-end ECN signaling. > >In effect, the MPLS domain behaves as a single black box router from >the perspective of RFC3540, masking any ECN signaling anomalies >internal to the MPLS domain. This may be an acceptable consequence of >this proposal, but it would be useful to know whether this consequence >has been considered. > >---Tom ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:47:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT7q-00073o-Dd; Fri, 26 Oct 2007 13:37:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il2QJ-0007GF-Sb for ietf@ietf.org; Thu, 25 Oct 2007 09:06:55 -0400 Received: from smtp3.wanadoo.co.uk ([193.252.22.156] helo=smtp3.freeserve.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il2QE-0006Bi-To for ietf@ietf.org; Thu, 25 Oct 2007 09:06:51 -0400 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3211.me.freeserve.com (SMTP Server) with ESMTP id E05A21C00088; Thu, 25 Oct 2007 15:06:49 +0200 (CEST) Received: from Codalogic (user-5447e8d0.wfd93.dsl.pol.co.uk [84.71.232.208]) by mwinf3211.me.freeserve.com (SMTP Server) with SMTP id 494271C00081; Thu, 25 Oct 2007 15:06:49 +0200 (CEST) X-ME-UUID: 20071025130649300.494271C00081@mwinf3211.me.freeserve.com Message-ID: <000a01c81707$f265b1e0$5d00a8c0@Codalogic> From: "Pete Cordell" To: "Even, Roni" , References: <144ED8561CE90C41A3E5908EDECE315C0501B822@IsrExch01.israel.polycom.com> Date: Thu, 25 Oct 2007 14:07:05 +0100 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:37:20 -0400 Cc: Cullen Jennings , oritl@microsoft.com, pierre@radvision.com, jo@acm.org, jf.mule@cablelabs.com, Colin Perkins Subject: Re: Last Call: draft-levin-mmusic-xml-media-control (XML Schema for Media Control) to Informational RFC X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi Roni, This looks fine to me. The only thing I would say is that I think the elementFormDefault="qualified" is redundant because there is no namespace to qualify the elements with. Pete. P.S. Sorry for the delay in responding to this. I have been away for a few days. -- ============================================= Pete Cordell Codalogic for XML Schema to C++ data binding visit http://www.codalogic.com/lmx/ ============================================= ----- Original Message ----- From: "Even, Roni" To: "Pete Cordell" ; Cc: ; ; "Colin Perkins" ; "Cullen Jennings" ; ; Sent: Thursday, October 25, 2007 1:29 PM Subject: RE: Last Call: draft-levin-mmusic-xml-media-control (XML Schema for Media Control) to Informational RFC Hi Pete, After consulting with my co-authors our view is that industry implemented the solution as specified in the example, so we need to revise the schema based on Pete's suggestion to This also means that we will not have the target name space so we do not need to register it with IANA as specified in section 9.2. If this is correct I will submit a revised revsion. Thanks Roni Even > -----Original Message----- > From: Pete Cordell [mailto:pete@codalogic.com] > Sent: Monday, October 08, 2007 4:22 PM > To: ietf@ietf.org > Cc: oritl@microsoft.com; Even, Roni; pierre@radvision.com > Subject: Re: Last Call: draft-levin-mmusic-xml-media-control (XML Schema > for Media Control) to Informational RFC > > I quickly looked at this and noticed that the XML instance examples don't > match the schema because the instance does not make reference to the > namespace. i.e., to match the schema, the example should be: > > > > > > > > > > > > My expectation is that the instance is actually more authorative in terms > of > what the authors are looking for. If that is the case, the schema should > be > modified along the lines of: > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"> > ... > > i.e. remove the targetNamespace declarations. > > You may have your reasons not to, but if not, you may want to consider > using > schema's documentation features instead of the XML comments; e.g.: > > > > Video control primitive. > > > > ... > > HTH, > > Pete. > -- > ============================================= > Pete Cordell > Codalogic > for XML Schema to C++ data binding visit > http://www.codalogic.com/lmx/ > ============================================= > ----- Original Message ----- > From: "The IESG" > To: "IETF-Announce" > Sent: Monday, October 08, 2007 2:29 PM > Subject: Last Call: draft-levin-mmusic-xml-media-control (XML Schema for > Media Control) to Informational RFC > > > > The IESG has received a request from an individual submitter to consider > > the following document: > > > > - 'XML Schema for Media Control ' > > as an Informational RFC > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2007-11-05. Exceptionally, > > comments may be sent to iesg@ietf.org instead. In either case, please > > retain the beginning of the Subject line to allow automated sorting. > > > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-levin-mmusic-xml-media- > control-11.txt > > > > > > IESG discussion can be tracked via > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=93 > 91&rfc_flag=0 > > > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf-announce > > > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:47:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT15-0002pP-5u; Fri, 26 Oct 2007 13:30:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IidCn-0003Cv-PE for ietf@ietf.org; Thu, 18 Oct 2007 17:47:01 -0400 Received: from hs-out-0708.google.com ([64.233.178.243] helo=hs-out-2021.google.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IidBQ-00029z-5e for ietf@ietf.org; Thu, 18 Oct 2007 17:47:01 -0400 Received: by hs-out-2021.google.com with SMTP id 54so224331hsz for ; Thu, 18 Oct 2007 14:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; bh=rhagqfswa90WJi0TF5jCU3ke0NJkkzFdUv6T7RyaH7I=; b=UVOYwhf21PGGaHDz6tm0WagbsXKNrf0LKcKK+3iOpD+8ocMSM5+m3q8+PncMcIjAyCkgLb8o6P2Rb3Ee3HKdpAo7VPLcYMYHV6BmU45TER6cD3IgSU1x5ard4eTB96yROpt0wFmpZXc9o7INY8NHwMlQIYjkTfjpCosuWj5pSmU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=UJJf3fr3P+KdsZVKFQuEhNm78S0I/6ERRJFJDLEbXM9+kOUL2TxIEHXNcywCi9ap6PcALsLQ2lcXVczGIRzQvM3fAOtO80O5F0JzMq8q32fjjn+rHKUEHEbjn23Wnp6pGDsnWPKlnTaKZx2Iji4uSr71NbYILZQF2DL7+JEqM0g= Received: by 10.90.75.10 with SMTP id x10mr1703598aga.1192743906862; Thu, 18 Oct 2007 14:45:06 -0700 (PDT) Received: by 10.90.113.19 with HTTP; Thu, 18 Oct 2007 14:45:06 -0700 (PDT) Message-ID: <1d0338290710181445h75a0c0a3y31ea4b4f472a0112@mail.gmail.com> Date: Thu, 18 Oct 2007 16:45:06 -0500 From: "Chuck Burgess" To: ietf@ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: 7ad1f35d1828274f X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Fri, 26 Oct 2007 13:30:19 -0400 Cc: campaigns@fsf.org Subject: NO to TLS-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2051629567==" Errors-To: ietf-bounces@ietf.org --===============2051629567== Content-Type: multipart/alternative; boundary="----=_Part_10841_5492903.1192743906853" ------=_Part_10841_5492903.1192743906853 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, I support and second the comments previously sent to you by the FSF ( http://www.fsf.org/campaigns/software-patents/draft-housley-tls-authz-extns.html). Please do not let this standardization attempt continue. -- CRB Let me introduce you to my very own DMCA-protected encryption key: BC 1B 64 4A 8D DE 49 E8 C3 7D CC EE 1A AD EE F5 (compliments of Freedom-to-Tinker http://www.freedom-to-tinker.com/?p=1155) ------=_Part_10841_5492903.1192743906853 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello,

I support and second the comments previously sent to you by the FSF (http://www.fsf.org/campaigns/software-patents/draft-housley-tls-authz-extns.html ). 

Please do not let this standardization attempt continue.
--
CRB

Let me introduce you to my very own DMCA-protected encryption key:
BC 1B 64 4A 8D DE 49 E8 C3 7D CC EE 1A AD EE F5
(compliments of Freedom-to-Tinker http://www.freedom-to-tinker.com/?p=1155) ------=_Part_10841_5492903.1192743906853-- --===============2051629567== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============2051629567==-- From ietf-bounces@ietf.org Fri Oct 26 13:48:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT18-0002ry-4K; Fri, 26 Oct 2007 13:30:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiuOk-0006dC-Np for ietf@ietf.org; Fri, 19 Oct 2007 12:08:30 -0400 Received: from volo.yukidoke.org ([207.210.245.136]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiuOU-0001m7-W2 for ietf@ietf.org; Fri, 19 Oct 2007 12:08:15 -0400 Received: from toivoa.media.mit.edu (localhost [127.0.0.1]) by volo.yukidoke.org (Postfix) with ESMTP id 6D5634158F for ; Fri, 19 Oct 2007 16:00:16 +0000 (UTC) Received: by toivoa.media.mit.edu (Postfix, from userid 1000) id 8B00811D074; Fri, 19 Oct 2007 12:08:13 -0400 (EDT) Date: Fri, 19 Oct 2007 12:08:13 -0400 From: "Benj. Mako Hill" To: ietf@ietf.org Message-ID: <20071019160813.GF11795@yukidoke.org> MIME-Version: 1.0 User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:30:23 -0400 Subject: TLS-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1939838877==" Errors-To: ietf-bounces@ietf.org --===============1939838877== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ylS2wUBXLOxYXZFQ" Content-Disposition: inline --ylS2wUBXLOxYXZFQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable To whom it may concern, Allowing the TLS-authz specification to advance as an "experimental" or "informational" specification is a poor choice by the IETF. The IEFT has taken a reasonable position on patents and standards in the past. To compromise this position by creating new form of quasi-standards dilutes the IETF's authority and weakens its principles. Please reconsider this action and reject the TLS-autz specification, in any form, until the patent issues in question have been resolved. Thank you for your time and consideration. Regards, Mako --=20 Benjamin Mako Hill mako@mit.edu http://mako.cc/ Senior Researcher | MIT Sloan School of Management Fellow | MIT Center for Future Civic Media Advisor | One Laptop per Child Project Member, Board of Directors | Free Software Foundation --ylS2wUBXLOxYXZFQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHGNZtic1LIWB1WeYRAkp0AJ0c5W4/HmQ1ljrKb2aitUj1Sz0INgCg9F8a JcHAsNDxwxTl8T5C9zrT3co= =guTR -----END PGP SIGNATURE----- --ylS2wUBXLOxYXZFQ-- --===============1939838877== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============1939838877==-- From ietf-bounces@ietf.org Fri Oct 26 13:59:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTNX-0003cv-W6; Fri, 26 Oct 2007 13:53:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkHiY-0001Nv-6s for ietf@ietf.org; Tue, 23 Oct 2007 07:14:39 -0400 Received: from vs163115.vserver.de ([62.75.163.115]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkHiJ-00029D-9p for ietf@ietf.org; Tue, 23 Oct 2007 07:14:34 -0400 Received: from [91.39.167.175] (helo=[192.168.178.200]) by vs163115.vserver.de with esmtpsa (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.63) (envelope-from ) id 1IkHhX-0004fD-UT for ietf@ietf.org; Tue, 23 Oct 2007 11:14:02 +0000 From: Martin =?ISO-8859-1?Q?J=FCrgens?= To: ietf@ietf.org Content-Type: text/plain; charset=UTF-8 Date: Tue, 23 Oct 2007 13:10:33 +0200 Message-Id: <1193137833.3016.13.camel@localhost6.localdomain6> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-4.fc7) Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 91.39.167.175 X-SA-Exim-Mail-From: martin@gamesplace.info X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on vs163115.vserver.de X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7-deb X-SA-Exim-Version: 4.2.1 (built Tue, 09 Jan 2007 17:23:22 +0000) X-SA-Exim-Scanned: Yes (on vs163115.vserver.de) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:53:29 -0400 Subject: TLS-authz standard X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hello, herewith I express my concerns in pushing TLS-authz as an experimental or informal standard (http://tools.ietf.org/wg/tls/draft-housley-tls-authz-extns-07.txt). The patents hold by Red Phone Security (https://datatracker.ietf.org/ipr/833/) would prevent developers of open source software to implent this standard.=20 As a huge amount of servers use open source software (in which the standard would not be integrated), the standard would not get implented in lots of environments. Martin J=C3=BCrgens _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:59:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTNY-0003d2-HU; Fri, 26 Oct 2007 13:53:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkI83-0000Zy-0P for ietf@ietf.org; Tue, 23 Oct 2007 07:40:59 -0400 Received: from zeus.suchwerk.de ([88.198.52.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkI7t-0003No-Pw for ietf@ietf.org; Tue, 23 Oct 2007 07:40:55 -0400 Received: from localhost (localhost [127.0.0.1]) by zeus.suchwerk.de (Postfix) with ESMTP id 68EB82A5958; Tue, 23 Oct 2007 13:40:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at suchwerk.de Received: from zeus.suchwerk.de ([127.0.0.1]) by localhost (zeus.suchwerk.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPBH1g+tIH+q; Tue, 23 Oct 2007 13:40:24 +0200 (CEST) Received: from ws1.m1b.de (L6d0e.l.strato-dslnet.de [89.48.109.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by zeus.suchwerk.de (Postfix) with ESMTP id 7722129DB7D; Tue, 23 Oct 2007 13:40:24 +0200 (CEST) From: Reinhard Moosauer To: ietf@ietf.org Date: Tue, 23 Oct 2007 13:40:23 +0200 User-Agent: KMail/1.9.5 Organization: http://m1b.de MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710231340.23121.office@moosauer.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:53:30 -0400 Cc: campaigns@fsf.org Subject: We oppose TLS-authz "experimental" standard X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Dears Sirs, we join the FSF in opposing to the TLS-authz "experimental" standard! Kind regards Reinhard Moosauer IT Beratung -- Reinhard Moosauer IT Beratung Neustadt 449 84028 Landshut EMail: office@Moosauer.de Tel: (0871) 27 63 92 32 Fax: (0871) 9247871 Web: http://www.m1b.de _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:59:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTNU-0003cR-Vx; Fri, 26 Oct 2007 13:53:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik9Kw-0007f7-65 for ietf@ietf.org; Mon, 22 Oct 2007 22:17:42 -0400 Received: from fk-out-0910.google.com ([209.85.128.187]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik9Kv-0006ew-Sp for ietf@ietf.org; Mon, 22 Oct 2007 22:17:42 -0400 Received: by fk-out-0910.google.com with SMTP id z23so1368710fkz for ; Mon, 22 Oct 2007 19:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=7dA73W9FUlm5368EHlQSjWBuDs3kYuWUw1msFpbO9rQ=; b=YNymh+PMUwjela2W36PF5RQ1cl1CI8SMLUsl6b+crlTJjacXKMoXd+JYCICeQffUHkHlTVvxwIVj6cZnJ6fOAh3a9SBm0I2BOch8Kkv9mDZUyMRWJ6duWNj8ZCh8GftLpWhAUD7OBW7+HOspqZSdA71BooH+xMIsMpZ9DqhWnak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=gbcG6qZhJlvr0fB8GDkxQZGi9OshiIrpsffVjt2Bfbn+dPa/SSpxx8p0NcAImiuGY8YUUt5T95UI32f5uFzoml+tm7mmUsboHumth91smF+BT0rU+f9A84QmmSuXLhiKodJ4VbMSxGtBB5bv2I5BM2S+Ikj8pZBtfCBR/JLTH8A= Received: by 10.82.107.15 with SMTP id f15mr9480249buc.1193104417771; Mon, 22 Oct 2007 18:53:37 -0700 (PDT) Received: by 10.82.179.12 with HTTP; Mon, 22 Oct 2007 18:53:37 -0700 (PDT) Message-ID: <455d7d2d0710221853q27a8c0a6qcf11bc76ac5f99f4@mail.gmail.com> Date: Mon, 22 Oct 2007 19:53:37 -0600 From: "Richard Wilbur" To: ietf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:53:30 -0400 Cc: campaigns@fsf.org Subject: TLS-authz "experimental" standard X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org To those considering the TLS-authz proposal: The patent shenanigans of RedPhone Security have reduced implementation status from "open" to "taxed at the whim of RedPhone Security." This should be enough to disqualify the proposal from further consideration unless, and until, RedPhone Security grants a royalty-free license for all users. The imprimatur of the IETF should remain reserved for open standards. Thank you for considering my position. Sincerely, Richard Wilbur Senior Software Developer Server Software _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:59:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTNQ-0003by-Mx; Fri, 26 Oct 2007 13:53:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IidCz-0003Hk-9K for ietf@ietf.org; Thu, 18 Oct 2007 17:47:13 -0400 Received: from server1.f7.net ([64.34.169.74] helo=f7.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IidCu-0002NP-Vs for ietf@ietf.org; Thu, 18 Oct 2007 17:47:09 -0400 X-Envelope-From: karl@freefriends.org X-Envelope-To: ietf@ietf.org Received: (from karl@localhost) by f7.net (8.11.7-20030920/8.11.7) id l9ILl8J09639; Thu, 18 Oct 2007 16:47:08 -0500 Date: Thu, 18 Oct 2007 16:47:08 -0500 Message-Id: <200710182147.l9ILl8J09639@f7.net> From: karl@freefriends.org (Karl Berry) To: ietf@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:53:27 -0400 Cc: campaigns@fsf.org Subject: rejection of patents and standards X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I ask you to reject http://tools.ietf.org/wg/tls/draft-housley-tls-authz-extns-07.txt from the experimental track, as it was rejected on the official track. A standard that can only be implemented with permission of and payment to a software patent holder is no standard at all. As you know so well, software patents have no place in public standards. Thank you for the chance to comment, and all your efforts! Karl Berry (programmer) _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:59:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTNT-0003c8-0H; Fri, 26 Oct 2007 13:53:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IifAi-0000Na-G7 for ietf@ietf.org; Thu, 18 Oct 2007 19:53:00 -0400 Received: from blue.powerfulnet.net ([80.68.94.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iif9E-0006X2-4j for ietf@ietf.org; Thu, 18 Oct 2007 19:53:00 -0400 Received: from silver.local ([::ffff:213.79.37.170]) (AUTH: PLAIN pupeno@pupeno.com, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by blue.powerfulnet.net with esmtp; Fri, 19 Oct 2007 00:49:15 +0100 id 0007803F.4717F109.000055B5 From: "J. Pablo =?utf-8?q?Fern=C3=A1ndez?=" To: ietf@ietf.org Date: Fri, 19 Oct 2007 00:47:58 +0100 User-Agent: KMail/1.9.6 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200710190047.59493.pupeno@pupeno.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-Mailman-Approved-At: Fri, 26 Oct 2007 13:53:28 -0400 Subject: A pattented standard is not a standard X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hello, The idea of an standard is to make communication possible and easy. A=20 pattented standard is a call for chaos or a tax on communication. I'm very= =20 much with the FSF in opposing TLS-authz. Thank you. =2D-=20 J. Pablo Fern=C3=A1ndez (http://pupeno.com) _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:59:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTNW-0003cj-U0; Fri, 26 Oct 2007 13:53:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkGQY-0004zG-2g; Tue, 23 Oct 2007 05:51:58 -0400 Received: from smtp1.mail.adnap.net.au ([203.6.132.75]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkGQT-0007IO-HX; Tue, 23 Oct 2007 05:51:53 -0400 Received: from 219-90-189-114.ip.adam.com.au ([219.90.189.114] helo=mail.nosense.org) by smtp1.mail.adnap.net.au with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IkGQN-0009pT-OP; Tue, 23 Oct 2007 19:21:47 +0930 Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id 075CC4412F; Tue, 23 Oct 2007 19:20:53 +0930 (CST) Date: Tue, 23 Oct 2007 19:20:53 +0930 From: Mark Smith To: jordi.palet@consulintel.es Message-Id: <20071023192053.4e54176b.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: X-Mailer: Sylpheed 2.4.5 (GTK+ 2.10.14; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Fri, 26 Oct 2007 13:53:28 -0400 Cc: ipv6@ietf.org, ietf@ietf.org Subject: Re: An example of what is wrong with the IETF's IPv6 documentation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Tue, 23 Oct 2007 10:52:36 +0200 JORDI PALET MARTINEZ wrote: > As IETF Sergeant-at-arms, I will suggest that this topic is specific to 6MAN > and should be further discussed there. > Books worked for me, but then again, I'm willing to spend my own money on keeping my knowledge up to date. It seems a fair number of operational people aren't interested in doing that. RFCs of course helped clarify points. RFCs themselves are a waste of time I think for this problem. In my experience most operational people in networking don't read those either - sadly they don't know what they're missing. Power point presentations at NANOG and other meetings seems to be the only answer (sadly). Maybe groups like the IPv6 forum need to create evangelist roles and send those people around to evangelising. Regards, Mark. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:59:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTNb-0003dc-9r; Fri, 26 Oct 2007 13:53:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkhSq-0008MZ-UZ; Wed, 24 Oct 2007 10:44:08 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkhSq-0006u9-3C; Wed, 24 Oct 2007 10:44:08 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id B7C7D175EF; Wed, 24 Oct 2007 14:43:27 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IkhSB-0004yU-98; Wed, 24 Oct 2007 10:43:27 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: IETF Announcement list From: The IESG Message-Id: Date: Wed, 24 Oct 2007 10:43:27 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-Mailman-Approved-At: Fri, 26 Oct 2007 13:53:31 -0400 Cc: ietf@ietf.org, iesg@iesg.org Subject: Call for IAOC Nominations and Volunteers X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org The IESG is making a call for volunteers for the IETF Administrative Oversight Committee (IAOC), as described in BCP 101 (RFC 4071), following the procedures documented in BCP 113 (RFC 4333). The nominations open now, and they will close on 18 Nov 2007. In alternate years. the IESG and the IAB each select one person for a two-year IAOC term. This year, the IESG will select one person for a term beginning in the Spring of 2008. The incumbent is Kurtis Lindqvist. Candidates for these IAOC positions should have knowledge of the IETF, knowledge of contracts and financial procedures, and familiarity with the administrative support needs of the IAB, the IESG, and the IETF standards process. Candidates are also expected to be able to understand the respective roles and responsibilities of the IETF and ISOC in this activity, and be able to articulate these roles within the IETF community. Acceptable candidates must be prepared to exercise all the duties of an IAOC member. These responsibilities include, but are not limited to, the setting of administrative support policies, oversight of the administrative operations of the IETF, and representing the interests of the IETF to the IAOC. Acceptable candidates must be able to undertake full participation in all IAOC meetings and activities. The IESG-selected member of the IAOC does not directly represent the IESG. The IAB and IESG selected members are accountable directly to the IETF community. As such, candidates do not need to be current members of the IAB or the IESG, and in fact we prefer nominations and volunteers from the rest of the community. If you are interested in one of these positions, or know of someone who may be a good fit for this position, please send the name and email address to . The IESG will respond with a questionnaire, asking for the candidates' qualifications and willingness to serve. The names of all people who declare themselves willing to serve will be made public on the ietf-announce@ietf.org list after the end of the solicitation period. The plan is to post the list of candidates on 17 Dec 2007. The IESG expects to make a decision on or before 1 Feb 2007. Note that NomCom is also selecting an IAOC member, and the goal is for the IESG selection to conclude shortly before NomCom announces their selection. On Behalf of the IESG, Russ Housley _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:59:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTNT-0003cH-Rd; Fri, 26 Oct 2007 13:53:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij0QH-0004LW-Q6 for ietf@ietf.org; Fri, 19 Oct 2007 18:34:29 -0400 Received: from cotopaxi.tusojos.com ([69.16.212.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ij0QC-0000wQ-Hz for ietf@ietf.org; Fri, 19 Oct 2007 18:34:24 -0400 Received: from nobody by cotopaxi.tusojos.com with local (Exim 4.63) (envelope-from ) id 1Ij0QB-0001IU-RU; Fri, 19 Oct 2007 17:34:23 -0500 To: ietf@ietf.org Date: Fri, 19 Oct 2007 17:34:23 CDT From: "Ismael Jones" Message-ID: <20071019488.4885591192833263@tusojos.com> X-Mailer: SocketMail Engine version X-Remote_Addr: 216.199.177.99 Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cotopaxi.tusojos.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - cotopaxi.tusojos.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:53:28 -0400 Cc: campaigns@fsf.org Subject: Please reject proprietary standards. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ismael Jones List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Best IETF, In response to the recent TLS submission, I would like to ask you sincerely to reject at all levels any standard which relies on proprietary or otherwise commercially-based technologies. Thank you very much for your consideration. Best regards, Ismael Fal ismaeljones@tusojos.com http://ismaeljones.tusojos.com/ :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Obtén el correo electrónico que estabas buscando, GRATIS !. Ejemplos: oswaldo@ingeniero1.com, marzela@abogada1.com, julio@jaramillo1.com, karla@fotografa.org Tu e-mail será: fácil de recordar, profesional y te representará. Ingresa a www.tusojos.com y subscríbete hoy mismo. :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:59:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTNb-0003dc-9r; Fri, 26 Oct 2007 13:53:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkhSq-0008MZ-UZ; Wed, 24 Oct 2007 10:44:08 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkhSq-0006u9-3C; Wed, 24 Oct 2007 10:44:08 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id B7C7D175EF; Wed, 24 Oct 2007 14:43:27 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IkhSB-0004yU-98; Wed, 24 Oct 2007 10:43:27 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: IETF Announcement list From: The IESG Message-Id: Date: Wed, 24 Oct 2007 10:43:27 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-Mailman-Approved-At: Fri, 26 Oct 2007 13:53:31 -0400 Cc: ietf@ietf.org, iesg@iesg.org Subject: Call for IAOC Nominations and Volunteers X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org The IESG is making a call for volunteers for the IETF Administrative Oversight Committee (IAOC), as described in BCP 101 (RFC 4071), following the procedures documented in BCP 113 (RFC 4333). The nominations open now, and they will close on 18 Nov 2007. In alternate years. the IESG and the IAB each select one person for a two-year IAOC term. This year, the IESG will select one person for a term beginning in the Spring of 2008. The incumbent is Kurtis Lindqvist. Candidates for these IAOC positions should have knowledge of the IETF, knowledge of contracts and financial procedures, and familiarity with the administrative support needs of the IAB, the IESG, and the IETF standards process. Candidates are also expected to be able to understand the respective roles and responsibilities of the IETF and ISOC in this activity, and be able to articulate these roles within the IETF community. Acceptable candidates must be prepared to exercise all the duties of an IAOC member. These responsibilities include, but are not limited to, the setting of administrative support policies, oversight of the administrative operations of the IETF, and representing the interests of the IETF to the IAOC. Acceptable candidates must be able to undertake full participation in all IAOC meetings and activities. The IESG-selected member of the IAOC does not directly represent the IESG. The IAB and IESG selected members are accountable directly to the IETF community. As such, candidates do not need to be current members of the IAB or the IESG, and in fact we prefer nominations and volunteers from the rest of the community. If you are interested in one of these positions, or know of someone who may be a good fit for this position, please send the name and email address to . The IESG will respond with a questionnaire, asking for the candidates' qualifications and willingness to serve. The names of all people who declare themselves willing to serve will be made public on the ietf-announce@ietf.org list after the end of the solicitation period. The plan is to post the list of candidates on 17 Dec 2007. The IESG expects to make a decision on or before 1 Feb 2007. Note that NomCom is also selecting an IAOC member, and the goal is for the IESG selection to conclude shortly before NomCom announces their selection. On Behalf of the IESG, Russ Housley _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:59:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTNT-0003cH-Rd; Fri, 26 Oct 2007 13:53:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij0QH-0004LW-Q6 for ietf@ietf.org; Fri, 19 Oct 2007 18:34:29 -0400 Received: from cotopaxi.tusojos.com ([69.16.212.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ij0QC-0000wQ-Hz for ietf@ietf.org; Fri, 19 Oct 2007 18:34:24 -0400 Received: from nobody by cotopaxi.tusojos.com with local (Exim 4.63) (envelope-from ) id 1Ij0QB-0001IU-RU; Fri, 19 Oct 2007 17:34:23 -0500 To: ietf@ietf.org Date: Fri, 19 Oct 2007 17:34:23 CDT From: "Ismael Jones" Message-ID: <20071019488.4885591192833263@tusojos.com> X-Mailer: SocketMail Engine version X-Remote_Addr: 216.199.177.99 Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cotopaxi.tusojos.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - cotopaxi.tusojos.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:53:28 -0400 Cc: campaigns@fsf.org Subject: Please reject proprietary standards. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ismael Jones List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Best IETF, In response to the recent TLS submission, I would like to ask you sincerely to reject at all levels any standard which relies on proprietary or otherwise commercially-based technologies. Thank you very much for your consideration. Best regards, Ismael Fal ismaeljones@tusojos.com http://ismaeljones.tusojos.com/ :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Obtén el correo electrónico que estabas buscando, GRATIS !. Ejemplos: oswaldo@ingeniero1.com, marzela@abogada1.com, julio@jaramillo1.com, karla@fotografa.org Tu e-mail será: fácil de recordar, profesional y te representará. Ingresa a www.tusojos.com y subscríbete hoy mismo. :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:59:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTNX-0003cp-Ey; Fri, 26 Oct 2007 13:53:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkGzu-00049U-0Z for ietf@ietf.org; Tue, 23 Oct 2007 06:28:30 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IkGzr-0000Jl-7i for ietf@ietf.org; Tue, 23 Oct 2007 06:28:29 -0400 Received: (qmail invoked by alias); 23 Oct 2007 10:28:21 -0000 Received: from dynamic-unidsl-85-197-22-171.westend.de (EHLO [192.168.0.7]) [85.197.22.171] by mail.gmx.net (mp041) with SMTP; 23 Oct 2007 12:28:21 +0200 X-Authenticated: #1561828 X-Provags-ID: V01U2FsdGVkX1+ntSsXKJunTWn9vYtHHfl+D6VlKtSpHWk0pj3HFW f+JqwZnymk8zl4 Message-ID: <471DCCBB.5080403@gmx.de> Date: Tue, 23 Oct 2007 12:28:11 +0200 From: Sven Lilienthal User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: ietf@ietf.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Fri, 26 Oct 2007 13:53:30 -0400 Cc: campaigns@fsf.org Subject: I oppose making TLS-authz an experimental standard X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I oppose publication of draft-housley-tls-authz-extns as an experimental standard. The patent application disclosed by RedPhone Security has put any free software attempting to implement these extensions in a very difficult position. Free software developers cannot safely code to the specifications without risking infringement on RedPhone's patents. As a result of these concerns and the uncertain situation they create, GnuTLS has removed support for them in its latest release -- and no other software maintained by the GNU Project will be written to them. I know that the IETF and IESG largely share our view that patent-encumbered standards are unacceptable. I believe that the process has reached the proper conclusion -- the draft has been rejected as a standard. Please do not allow this decision to be negated by publishing it on the experimental track. I agree with Sam Hartman that "often it seems that we use informational as a way to publish things we cannot build a strong consensus behind. I think that process is generally problematic and would like to avoid it in this instance," and with Simon Josefsson that "[g]iven that the initial last call was to put the document on the standards track, my impression would be that this last call request for the experimental track is indeed intended to circumvent the normal process." In the long term, widespread adoption of something published on this track would put software authors in the same bad position as if the document were approved as a standard. Please respect the consensus that has been reached and do not publish this draft. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:59:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTNa-0003dW-Nf; Fri, 26 Oct 2007 13:53:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkczP-0005JA-U3 for ietf@ietf.org; Wed, 24 Oct 2007 05:57:27 -0400 Received: from smtp21.orange.fr ([80.12.242.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkczE-0006h4-1U for ietf@ietf.org; Wed, 24 Oct 2007 05:57:24 -0400 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2106.orange.fr (SMTP Server) with ESMTP id C4F111C0009B for ; Wed, 24 Oct 2007 11:56:54 +0200 (CEST) Received: from HARNON (APoitiers-258-1-4-223.w90-45.abo.wanadoo.fr [90.45.27.223]) by mwinf2106.orange.fr (SMTP Server) with ESMTP id 949371C0009A; Wed, 24 Oct 2007 11:56:53 +0200 (CEST) X-ME-UUID: 20071024095653608.949371C0009A@mwinf2106.orange.fr From: "Philippe Verdy" To: , References: <001d01c815e8$b2b966b0$6401a8c0@LROSENTOSHIBA> Date: Wed, 24 Oct 2007 11:56:50 +0200 Organization: Ordinateur Personnel Message-ID: <015101c81624$3357e090$0a01a8c0@rodage.dyndns.org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <001d01c815e8$b2b966b0$6401a8c0@LROSENTOSHIBA> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgV6LDV1h0ax/DmTLatmeFJFPPcyQAMyUPw X-Spam-Score: 0.0 (/) X-Scan-Signature: 72be645574b2b4b84446d27f730bf563 X-Mailman-Approved-At: Fri, 26 Oct 2007 13:53:28 -0400 Cc: license-discuss@opensource.org Subject: RE: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: verdy_p@wanadoo.fr List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1793450186==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============1793450186== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0152_01C81634.F6E0B090" This is a multi-part message in MIME format. ------=_NextPart_000_0152_01C81634.F6E0B090 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The FSF campaigns against the current IETF policy and the current policy used in several standard bodies (notably ISO) who currently accept = standards encumbered with patents, only if they are licensed to everyone who ask = for it, under =93reasonable=94 or =93fair=94 licensing practices. However = the acceptable licenses are not precisely defined (at ISO, patent licensing royalties = are still acceptable), and notably this does not restrict the licensors from requiring a nominative agreement with each licensee. Such standards do = exist in ISO (notably most MPEG related applications are covered by such restrictive licenses). =20 However, the FSF recognizes that, until now, the IETF was more strict = about the licensing conditions, rejecting proposals that included = royalties-maker licenses and explicit personal agreement between the licensor and the licensees (under this scheme, if it was accepted, nothing would prevent = a licensor to start charging yearly royalties to each licensor for = exercising the patented rights. =20 But, the IETF is less strict about RFCs that are published with =93informational=94 status. We do have lots of informational RFCs which = are still needed and actively used, sometimes even required (notably those = in the BCP series, like the =93Netiquette=94 which has become a requirement = for almost all ISP customers, as part of their contract, despite they are = only informational, and could change at any time after having been replaced = by another RFC replacing the older one with the same BCP number. =20 I do approve the FSF campaign: if the IETF publishes a RFC, and even if = it=92s just informational and still not a =93BCP=94 recommendation, those RFCs = should really be patent free, or exempt from non-free patents requiring an = explicit license. We have already seen in the past the case where a licensor = changed its policy, and started to claim royaltees for what was initially = granted for free and licensed to any one without charge. We can accept the = existence of patents only as a way to prevent another counter-patent to be = reserved by someone else (but in a free world, such patent is normally not needed, = as the copyright assignment and its legal protection is enough to avoid = this). =20 However, the WIPO is currently changing the game, trying to merge the = two systems of copyrights and patents into a single one with equal force, forcing those that just want a protection of their copyright to register = it at some national or international registry to maintain the protection. = This is a dangerous evolution, because it would harm all legitimate authors = that have produced valuable works, and assigned a their copyright on these = works, to protect it from claims by others: they would now have to pay each = year some fee to a registry to maintain the protection on their own work; if = they just forget to do that, someone else (richer than the authors) will = apply for a patent registration and will pay indefinitely the registry to gain = and enforce the legal protection. =20 For this reason, we should only accept patents that are protected with = the following minimum bases: * Licensed to anyone without condition, and in every country (within the limitations of the national laws applicable to the licensors, such = as export/import controls, but at the time of proposal or publication of = the standard, such legal restrictions should not exist, and the IETF should invite all governments to rapidly express their reservations against = legal restrictions in their area, by submitting also a copy to ISO members = where worldwide governments are represented). * (If legal restrictions exists and are known to the IETF or to the standard proposer, they MUST signal them, so that every licencee car = verify if the standard is usable for their intended application). * Licensed only in a non-exclusive way (no licensee can claim ownership or reservation within some domains of application or exercise = of the patent, or reservation in any place, against other competing = licensees): all licensees being treated equally, whatever the time when they first = got their license. * Does not require an explicit agreement between each licensor and licensee. * Grants usage and distribution rights to anyone, acting then as a legal sublicensor: the sublicensor must not forbid the exercise of the distribution right by its own licensees. * Being granted without limitation of time, including the distribution right (so that new licensees can always come and apply the same terms). * Offers a warranty (signed by the patent owner) to licensors that the patent does not violate any other patent or copyright or author=92s = rights. * Making this warranty permanent too, and without requesting any charge to pay by the licensees and distributors (including the IETF). * Offer a signed warranty of indemnification of licensees and of the IETF if the patent licensor has violated these rights. * Stating contractually that no further charges will be requested to all licensees in the future by the patent owner. With all these conditions, patents are in fact not needed. We much = prefer the system of copyrights which is much simpler to protect open and free technologies. =20 If needed, all RFCs published by the IETF should first pass a long = enough transitory period where the RFC is published but with strong notice that = it is not approved, so that the only rile of the publication is to verify = that the RFC does not violate any rights. After this time has elapsed (2-3 = years after first publication?) during which the other patent owners have had = the possibility to exercise their rights, the RFC could be only be in an informational state, becoming a recommendation later. * The IETF should also make some efforts to propose alternatives to every published standard, so that at least one replacement technology is also published with the same status, allowing applications to implement several of them, and possibly turning down rapidly, with less efforts, = any technology for which a patent becomes applicable. The BCP standard track should list the alternative technologies, and not promote only one. * In addition all standard should support optional additions and a framework for making these options interoperable with other = implementations of the standard that don=92t have this option. This will ease the = replacement of one technology by another if there is any problem with a technologies that was informally considered =94the best=94 one (but appears to be now encumbered by costly patent claims). In fact this should be the role of standards: not promoting a single technology, but providing this free framework for interoperability. The =93requirements=94 in a standard = should be only about interoperability, not about an exclusive implementation = solution. * So supporting the extensibility should be a requirement for conformance. If a =93standard=94 does not support extensibility, it = should be deprecated or another newer standard should be created rapidly as an accepted alternative, within which the currently deprecated standard = would just become a particular implementation. =20 _____ =20 De : Lawrence Rosen [mailto:lrosen@rosenlaw.com]=20 Envoy=E9 : mercredi 24 octobre 2007 04:51 =C0 : ietf@ietf.org Cc : license-discuss@opensource.org Objet : Re: A priori IPR choices =20 To: IETF list =20 These are statements from FSF about the issue we've been discussing at ietf@ietf.org.=20 =20 http://www.fsf.org/campaigns/software-patents/draft-housley-tls-authz-ext= ns. html=20 =20 and =20 http://www.fsf.org/news/oppose-tls-authz-standard.html=20 =20 The GPL does not have problems with most IETF specifications, only those that are encumbered by non-free patents. This is an important example of = why so many of us in the open source and free software communities believe = that the IETF patent policy must be improved.=20 =20 ------=_NextPart_000_0152_01C81634.F6E0B090 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The FSF = campaigns against the current IETF policy and the current policy used in several standard = bodies (notably ISO) who currently accept standards encumbered with patents, = only if they are licensed to everyone who ask for it, under = “reasonable” or “fair” licensing practices. However the acceptable licenses = are not precisely defined (at ISO, patent licensing royalties are still = acceptable), and notably this does not restrict the licensors from requiring a = nominative agreement with each licensee. Such standards do exist in ISO (notably = most MPEG related applications are covered by such restrictive = licenses).

 =

However, the FSF recognizes that, until now, the IETF was more strict about the licensing conditions, rejecting proposals that included royalties-maker licenses = and explicit personal agreement between the licensor and the licensees (under this = scheme, if it was accepted, nothing would prevent a licensor to start charging = yearly royalties to each licensor for exercising the patented = rights.

 =

But, the IETF is = less strict about RFCs that are published with “informational” = status. We do have lots of informational RFCs which are still needed and actively = used, sometimes even required (notably those in the BCP series, like the = “Netiquette” which has become a requirement for almost all ISP customers, as part of = their contract, despite they are only informational, and could change at any = time after having been replaced by another RFC replacing the older one with the = same BCP number.

 =

I do approve the = FSF campaign: if the IETF publishes a RFC, and even if it’s just informational and still not a “BCP” recommendation, those = RFCs should really be patent free, or exempt from non-free patents requiring = an explicit license. We have already seen in the past the case where a licensor = changed its policy, and started to claim royaltees for what was initially granted = for free and licensed to any one without charge. We can accept the existence of = patents only as a way to prevent another counter-patent to be reserved by = someone else (but in a free world, such patent is normally not needed, as the = copyright assignment and its legal protection is enough to avoid = this).

 =

However, the = WIPO is currently changing the game, trying to merge the two systems of = copyrights and patents into a single one with equal force, forcing those that just want = a protection of their copyright to register it at some national or = international registry to maintain the protection. This is a dangerous evolution, = because it would harm all legitimate authors that have produced valuable works, and assigned a their copyright on these works, to protect it from claims by = others: they would now have to pay each year some fee to a registry to maintain = the protection on their own work; if they just forget to do that, someone = else (richer than the authors) will apply for a patent registration and will pay indefinitely the registry to gain and enforce the legal = protection.

 =

For this reason, = we should only accept patents that are protected with the following minimum = bases:

  • Licensed to anyone without condition, and in every country = (within the limitations of the national laws applicable to the licensors, = such as export/import controls, but at the time of proposal or publication = of the standard, such legal restrictions should not exist, and the IETF = should invite all governments to rapidly express their reservations = against legal restrictions in their area, by submitting also a copy to ISO = members where worldwide governments are = represented).
  • (If legal restrictions exists and are known to the IETF or = to the standard proposer, they MUST signal them, so that every licencee = car verify if the standard is usable for their intended = application).
  • Licensed only in a non-exclusive way (no licensee can claim ownership or reservation within some domains of application or = exercise of the patent, or reservation in any place, against other competing = licensees): all licensees being treated equally, whatever the time when they = first got their license.
  • Does not require an explicit agreement between each licensor = and licensee.
  • Grants usage and distribution rights to anyone, acting then = as a legal sublicensor: the sublicensor must not forbid the exercise of = the distribution right by its own = licensees.
  • Being granted without limitation of time, including the distribution right (so that new licensees can always come and apply = the same terms).
  • Offers a warranty (signed by the patent owner) to licensors = that the patent does not violate any other patent or copyright or = author’s rights.
  • Making this warranty permanent too, and without requesting = any charge to pay by the licensees and distributors (including the = IETF).
  • Offer a signed warranty of indemnification of licensees and = of the IETF if the patent licensor has violated these = rights.
  • Stating contractually that no further charges will be = requested to all licensees in the future by the patent = owner.

With all these = conditions, patents are in fact not needed. We much prefer the system of copyrights = which is much simpler to protect open and free = technologies.

 =

If needed, all = RFCs published by the IETF should first pass a long enough transitory period = where the RFC is published but with strong notice that it is not approved, so = that the only rile of the publication is to verify that the RFC does not = violate any rights. After this time has elapsed (2-3 years after first publication?) = during which the other patent owners have had the possibility to exercise their = rights, the RFC could be only be in an informational state, becoming a = recommendation later.

  • The IETF should also make some efforts to propose = alternatives to every published standard, so that at least one replacement = technology is also published with the same status, allowing applications to = implement several of them, and possibly turning down rapidly, with less = efforts, any technology for which a patent becomes applicable. The BCP standard = track should list the alternative technologies, and not promote only = one.
  • In addition all standard should support optional additions = and a framework for making these options interoperable with other = implementations of the standard that don’t have this option. This will ease = the replacement of one technology by another if there is any problem = with a technologies that was informally considered ”the best” = one (but appears to be now encumbered by costly patent claims). In fact = this should be the role of standards: not promoting a single technology, = but providing this free framework for interoperability. The = “requirements” in a standard should be only about interoperability, not about an = exclusive implementation solution.
  • So supporting the extensibility should be a requirement for conformance. If a “standard” does not support = extensibility, it should be deprecated or another newer standard should be created = rapidly as an accepted alternative, within which the currently deprecated = standard would just become a particular = implementation.

 =


De : = Lawrence Rosen [mailto:lrosen@rosenlaw.com]
Envoy=E9 : mercredi = 24 octobre 2007 04:51
=C0 : = ietf@ietf.org
Cc : license-discuss@opensource.org
Objet : Re: A priori = IPR choices

 

To: IETF list

 

These are statements from FSF about the issue = we've been discussing at ietf@ietf.org. =

 

http://www.fsf.org/campaigns/software-patents/draft-hous= ley-tls-authz-extns.html

 

and

 

http://ww= w.fsf.org/news/oppose-tls-authz-standard.html

 

The GPL does not have problems with most IETF specifications, only those that are encumbered by non-free patents. This = is an important example of why so many of us in the open source and free = software communities believe that the IETF patent policy must be improved. =

 

------=_NextPart_000_0152_01C81634.F6E0B090-- --===============1793450186== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============1793450186==-- From ietf-bounces@ietf.org Fri Oct 26 13:59:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTNZ-0003dB-39; Fri, 26 Oct 2007 13:53:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkLdk-0002Mp-VM for ietf@ietf.org; Tue, 23 Oct 2007 11:25:56 -0400 Received: from mailout1.informatik.tu-muenchen.de ([131.159.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkLdY-0005m5-No for ietf@ietf.org; Tue, 23 Oct 2007 11:25:50 -0400 Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 7A3B347C71; Tue, 23 Oct 2007 17:24:44 +0200 (CEST) Received: from thrush.net.informatik.tu-muenchen.de (thrush.net.informatik.tu-muenchen.de [131.159.14.42]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 6A65E2484; Tue, 23 Oct 2007 17:24:44 +0200 (CEST) Date: Tue, 23 Oct 2007 17:24:44 +0200 (CEST) From: Richard Hartmann X-X-Sender: richih@thrush.net.informatik.tu-muenchen.de To: ietf@ietf.org, campaigns@fsf.org Message-ID: X-GPG-PUBLIC_KEY: http://richih.org/gpg_temp.asc X-GPG-FINGRPRINT: F8B01AA8 - 1FD6 D300 9E74 C048 0F04 ABCB FA13 A785 F8B0 1AA8 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 2.2 (++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-Mailman-Approved-At: Fri, 26 Oct 2007 13:53:29 -0400 Cc: Subject: Opposition to accepting TLS-authz an experimental standard X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Dear Sirs and Madams, I just wanted to let you know that I fully agree with the FSF's position [1] on making TLS-authz an experimental standard. As their rationale is covering all important points, I can save myself and yourself the effort to write and read a lengthy rationale of my own. Best regards, Richard Hartmann [1] http://www.fsf.org/campaigns/software-patents/draft-housley-tls-authz-extns.html _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 13:59:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTNb-0003dj-RD; Fri, 26 Oct 2007 13:53:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il2RM-0007xl-Sp for ietf@ietf.org; Thu, 25 Oct 2007 09:08:00 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il2RI-0002nb-Mu for ietf@ietf.org; Thu, 25 Oct 2007 09:07:57 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 25 Oct 2007 06:07:54 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l9PD7r3F002456; Thu, 25 Oct 2007 06:07:53 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l9PD7n7B002842; Thu, 25 Oct 2007 13:07:51 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 09:07:50 -0400 Received: from swbmbp.local.employees.org ([10.86.242.230]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 09:07:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18208.38178.806394.851986@swbmbp.local> Date: Thu, 25 Oct 2007 09:07:46 -0400 From: Scott Brim To: "Hallam-Baker, Phillip" In-Reply-To: <2788466ED3E31C418E9ACC5C31661557084F05@mou1wnexmb09.vcorp.ad.vrsn.com> References: <8138-SnapperMsgD8DB99B6C3444D0A@[70.195.169.164]> <20071024105010.90F0622024E@quill.bollow.ch> <200710241133.41148.scott@kitterman.com> <2788466ED3E31C418E9ACC5C31661557084F05@mou1wnexmb09.vcorp.ad.vrsn.com> X-OriginalArrivalTime: 25 Oct 2007 13:07:49.0685 (UTC) FILETIME=[0B4D4650:01C81708] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15504.002 X-TM-AS-Result: No--6.459800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Authentication-Results: sj-dkim-4; header.From=swbhelp@employees.org; dkim=neutral X-Spam-Score: -4.0 (----) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-Mailman-Approved-At: Fri, 26 Oct 2007 13:53:29 -0400 Cc: Scott Kitterman , ietf@ietf.org Subject: RE: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 24 Oct 2007 at 11:01 -0700, Hallam-Baker, Phillip allegedly wrote: > What I would like to do here is to arrive at a set of terms that is > considered to be sufficiently RANDZ NO license required is better than RANDZ. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 14:14:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTXd-0000n6-Ja; Fri, 26 Oct 2007 14:04:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTXc-0000n0-7e for ietf@ietf.org; Fri, 26 Oct 2007 14:04:16 -0400 Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlTXb-0002Yb-Tn for ietf@ietf.org; Fri, 26 Oct 2007 14:04:16 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=UX9/xx887aGiTdmKzZAsTSX+Gpj6dYJwoozDAewIb3d+CXQNHDP1u8mn0mhQ5LVw; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.82.46] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IlTXb-0002r0-1x for ietf@ietf.org; Fri, 26 Oct 2007 14:04:15 -0400 Message-ID: <003e01c817fa$b09cfb80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Fri, 26 Oct 2007 11:04:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31a741af127e84cf046fdb1190db5037cd8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.82.46 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi - The existence of IPR claims potentially relevant to the implementation of a specification has never been sufficient grounds to block the publication of that specification as an RFC. Given the unfortunate history of this work, publication of draft-housley-tls-authz-extns as experimental seems to be the most sensible path out of this mess. If the IPR terms are indeed so onerous as to preclude widespread implementation, as seems to be the concern of some, then it will simply gather dust with other "experiments" that didn't work out, and the open source community need not worry. If, on the other hand, this technology is so superior to anything the open source community can offer as an alternative, then Darwin will go to work. None of the recent argumentation has been technical. None of the recent argumentation has provided a convincing procedural reason to block publication of draft-housley-tls-authz-extns. Let's just hand it over to the RFC editor and be done with it. Randy _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 14:22:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTlR-0003ya-70; Fri, 26 Oct 2007 14:18:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTlP-0003yF-JF for ietf@ietf.org; Fri, 26 Oct 2007 14:18:31 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IlTlP-0002yQ-5j for ietf@ietf.org; Fri, 26 Oct 2007 14:18:31 -0400 X-VirusChecked: Checked X-Env-Sender: Chuck.Powers@motorola.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1193422709!18878639!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 31635 invoked from network); 26 Oct 2007 18:18:29 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-9.tower-128.messagelabs.com with SMTP; 26 Oct 2007 18:18:29 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l9QIIO1S006018 for ; Fri, 26 Oct 2007 11:18:29 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l9QIIN6O021605 for ; Fri, 26 Oct 2007 13:18:24 -0500 (CDT) Received: from de01exm69.ds.mot.com (de01exm69.am.mot.com [10.176.8.25]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l9QIIMrw021591 for ; Fri, 26 Oct 2007 13:18:22 -0500 (CDT) 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" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Oct 2007 14:18:21 -0400 Message-ID: <2963ECA56B01F94B9964469DCB8A2B5A042BA904@de01exm69.ds.mot.com> In-Reply-To: <003e01c817fa$b09cfb80$6801a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Experimental makes sense for tls-authz Thread-Index: AcgX+3i1/6+++OtSSVuTa95FA4KRaAAAEcDg From: "Powers Chuck-RXCP20" To: X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: RE: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > Randy Presuhn wrote: >=20 > Hi - >=20 > The existence of IPR claims potentially relevant to the=20 > implementation of a specification has never been sufficient=20 > grounds to block the publication of that specification as an=20 > RFC. Given the unfortunate history of this work, publication=20 > of draft-housley-tls-authz-extns as experimental seems to be=20 > the most sensible path out of this mess. >=20 > If the IPR terms are indeed so onerous as to preclude=20 > widespread implementation, as seems to be the concern of=20 > some, then it will simply gather dust with other=20 > "experiments" that didn't work out, and the open source=20 > community need not worry. If, on the other hand, this=20 > technology is so superior to anything the open source=20 > community can offer as an alternative, then Darwin will go to work. >=20 > None of the recent argumentation has been technical. None of=20 > the recent argumentation has provided a convincing procedural=20 > reason to block publication of draft-housley-tls-authz-extns.=20 > Let's just hand it over to the RFC editor and be done with it. >=20 > Randy +1 If there is a technical reason for opposing the publication of this as an Experimental RFC, please make that argument. Otherwise, lFrom ietf-bounces@ietf.org Fri Oct 26 14:22:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTlR-0003ya-70; Fri, 26 Oct 2007 14:18:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTlP-0003yF-JF for ietf@ietf.org; Fri, 26 Oct 2007 14:18:31 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IlTlP-0002yQ-5j for ietf@ietf.org; Fri, 26 Oct 2007 14:18:31 -0400 X-VirusChecked: Checked X-Env-Sender: Chuck.Powers@motorola.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1193422709!18878639!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 31635 invoked from network); 26 Oct 2007 18:18:29 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-9.tower-128.messagelabs.com with SMTP; 26 Oct 2007 18:18:29 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l9QIIO1S006018 for ; Fri, 26 Oct 2007 11:18:29 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l9QIIN6O021605 for ; Fri, 26 Oct 2007 13:18:24 -0500 (CDT) Received: from de01exm69.ds.mot.com (de01exm69.am.mot.com [10.176.8.25]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l9QIIMrw021591 for ; Fri, 26 Oct 2007 13:18:22 -0500 (CDT) 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" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Oct 2007 14:18:21 -0400 Message-ID: <2963ECA56B01F94B9964469DCB8A2B5A042BA904@de01exm69.ds.mot.com> In-Reply-To: <003e01c817fa$b09cfb80$6801a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Experimental makes sense for tls-authz Thread-Index: AcgX+3i1/6+++OtSSVuTa95FA4KRaAAAEcDg From: "Powers Chuck-RXCP20" To: X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: RE: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > Randy Presuhn wrote: >=20 > Hi - >=20 > The existence of IPR claims potentially relevant to the=20 > implementation of a specification has never been sufficient=20 > grounds to block the publication of that specification as an=20 > RFC. Given the unfortunate history of this work, publication=20 > of draft-housley-tls-authz-extns as experimental seems to be=20 > the most sensible path out of this mess. >=20 > If the IPR terms are indeed so onerous as to preclude=20 > widespread implementation, as seems to be the concern of=20 > some, then it will simply gather dust with other=20 > "experiments" that didn't work out, and the open source=20 > community need not worry. If, on the other hand, this=20 > technology is so superior to anything the open source=20 > community can offer as an alternative, then Darwin will go to work. >=20 > None of the recent argumentation has been technical. None of=20 > the recent argumentation has provided a convincing procedural=20 > reason to block publication of draft-housley-tls-authz-extns.=20 > Let's just hand it over to the RFC editor and be done with it. >=20 > Randy +1 If there is a technical reason for opposing the publication of this as an Experimental RFC, please make that argument. Otherwise, let the Experimental RFC track do what it was designed to do, and determine what interest (if any) there is in this technology in the industry. regards, Chuck _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 14:22:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTjw-0003aC-NZ; Fri, 26 Oct 2007 14:17:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTjv-0003a6-Ke for ietf@ietf.org; Fri, 26 Oct 2007 14:16:59 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlTjv-0002vK-Av for ietf@ietf.org; Fri, 26 Oct 2007 14:16:59 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Oct 2007 11:16:58 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9QIGwwH025683; Fri, 26 Oct 2007 11:16:58 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l9QIGuPd010760; Fri, 26 Oct 2007 18:16:58 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 14:16:39 -0400 Received: from 10.86.115.66 ([10.86.115.66]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) with Microsoft Exchange Server HTTP-DAV ; Fri, 26 Oct 2007 18:16:39 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 26 Oct 2007 14:16:41 -0400 From: Melinda Shore To: Randy Presuhn , Message-ID: Thread-Topic: Experimental makes sense for tls-authz Thread-Index: AcgX/Fs9mhOOBoPvEdyLjQAKleNSdA== In-Reply-To: <003e01c817fa$b09cfb80$6801a8c0@oemcomputer> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Oct 2007 18:16:40.0055 (UTC) FILETIME=[5AAD1870:01C817FC] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15506.002 X-TM-AS-Result: No--10.767800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=269; t=1193422618; x=1194286618; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20 |Subject:=20Re=3A=20Experimental=20makes=20sense=20for=20tls-authz |Sender:=20; bh=n0n6VEQIow3TQ4iyy1IhcQ1kvBJQfsOWMazezFtmHnc=; b=PaEbUUB2FiHxSdTdM398bbHRGZiYNG7n59Rok4MnFOEkT8e+Q82IaH0QP0oyYpBdnbvT4aiS ah6vz7H3YiISBkThc69pPzjv/xXAatavX1NYplKvkdd7RUtlCaJkPtfa; Authentication-Results: sj-dkim-2; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 10/26/07 2:04 PM, "Randy Presuhn" wrote: > Given the unfortunate > history of this work, publication of draft-housley-tls-authz-extns > as experimental seems to be the most sensible path out of this mess. Hear, hear. Melinda _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf et the Experimental RFC track do what it was designed to do, and determine what interest (if any) there is in this technology in the industry. regards, Chuck _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 14:22:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTjw-0003aC-NZ; Fri, 26 Oct 2007 14:17:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTjv-0003a6-Ke for ietf@ietf.org; Fri, 26 Oct 2007 14:16:59 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlTjv-0002vK-Av for ietf@ietf.org; Fri, 26 Oct 2007 14:16:59 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Oct 2007 11:16:58 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9QIGwwH025683; Fri, 26 Oct 2007 11:16:58 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l9QIGuPd010760; Fri, 26 Oct 2007 18:16:58 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 14:16:39 -0400 Received: from 10.86.115.66 ([10.86.115.66]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) with Microsoft Exchange Server HTTP-DAV ; Fri, 26 Oct 2007 18:16:39 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 26 Oct 2007 14:16:41 -0400 From: Melinda Shore To: Randy Presuhn , Message-ID: Thread-Topic: Experimental makes sense for tls-authz Thread-Index: AcgX/Fs9mhOOBoPvEdyLjQAKleNSdA== In-Reply-To: <003e01c817fa$b09cfb80$6801a8c0@oemcomputer> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Oct 2007 18:16:40.0055 (UTC) FILETIME=[5AAD1870:01C817FC] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15506.002 X-TM-AS-Result: No--10.767800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=269; t=1193422618; x=1194286618; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20 |Subject:=20Re=3A=20Experimental=20makes=20sense=20for=20tls-authz |Sender:=20; bh=n0n6VEQIow3TQ4iyy1IhcQ1kvBJQfsOWMazezFtmHnc=; b=PaEbUUB2FiHxSdTdM398bbHRGZiYNG7n59Rok4MnFOEkT8e+Q82IaH0QP0oyYpBdnbvT4aiS ah6vz7H3YiISBkThc69pPzjv/xXAatavX1NYplKvkdd7RUtlCaJkPtfa; Authentication-Results: sj-dkim-2; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 10/26/07 2:04 PM, "Randy Presuhn" wrote: > Given the unfortunate > history of this work, publication of draft-housley-tls-authz-extns > as experimental seems to be the most sensible path out of this mess. Hear, hear. Melinda _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 14:36:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTuM-0000Eh-DI; Fri, 26 Oct 2007 14:27:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTuL-0008Vz-3r for ietf@ietf.org; Fri, 26 Oct 2007 14:27:45 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlTu6-0007YI-2f for ietf@ietf.org; Fri, 26 Oct 2007 14:27:36 -0400 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l9QINbJe010126; Fri, 26 Oct 2007 11:23:37 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Oct 2007 11:26:42 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 26 Oct 2007 11:22:03 -0700 Message-ID: <2788466ED3E31C418E9ACC5C3166155707A4C4@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <0f0001c817ea$f02a0190$6501a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A priori IPR choices Thread-Index: AcgX7M2qyHwVOfUFSGm9h1pZZOYm7AADqVrQ From: "Hallam-Baker, Phillip" To: "Spencer Dawkins" , X-OriginalArrivalTime: 26 Oct 2007 18:26:42.0111 (UTC) FILETIME=[C1878CF0:01C817FD] X-Spam-Score: -4.0 (----) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Subject: RE: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org It is not a major change in principle. But it does have some practical = changes. When we chartered KEYPROV I was told that the IPR regime should not be = in the charter, this was not a concern to me there because all the = proposals were OK IPR wise. But I do want to have the option of the = forcing function in the charter as explained. This is standard in OASIS = and in W3C there is only one regime that the WGs can chose. I do not expect there to be very many charter changes of that type if = any. And if it was going to happen I would expect that it would have = already soaked up a large amount of IESG time. The point about making the statement in the charter is that if people = are going to commit time and resources they have a right to understand = upfront what the IPR is going to be and for this to only change if there = are exceptional circumstances. When we were doing S/MIME and SSL we all = knew about the RSA patent going in. There were no suprises. A WG has to recharter to add stuff to the charter, changing the IPR = regime is a much more serious change in my view. In MARID it was obvious from the start that there was no prospect of an = encumbered technology being adopted. Everyone recognized the fact. The = WG came off the rails because there was not agreement on what the = criteria for being unencumbered were. Another change I am looking for is for the default assumption going = forward to be that the IETF will manage all the mailing lists for WGs = and BOFs and that these will be automatically archived and contain = prominent NOTE WELL notification in their subscription process. A final change I would like to see is less scope for thrashing on this = topic on this list :-) =20 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 > Sent: Friday, October 26, 2007 12:12 PM > To: ietf@ietf.org > Subject: Re: A priori IPR choices >=20 > Hi, Phil, >=20 > I'm not seeing anything in your proposal that requires=20 > changes to the IPR procedures in IETF - are you? >=20 > I AM seeing something in your proposal that could reasonably=20 > be adopted by specific working groups, and I AM seeing=20 > something that might reasonably be developed into an=20 > Informational RFC(*) (heck, maybe even an ION) saying "some=20 > IETF participants worry about X, so we're explicitly pointing=20 > out that IETF working groups can do Y to reduce the chances=20 > of X happening, and here's how to do Y". >=20 > If there's any gap between the tools we have and what you're=20 > suggesting, it's your wish to have this constraint IN THE=20 > WORKING GROUP CHARTER. Is that critical? and if so, is there=20 > any OTHER way to obtain WG consensus and document it, so the=20 > WG doesn't have to keep defending the choice? >=20 > I AM thinking that including IPR constraints in the charter=20 > would set off IESG review for charter changes if the WG=20 > changes its mind - I'm not sure that's helpful, and it's=20 > certainly not required today. >=20 > Thanks, >=20 > Spencer >=20 > (*) The IPR working group has developed Informational RFCs=20 > offered as guidance in the past - I'm sure Phil knows about=20 > http://www.ietf.org/rfc/rfc3669.txt, but others may not have=20 > noticed it. >=20 > From: "Hallam-Baker, Phillip" > To: "Theodore Tso" ; "Norbert Bollow" > Cc: > Sent: Friday, October 26, 2007 9:51 AM > Subject: RE: A priori IPR choices >=20 > The reason I would like to be able to put a RANDZ requirement=20 > in a WG charter is that there are certain areas where I would=20 > like to see a working group form, where there is a set of=20 > clearly unencumbered technology that can be used and=20 > alternative technology that is owned by a proprietary concern. >=20 > I want a WG to be able to make it clear to such rights=20 > holders from the outset that their technology is going to be=20 > stripped from the documents if they fail to deliver=20 > acceptable access terms before the start of last call.=20 >=20 >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 14:54:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlU5y-0001XP-CH; Fri, 26 Oct 2007 14:39:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlU5w-0001QQ-4J for ietf@ietf.org; Fri, 26 Oct 2007 14:39:44 -0400 Received: from robin.verisign.com ([65.205.251.75]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlU5q-0003Zt-LS for ietf@ietf.org; Fri, 26 Oct 2007 14:39:39 -0400 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l9QIaCD8010622; Fri, 26 Oct 2007 11:36:12 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Oct 2007 11:39:16 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 26 Oct 2007 11:35:45 -0700 Message-ID: <2788466ED3E31C418E9ACC5C3166155707A4C9@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <200710190047.59493.pupeno@pupeno.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A pattented standard is not a standard Thread-Index: AcgX+iNZh2JhsCt8Tx2jpTnSOvyrtAAA9vCg From: "Hallam-Baker, Phillip" To: =?UTF-8?B?Si4gUGFibG8gRmVybsOhbmRleg==?= , X-OriginalArrivalTime: 26 Oct 2007 18:39:16.0448 (UTC) FILETIME=[83263E00:01C817FF] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: RE: A pattented standard is not a standard X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2061511749==" Errors-To: ietf-bounces@ietf.org --===============2061511749== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SXMgdGhpcyBhbiBvZmZpY2lhbCBGU0YgY2FtcGFpZ24/DQoNCk15IHBhc3QgZXhwZXJpZW5jZSBp cyB0aGF0IFJNUyBiZWdpbnMgdGhlc2UgY2FtcGFpZ25zIGJlZm9yZSBib3RoZXJpbmcgdG8gZmlu ZCBvdXQgd2hhdCB0aGUgYWN0dWFsIGlzc3VlcyBhcmUuIElmIFJNUyB3YW50cyB0byBpbmZsdWVu Y2UgdGhlIGRlYmF0ZSB0aGVuIGhlIHNob3VsZCBqb2luIHRoZSBkZWJhdGUgaGVyZS4NCg0KSSBh bSBub3QgdmVyeSBpbnRlcmVzdGVkIGluIFJNUydzIG9waW5pb24gb24gYSBzZXQgb2YgY2xhaW1z IGhlIGhhcyBoZWFyZCBzZWNvbmQgaGFuZCBmcm9tIG9uZSBzdXBwb3J0ZXIgd2hpY2ggaGUgdGhl biByZWxheXMgdGhpcmQgaGFuZCB0aHJvdWdoIG90aGVyIHN1cHBvcnRlcnMuDQoNCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKLiBQYWJsbyBGZXJuw6FuZGV6IFttYWls dG86cHVwZW5vQHB1cGVuby5jb21dIA0KPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxOCwgMjAw NyA3OjQ4IFBNDQo+IFRvOiBpZXRmQGlldGYub3JnDQo+IFN1YmplY3Q6IEEgcGF0dGVudGVkIHN0 YW5kYXJkIGlzIG5vdCBhIHN0YW5kYXJkDQo+IA0KPiBIZWxsbywNCj4gDQo+IFRoZSBpZGVhIG9m IGFuIHN0YW5kYXJkIGlzIHRvIG1ha2UgY29tbXVuaWNhdGlvbiBwb3NzaWJsZSBhbmQgDQo+IGVh c3kuIEEgcGF0dGVudGVkIHN0YW5kYXJkIGlzIGEgY2FsbCBmb3IgY2hhb3Mgb3IgYSB0YXggb24g DQo+IGNvbW11bmljYXRpb24uIEknbSB2ZXJ5IG11Y2ggd2l0aCB0aGUgRlNGIGluIG9wcG9zaW5n IFRMUy1hdXRoei4NCj4gDQo+IFRoYW5rIHlvdS4NCj4gLS0NCj4gSi4gUGFibG8gRmVybsOhbmRl eiA8cHVwZW5vQHB1cGVuby5jb20+IChodHRwOi8vcHVwZW5vLmNvbSkNCj4gDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElldGYgbWFpbGluZyBs aXN0DQo+IElldGZAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaWV0Zg0KPiANCg== --===============2061511749== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============2061511749==-- From ietf-bounces@ietf.org Fri Oct 26 15:11:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlURB-0003FI-PL; Fri, 26 Oct 2007 15:01:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlUR9-0003Em-VN for ietf@ietf.org; Fri, 26 Oct 2007 15:01:39 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlUR7-0004F4-M5 for ietf@ietf.org; Fri, 26 Oct 2007 15:01:37 -0400 X-IronPort-AV: E=Sophos;i="4.21,335,1188792000"; d="scan'208";a="74809742" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 26 Oct 2007 15:01:37 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9QJ1bfX012917; Fri, 26 Oct 2007 15:01:37 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9QJ1WdS001513; Fri, 26 Oct 2007 19:01:37 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 15:01:34 -0400 Received: from swbmbp.local.employees.org ([10.86.240.198]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 15:01:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18210.14732.839933.995402@swbmbp.local> Date: Fri, 26 Oct 2007 15:01:32 -0400 From: Scott Brim To: "Hallam-Baker, Phillip" In-Reply-To: <2788466ED3E31C418E9ACC5C3166155707A4C9@mou1wnexmb09.vcorp.ad.vrsn.com> References: <200710190047.59493.pupeno@pupeno.com> <2788466ED3E31C418E9ACC5C3166155707A4C9@mou1wnexmb09.vcorp.ad.vrsn.com> X-Mailer: VM 8.0.3-495 under Emacs 22.1.1 (i386-apple-darwin8.10.1) X-OriginalArrivalTime: 26 Oct 2007 19:01:34.0231 (UTC) FILETIME=[A087BA70:01C81802] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15506.002 X-TM-AS-Result: No--7.909800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Cc: "J. Pablo =?iso-8859-1?Q?Fern=E1ndez?=" , ietf@ietf.org Subject: RE: A pattented standard is not a standard X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 26 Oct 2007 at 11:35 -0700, Hallam-Baker, Phillip allegedly wrote: > Is this an official FSF campaign? Half of them are CCed to fsf-campaign. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 15:11:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlUWU-0007n6-0H; Fri, 26 Oct 2007 15:07:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlUWR-0007hc-Un for ietf@ietf.org; Fri, 26 Oct 2007 15:07:07 -0400 Received: from ns1.qubic.net ([208.78.240.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlUWK-0000Qs-T1 for ietf@ietf.org; Fri, 26 Oct 2007 15:07:07 -0400 Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.2.Beta1/8.14.2.Beta1) with ESMTP id l9QJ6SVd006470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Oct 2007 12:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=À; t=1193425603; x=1193512003; bh=8LmdLq/cVG7tHVbBZCuEBnTDvY3JGAPnV5IS MNB7QKU=; h=DomainKey-Signature:Message-Id:X-Mailer:Date:To:From: Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type; b=bKs NVtlQdQ7iLR1ZezFMIVn918SCd0bM0yqc4qCyA2x1inVMOsL/VEviSmr8y5f1QFoSVj 0YeKlGLemKeLfbFb7EnueZN29hiWMeSQEHEzDMQ79KWNaKOT378+HWPrJeNamK6gP7F P6ZaaFbjQLvb8RX/Li8mrAeZqYlhJRqzUQ= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=kENmdatYW22tpsSpBfwgeh4E6/vk8Ekro5zumg99JpPIWl4ZnLfcuKRCIZLJUNU7m xO2QU3CTgKNVaqqhv8PiJMUK3JDIz730q+XKJXk0IDEyNr942H8kvP838i1mPwdSM9U DpWGtnGxFMDafIfN6knKVJgMQZUZ6Om3VYwj234= Message-Id: <6.2.5.6.2.20071026113306.030c89a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 26 Oct 2007 12:06:17 -0700 To: ietf@ietf.org From: SM In-Reply-To: <20071026081346.8460D22024E@quill.bollow.ch> References: <007001c8165f$a6007090$6401a8c0@LROSENTOSHIBA> <471FC008.7070901@gmail.com> <20071025153346.GC22103@thunk.org> <20071025160042.C8E8F22024E@quill.bollow.ch> <20071025163925.GA6456@thunk.org> <20071025170954.72B2422024E@quill.bollow.ch> <472100F6.50200@gmail.com> <20071026081346.8460D22024E@quill.bollow.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 01:13 26-10-2007, Norbert Bollow wrote: >The question is this: Is copyleft open source / free software so >unimportant with regard to any area of internet standards that it >would be justifiable to adopt any specification with fundamentally >incompatible patent situation as a standards-track RFC? The better question would be: Are Internet standards so unimportant that copyleft open source /free software developers don't participate in the process? Letter-writing campaigns may not be the best way to influence the process (see RedPhone incident). Patents do raise some concerns about interoperability in regards to open source/free software. From a technical point of view, there is nothing that prevents implementation if the specifications are available. But then, we are taking a narrowed view of interoperability. Regards, -sm _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 15:23:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlUfX-0000tN-Ge; Fri, 26 Oct 2007 15:16:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlUfV-0000p6-1e for ietf@ietf.org; Fri, 26 Oct 2007 15:16:29 -0400 Received: from bender-mail.tigertech.net ([64.62.209.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlUfO-0000kk-QS for ietf@ietf.org; Fri, 26 Oct 2007 15:16:29 -0400 Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id 079517E16 for ; Fri, 26 Oct 2007 12:16:13 -0700 (PDT) Received: from JMHLap3.joelhalpern.com (pool-162-84-109-161.culp.east.verizon.net [162.84.109.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id C65F27E13 for ; Fri, 26 Oct 2007 12:16:11 -0700 (PDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 26 Oct 2007 15:16:07 -0400 To: From: "Joel M. Halpern" In-Reply-To: <003e01c817fa$b09cfb80$6801a8c0@oemcomputer> References: <003e01c817fa$b09cfb80$6801a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20071026191611.C65F27E13@bender.tigertech.net> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on bender.tigertech.net X-Spam-Status: No, hits=4.3 tagged_above=-999.0 required=7.0 tests=MSGID_FROM_MTA_ID, RCVD_IN_SORBS_DUL, SPF_NEUTRAL X-Spam-Level: **** X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Given the current email activity on this issue, I want to echo Randy's support. We have published encumbered experimental and informational documents on many occasions. I can see no reason not to do so in this case. Given that it appears that experimental publication is sufficient for the registration needs that go with this document, I strongly support publication. Yours, Joel M. Halpern At 02:04 PM 10/26/2007, Randy Presuhn wrote: >Hi - > >The existence of IPR claims potentially relevant to the implementation >of a specification has never been sufficient grounds to block the >publication of that specification as an RFC. Given the unfortunate >history of this work, publication of draft-housley-tls-authz-extns >as experimental seems to be the most sensible path out of this mess. > >If the IPR terms are indeed so onerous as to preclude widespread >implementation, as seems to be the concern of some, then it will >simply gather dust with other "experiments" that didn't work out, >and the open source community need not worry. If, on the other >hand, this technology is so superior to anything the open source >community can offer as an alternative, then Darwin will go to work. > >None of the recent argumentation has been technical. None of the >recent argumentation has provided a convincing procedural reason >to block publication of draft-housley-tls-authz-extns. Let's just >hand it over to the RFC editor and be done with it. > >Randy > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 15:43:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlUvI-0002Ae-6i; Fri, 26 Oct 2007 15:32:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlUvG-0002AZ-Ud for ietf@ietf.org; Fri, 26 Oct 2007 15:32:46 -0400 Received: from rv-out-0910.google.com ([209.85.198.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlUvA-0001Kb-OV for ietf@ietf.org; Fri, 26 Oct 2007 15:32:46 -0400 Received: by rv-out-0910.google.com with SMTP id l15so789916rvb for ; Fri, 26 Oct 2007 12:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=jIgfTsydtNGqWVpg+p9IVkBWrBP/TdQPChUJy85eZng=; b=U91Y6rgNZn+RrTPP3aJbE6tBXItBzGIowKl9Z5UO42Z6W73kXAQBrmYLPJYpVo3lmc1Qnve5iniA7/Q8KnQJrDEC/aARrCsm3BZnxa4D4hJqo6FRqrQeiKR41wBOGWUekoL4bFnp7dzi7AkJC85zEUAXjvGI0Lgo5ZrfrTlCyME= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=rrX+NE8CSxKUuXFHgLWCXJxmjKydCSIg4K5mctfxcZWmej/vz4GqOsdg0AC/bwpwXwkdnS6PfHRFGl6NUaJUfrsSGM+c1yk/mJzmxJLk0YGaE/8snvN3Wt848yOGouiTfPXvd++oQR0dTRZpsVvjn40ntZHdBhuntmHsGZyV8XE= Received: by 10.141.202.12 with SMTP id e12mr1719161rvq.1193427142418; Fri, 26 Oct 2007 12:32:22 -0700 (PDT) Received: from ?10.1.1.7? ( [222.153.14.113]) by mx.google.com with ESMTPS id b2sm6262772rvf.2007.10.26.12.32.20 (version=SSLv3 cipher=RC4-MD5); Fri, 26 Oct 2007 12:32:21 -0700 (PDT) Message-ID: <472240BB.4020904@gmail.com> Date: Sat, 27 Oct 2007 08:32:11 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Presuhn References: <003e01c817fa$b09cfb80$6801a8c0@oemcomputer> In-Reply-To: <003e01c817fa$b09cfb80$6801a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ietf@ietf.org Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-27 07:04, Randy Presuhn wrote: > Hi - > > The existence of IPR claims potentially relevant to the implementation > of a specification has never been sufficient grounds to block the > publication of that specification as an RFC. Given the unfortunate > history of this work, publication of draft-housley-tls-authz-extns > as experimental seems to be the most sensible path out of this mess. I agree. The DOS attack on this list seems to be from people who haven't read RFC 2026 and use meaningless phrases like "experimental standard." In fact, publishing this as an experiment to see if it gets implemented and deployed despite the IPR issue seems like *exactly* the right thing to do. Brian > > If the IPR terms are indeed so onerous as to preclude widespread > implementation, as seems to be the concern of some, then it will > simply gather dust with other "experiments" that didn't work out, > and the open source community need not worry. If, on the other > hand, this technology is so superior to anything the open source > community can offer as an alternative, then Darwin will go to work. > > None of the recent argumentation has been technical. None of the > recent argumentation has provided a convincing procedural reason > to block publication of draft-housley-tls-authz-extns. Let's just > hand it over to the RFC editor and be done with it. > > Randy > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 15:58:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlV69-0002wy-9n; Fri, 26 Oct 2007 15:44:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlV67-0002qa-LZ for ietf@ietf.org; Fri, 26 Oct 2007 15:43:59 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlV5w-0001gs-AV for ietf@ietf.org; Fri, 26 Oct 2007 15:43:54 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IlV5g-0001xr-QH for ietf@ietf.org; Fri, 26 Oct 2007 19:43:32 +0000 Received: from 1cust187.tnt3.hbg2.deu.da.uu.net ([149.225.14.187]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Oct 2007 19:43:32 +0000 Received: from nobody by 1cust187.tnt3.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Oct 2007 19:43:32 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: "Frank Ellermann" Date: Fri, 26 Oct 2007 21:41:03 +0200 Organization: http://purl.net/xyzzy Lines: 20 Message-ID: References: <20071018193104.GD2537@always.joy.eth.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 1cust187.tnt3.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: Megatron (was: TLS-authz) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Apparently Megatron put a bunch of messages on hold for eight days, compare : | Original-Received: from [127.0.0.1] = (helo=3Dstiedprmman1.va.neustar.com) | by megatron.ietf.org with esmtp (Exim 4.43) | id 1IlT12-0002lZ-Jq; Fri, 26 Oct 2007 13:30:36 -0400 | Original-Received: from [10.90.34.44] (helo=3Dchiedprmail1.ietf.org) | by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiaz1-0005pF-56 | for ietf@ietf.org; Thu, 18 Oct 2007 15:24:39 -0400 | Original-Received: from sceptre.pobox.com ([207.106.133.20]) | by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iiayl-0006I3-OX | for ietf@ietf.org; Thu, 18 Oct 2007 15:24:24 -0400 As far as I can see it only Peter noted that something's wrong... ...and solved it by simply trying again after about twelve hours: Frank _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 16:09:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlVLl-00067A-Vq; Fri, 26 Oct 2007 16:00:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlVLk-0005w2-Gu for ietf@ietf.org; Fri, 26 Oct 2007 16:00:08 -0400 Received: from mailout00.controlledmail.com ([72.81.252.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlVLk-0005r5-7n for ietf@ietf.org; Fri, 26 Oct 2007 16:00:08 -0400 Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id DC95E5CC0EF for ; Fri, 26 Oct 2007 20:00:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1193428807; bh=c7AUWT8gMEFildhNefEka66YOWHGvz7lFwoXOqV aDvw=; h=Received:From:Organization:To:Subject:Date:User-Agent: References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-Disposition:Message-Id: X-AV-Checked; b=IgxsnIQYM9hte9lsoRVPGONvdoG6L4Rl6UvAsvnmN8oxyDhtHb e27QktuEsmpmw/r4g46H3yU/gHaiQ7ov4FsisDES7+4IXMHVJ3m3iuZBBMHOi5tHyOM i/1rim9X3GDcQpRbv1MlfazMnY+YhobYQiFnMwezqf/PxtGQQ06hnA= Received: from [192.168.111.102] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by mailout00.controlledmail.com (Postfix) with ESMTP id C8BA95CC08D for ; Fri, 26 Oct 2007 20:00:07 +0000 (UTC) From: Scott Kitterman Organization: Kitterman Technical Services To: ietf@ietf.org Date: Fri, 26 Oct 2007 16:00:04 -0400 User-Agent: KMail/1.9.5 References: <003e01c817fa$b09cfb80$6801a8c0@oemcomputer> <472240BB.4020904@gmail.com> In-Reply-To: <472240BB.4020904@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710261600.05678.scott@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Friday 26 October 2007 15:32, Brian E Carpenter wrote: > On 2007-10-27 07:04, Randy Presuhn wrote: > > Hi - > > > > The existence of IPR claims potentially relevant to the implementation > > of a specification has never been sufficient grounds to block the > > publication of that specification as an RFC. Given the unfortunate > > history of this work, publication of draft-housley-tls-authz-extns > > as experimental seems to be the most sensible path out of this mess. > > I agree. The DOS attack on this list seems to be from people > who haven't read RFC 2026 and use meaningless phrases like > "experimental standard." In fact, publishing this as an experiment > to see if it gets implemented and deployed despite the IPR issue > seems like *exactly* the right thing to do. Just make sure you aren't running an experiment on the results of ignoring the IETF rules not having signficant consuequences. Scott K _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 16:41:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlVnI-0004Y7-KA; Fri, 26 Oct 2007 16:28:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlVnH-0004Sx-BK for ietf@ietf.org; Fri, 26 Oct 2007 16:28:35 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlVn4-00036m-A9 for ietf@ietf.org; Fri, 26 Oct 2007 16:28:23 -0400 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l9QKOCqM005150; Fri, 26 Oct 2007 13:24:12 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Oct 2007 21:27:45 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 26 Oct 2007 13:27:07 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557084F1C@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Experimental makes sense for tls-authz Thread-Index: AcgYDEnGyfXxOm8uQqmWxl5EJgWtggAAkqWF References: <003e01c817fa$b09cfb80$6801a8c0@oemcomputer><472240BB.4020904@gmail.com> <200710261600.05678.scott@kitterman.com> From: "Hallam-Baker, Phillip" To: "Scott Kitterman" , X-OriginalArrivalTime: 26 Oct 2007 20:27:45.0566 (UTC) FILETIME=[AAE2D3E0:01C8180E] X-Spam-Score: -2.2 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Subject: RE: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1966379782==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============1966379782== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8180E.A9E00CAF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8180E.A9E00CAF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Perhaps the experiement is to see if the purported IPR is enforceable. ________________________________ From: Scott Kitterman [mailto:scott@kitterman.com] Sent: Fri 26/10/2007 4:00 PM To: ietf@ietf.org Subject: Re: Experimental makes sense for tls-authz On Friday 26 October 2007 15:32, Brian E Carpenter wrote: > On 2007-10-27 07:04, Randy Presuhn wrote: > > Hi - > > > > The existence of IPR claims potentially relevant to the = implementation > > of a specification has never been sufficient grounds to block the > > publication of that specification as an RFC. Given the unfortunate > > history of this work, publication of draft-housley-tls-authz-extns > > as experimental seems to be the most sensible path out of this mess. > > I agree. The DOS attack on this list seems to be from people > who haven't read RFC 2026 and use meaningless phrases like > "experimental standard." In fact, publishing this as an experiment > to see if it gets implemented and deployed despite the IPR issue > seems like *exactly* the right thing to do. Just make sure you aren't running an experiment on the results of = ignoring the IETF rules not having signficant consuequences. Scott K _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ------_=_NextPart_001_01C8180E.A9E00CAF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Experimental makes sense for = tls-authz=0A= =0A= =0A= =0A=
=0A=
Perhaps the = experiement is to see if the purported IPR is = enforceable.
=0A=

=0A=
=0A= From: Scott Kitterman = [mailto:scott@kitterman.com]
Sent: Fri 26/10/2007 4:00 = PM
To: ietf@ietf.org
Subject: Re: Experimental makes = sense for tls-authz

=0A=
=0A=

On Friday 26 October 2007 15:32, Brian E Carpenter = wrote:
> On 2007-10-27 07:04, Randy Presuhn wrote:
> > Hi = -
> >
> > The existence of IPR claims potentially = relevant to the implementation
> > of a specification has never = been sufficient grounds to block the
> > publication of that = specification as an RFC.  Given the unfortunate
> > = history of this work, publication of = draft-housley-tls-authz-extns
> > as experimental seems to be = the most sensible path out of this mess.
>
> I agree. The = DOS attack on this list seems to be from people
> who haven't read = RFC 2026 and use meaningless phrases like
> "experimental = standard." In fact, publishing this as an experiment
> to see if = it gets implemented and deployed despite the IPR issue
> seems = like *exactly* the right thing to do.

Just make sure you aren't = running an experiment on the results of ignoring the
IETF rules not = having signficant consuequences.

Scott = K

_______________________________________________
Ietf mailing = list
Ietf@ietf.org
https://www1.ietf.or= g/mailman/listinfo/ietf

------_=_NextPart_001_01C8180E.A9E00CAF-- --===============1966379782== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============1966379782==-- From ietf-bounces@ietf.org Fri Oct 26 16:41:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlVtv-0007kH-CN; Fri, 26 Oct 2007 16:35:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlVtb-0007Q9-Ae for ietf@ietf.org; Fri, 26 Oct 2007 16:35:07 -0400 Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlVtQ-0003I9-2n for ietf@ietf.org; Fri, 26 Oct 2007 16:35:02 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MMZBC0IL9C00F222@mauve.mrochek.com> for ietf@ietf.org; Fri, 26 Oct 2007 13:34:34 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MMZ8Q24JRK003GRV@mauve.mrochek.com>; Fri, 26 Oct 2007 13:34:32 -0700 (PDT) Message-id: <01MMZBBZGZTI003GRV@mauve.mrochek.com> Date: Fri, 26 Oct 2007 13:34:19 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 26 Oct 2007 15:16:07 -0400" <20071026191611.C65F27E13@bender.tigertech.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <003e01c817fa$b09cfb80$6801a8c0@oemcomputer> <20071026191611.C65F27E13@bender.tigertech.net> To: Joel M Halpern DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1193430874; h=Date: From:Subject:MIME-version:Content-type; b=Mf1loWLJkaHH3Q7Bty+AqSliW 2ral+GVbpweDEe1VCVGKySC6xSxowEuoPakNWa5vi7t9I/0Uv0W1Gro48McUw== X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ietf@ietf.org Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > Given the current email activity on this issue, I want to echo Randy's support. > We have published encumbered experimental and informational documents > on many occasions. I can see no reason not to do so in this > case. Given that it appears that experimental publication is > sufficient for the registration needs that go with this document, I > strongly support publication. +1 Ned _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 17:24:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlWNF-00031c-AG; Fri, 26 Oct 2007 17:05:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlWND-0002yd-62 for ietf@ietf.org; Fri, 26 Oct 2007 17:05:43 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlWN8-0007eV-TC for ietf@ietf.org; Fri, 26 Oct 2007 17:05:39 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 6D71E872CA; Fri, 26 Oct 2007 17:05:38 -0400 (EDT) To: ietf@ietf.org Message-Id: <20071026210538.6D71E872CA@mercury.lcs.mit.edu> Date: Fri, 26 Oct 2007 17:05:38 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: jnc@mercury.lcs.mit.edu Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > From: "Joel M. Halpern" > We have published encumbered experimental and informational documents > on many occasions. I can see no reason not to do so in this case. Given > that it appears that experimental publication is sufficient for the > registration needs that go with this document, I strongly support > publication. I concur - and I think this is the action we should take, no matter how many emails we see from people we've never heard from before (and probably never will again). Noel _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 17:27:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlWdW-0008Cs-V2; Fri, 26 Oct 2007 17:22:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlWdT-000875-RH; Fri, 26 Oct 2007 17:22:31 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlWdI-0004qz-Jf; Fri, 26 Oct 2007 17:22:26 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQJ00EIJFCIOO@usaga01-in.huawei.com>; Fri, 26 Oct 2007 14:21:54 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JQJ00H3QFCFN0@usaga01-in.huawei.com>; Fri, 26 Oct 2007 14:21:54 -0700 (PDT) Date: Fri, 26 Oct 2007 16:21:00 -0500 From: Spencer Dawkins To: Luca Barbato Message-id: <10cb01c81816$1bb34620$6501a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 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-Spam-Score: 0.0 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Cc: ext Cullen Jennings , General Area Review Team , draft-ietf-avt-rtp-vorbis@tools.ietf.org, avt-chairs@tools.ietf.org, ietf@ietf.org Subject: Gen-ART Last Call review of draft-ietf-avt-rtp-vorbis-06 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi, Luca, I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Thanks, Spencer Document: draft-ietf-avt-rtp-vorbis-06 Reviewer: Spencer Dawkins Review Date: 26 Oct 2007 (sorry, late!) IETF LC End Date: 22 Oct 2007 IESG Telechat date: Summary: This document is close to ready for publication as a Proposed Standard. I have a small number of questions, mostly involving clarity or 2119 language. Please take a look at the question in 7.1, especially. Comments: I have included "nits" in this review for the convenience of authors and editors later in the process. Nits are not part of a Gen-ART review. 1. Introduction Vorbis is a general purpose perceptual audio codec intended to allow maximum encoder flexibility, thus allowing it to scale competitively over an exceptionally wide range of bitrates. At the high quality/ bitrate end of the scale (CD or DAT rate stereo, 16/24 bits), it is in the same league as AAC. Vorbis is also intended for lower and Spencer (nit): AAC? has not been expanded previously. higher sample rates (from 8kHz telephony to 192kHz digital masters) and a range of channel representations (monaural, polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to 255 discrete channels). 2.2. Payload Header Vorbis Data Type (VDT): 2 bits This field specifies the kind of Vorbis data stored in this RTP packet. There are currently three different types of Vorbis payloads. Each packet MUST contain only a single type of Vorbis payload (e.g. you MUST not aggregate configuration and comment Spencer: this is close to a nit, but 2119 language is important. This is just restating the previous MUST. I'd suggest either "must" in lower case or "MUST NOT" - if there's a reason to have two 2119 requirements that say the same thing. payload in the same packet) 0 = Raw Vorbis payload 1 = Vorbis Packed Configuration payload 2 = Legacy Vorbis Comment payload 3 = Reserved The packets with a VDT of value 3 MUST be ignored The last 4 bits represent the number of complete packets in this payload. This provides for a maximum number of 15 Vorbis packets in the payload. If the packet contains fragmented data the number of packets MUST be set to 0. Spencer (nit): what type of fragmentation is this? Please provide an adjective :-) 2.3. Payload Data The Vorbis packet length header is the length of the Vorbis data block only and does not count the length field. Spencer (nit): s/count/include/, I think. The payload packing of the Vorbis data packets MUST follow the guidelines set-out in [3] where the oldest packet occurs immediately Spencer: again, adjectives are good. This is saying "the oldest Vorbis packet", right? It would be better if the specification doesn't use language like "the oldest packet in the packet" with no adjectives - that doesn't take us to a good place. after the RTP packet header. Subsequent packets, if any, MUST follow in temporal order. Spencer: "Subsequent Vorbis packets", right? what does the receiver do if the "follow in temporal order" MUST is violated? 3.1.1. Packed Configuration A Vorbis Packed Configuration is indicated with the Vorbis Data Type field set to 1. Of the three headers defined in the Vorbis I specification [10], the identification and the setup MUST be packed as they are, while the comment header MAY be replaced with a dummy one. The packed configuration follows a generic way to store xiph codec configurations: The first field stores the number of the following packets minus one (count field), the next ones represent the size of the headers (length fields), the headers immediately follow the list of length fields. The size of the last header is implicit. The count and the length fields are encoded using the following logic: the data is in network order, every byte has the Spencer (nit): c/network order/network byte order/, and there are multiple occurrences in the document... most significant bit used as flag and the following 7 used to store the value. The first N bit are to be taken, where N is number of bits representing the value modulo 7, and stored in the first byte. If there are more bits, the flag bit is set to 1 and the subsequent 7bit are stored in the following byte, if there are remaining bits set the flag to 1 and the same procedure is repeated. The ending byte has the flag bit set to 0. In order to decode it is enough to iterate over the bytes until the flag bit set to 0, for every byte the data is added to the accumulated value multiplied by 128. The headers are packed in the same order they are present in ogg: identification, comment, setup. 3.2. Out of Band Transmission This section, as stated above, does not cover all the possible out- of-band delivery methods since they rely on different protocols and are linked to specific applications. The following packet definition SHOULD be used in out-of-band delivery and MUST be used when Spencer: is there an obvious reason to violate the SHOULD? Configuration is inlined in the SDP. 5.1. Example Fragmented Vorbis Packet The Fragment type field is set to 2 and the number of packets field is set to 0. For large Vorbis fragments there can be several of these type of payload packets. The maximum packet size SHOULD be no Spencer (nit): s/these type/this type/? Spencer: why is this a SHOULD? greater than the path MTU, including all RTP and payload headers. The sequence number has been incremented by one but the timestamp field remains the same as the initial packet. 5.2. Packet Loss As there is no error correction within the Vorbis stream, packet loss will result in a loss of signal. Packet loss is more of an issue for fragmented Vorbis packets as the client will have to cope with the handling of the Fragment Type. In case of loss of fragments the client MUST discard all the remaining fragments and decode the Spencer (nit) - "remaining Vorbis fragments" and "incomplete Vorbis packet"? incomplete packet. If we use the fragmented Vorbis packet example above and the first packet is lost the client MUST detect that the Spencer (nit) - "and the first RTP packet is lost"? next packet has the packet count field set to 0 and the Fragment type 2 and MUST drop it. The next packet, which is the final fragmented packet, MUST be dropped in the same manner. If the missing packet is the last, the received two fragments will be kept and the incomplete vorbis packet decoded. 6. IANA Considerations configuration-uri: the URI [4] of the configuration headers in case of out of band transmission. In the form of "protocol://path/to/resource/", depending on the specific Spencer: isn't this "scheme://path/to/resource"? method, a single configuration packet could be retrived by its Ident number, or multiple packets could be aggregated in a single stream. Non hierarchical protocols MAY point to a resource using their specific syntax. 7.1. Mapping Media Type Parameters into SDP The information carried in the Media Type media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [5], which is commonly used to describe RTP sessions. When SDP is used to specify sessions the mapping are as follows: Spencer: is there anything you can say about Receiver behavior when the Media Type and SDP don't map correctly? 7.1.1. SDP Example The following example shows a basic SDP single stream. The first configuration packet is inlined in the sdp, other configurations Spencer (nit): it would be great if SDP, URI etc. were consistently capitalized. could be fetched at any time from the first provided uri using or all Spencer: is this "the URI currently in use"? but the sentence doesn't parse as written. the known configuration could be downloaded using the second uri. The inline base64 [9] configuration string is trimmed because of the Spencer: is this "is folded in this example due to RFC line length limitations"? length. c=IN IP4 192.0.2.1 m=audio RTP/AVP 98 a=rtpmap:98 vorbis/44100/2 a=fmtp:98 delivery-method=inline; configuration=AAAAAZ2f4g9NAh4aAXZvcmJpcwA...; delivery- method=out_band; configuration-uri=rtsp://path/to/the/resource; delivery-method=out_band; configuration-uri=http://another/path/to/resource/; Note that the payload format (encoding) names are commonly shown in upper case. Media Type subtypes are commonly shown in lower case. These names are case-insensitive in both places. Similarly, parameter names are case-insensitive both in Media Type types and in the default mapping to the SDP a=fmtp attribute. The exception regarding case sensitivity is the configuration-uri URI which MUST be regarded as being case sensitive. The a=fmtp line is a single line Spencer: "shown as multiple lines in this document for clarity"? even if it is presented broken because of clarity. 7.2. Usage with the SDP Offer/Answer Model The only paramenter negotiable is the delivery method. All the Spencer (nit): c/paramenter negotiable/negotiable parameter/ others are declarative: the offer, as described in An Offer/Answer Model Session Description Protocol [8], may contain a large number of delivery methods per single fmtp attribute, the answerer MUST remove every delivery-method and configuration-uri not supported. All the parameters MUST not be altered on answer otherwise. 8. Congestion Control Vorbis clients SHOULD send regular receiver reports detailing Spencer: is there a well-understood definition of "regular" within this community? congestion. A mechanism for dynamically downgrading the stream, known as bitrate peeling, will allow for a graceful backing off of the stream bitrate. This feature is not available at present so an alternative would be to redirect the client to a lower bitrate stream if one is available. 9.1. Stream Radio This is one of the most common situation: one single server streaming content in multicast, the clients may start a session at random time. The content itself could be a mix of live stream, as the wj's voice, Spencer (nit): "wj's"? please spell this out (I'm guessing what this means) and stored streams as the music she plays. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 18:12:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlXBk-00076S-Nw; Fri, 26 Oct 2007 17:57:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlXBi-0006yQ-Hd for ietf@ietf.org; Fri, 26 Oct 2007 17:57:54 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlXBY-0006GC-AT for ietf@ietf.org; Fri, 26 Oct 2007 17:57:50 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IlXBE-0004Kj-56 for ietf@ietf.org; Fri, 26 Oct 2007 21:57:24 +0000 Received: from 1cust187.tnt3.hbg2.deu.da.uu.net ([149.225.14.187]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Oct 2007 21:57:24 +0000 Received: from nobody by 1cust187.tnt3.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Oct 2007 21:57:24 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: "Frank Ellermann" Date: Fri, 26 Oct 2007 23:57:11 +0200 Organization: http://purl.net/xyzzy Lines: 23 Message-ID: References: <003e01c817fa$b09cfb80$6801a8c0@oemcomputer> <472240BB.4020904@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 1cust187.tnt3.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: DOS (was: Experimental makes sense for tls-authz) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Brian E Carpenter wrote: > The DOS attack on this list seems to be from people who haven't > read RFC 2026 and use meaningless phrases like "experimental > standard." What was it, 30 messages collected by Megatron over eight days ? FYI 36 offers a definition for "denial of service". Of course some messages about a "standard on experimental track" or similar kind of miss the point. As a "campaign" it reminded me of the weird "yes, we will deploy sender-id" parade in MARID. Other messages were perfectly on topic, apparently from concerned folks. I agree with the drift in the rest of your message, but of course I won't say anything about the specific I-D in an IETF Last Call, for starters I didn't read it. =20 OTOH I also agree with the drift of pages like , that includes a case where "attack" would be putting it mildly. Frank _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 18:26:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlXRW-0004JR-Gp; Fri, 26 Oct 2007 18:14:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlXRU-0004Bc-Kf for ietf@ietf.org; Fri, 26 Oct 2007 18:14:12 -0400 Received: from mho-01-bos.mailhop.org ([63.208.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlXRH-0006nP-Eo for ietf@ietf.org; Fri, 26 Oct 2007 18:14:05 -0400 Received: from c-71-197-208-131.hsd1.or.comcast.net ([71.197.208.131] helo=internaut.com) by mho-01-bos.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1IlXQw-0006tg-S6 for ietf@ietf.org; Fri, 26 Oct 2007 22:13:39 +0000 Received: by internaut.com (Postfix, from userid 1000) id 062D382964; Fri, 26 Oct 2007 15:13:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id EB1B2828FF for ; Fri, 26 Oct 2007 15:13:37 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.197.208.131 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18kKTYfHn88rTr5sjGx71gs Date: Fri, 26 Oct 2007 15:13:37 -0700 (PDT) From: Bernard Aboba To: ietf@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > I agree. The DOS attack on this list seems to be from people > who haven't read RFC 2026 and use meaningless phrases like > "experimental standard." In fact, publishing this as an experiment > to see if it gets implemented and deployed despite the IPR issue > seems like *exactly* the right thing to do. I agree that experimental status is the right thing here, but I am not clear that this determination is being made consistently. If one judges by the level of encumbrance, maturity, etc. then this specification is actually in much better shape than other specifications that been approved as Proposed Standard, some not too long ago. So, the question is whether the IETF has some kind of process and procedure by which to make these decisions -- or whether we just allow decisions to be made based on whether a particular specification gets on people's radar screen and "interpretation" of the resulting emails by the IESG. With respect to judging whether a particular set of emails constitutes a DoS attack or an expression of the will of the IETF community -- RFC 2026 doesn't impose a "poll tax" on posters, requiring that they demonstrate knowledge of IETF process to express their opinions. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 20:06:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlZ1X-0002Z4-HN; Fri, 26 Oct 2007 19:55:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlZ1V-0002WC-1p for ietf@ietf.org; Fri, 26 Oct 2007 19:55:29 -0400 Received: from rv-out-0910.google.com ([209.85.198.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlZ1O-0001CQ-Ro for ietf@ietf.org; Fri, 26 Oct 2007 19:55:29 -0400 Received: by rv-out-0910.google.com with SMTP id l15so838123rvb for ; Fri, 26 Oct 2007 16:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=faPI0zSfveMc3+ebWJL9kr3BuoBfrFO8ST94mzWDuhs=; b=t+Jau6rkTHnMbNtR4ak8pBZDgFwxEOpl2bmOp/4CW6LN3rX5MeeQ2r/cRfEg4OZ6FFBWYTOtQi5Uu9qiqA1eTNnaetqRf5lFRer1mIUVHs5UoaFngJi5IFweky0WViuJgAURfzm4diZ4/sfS/8QmN5+MzO9vsSejr/aCCwj4XDA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=jvlI9Jd8o5s6SbEjjMxOEvW6boSr/fdzcNyND3aj6leIwrIYe4j0xg5o6GoOaFJTVZk9dg6FOOvivJL3ZLWPdlRFLlw+YgpNIdJo48qgQaxbX1NNuyy55y0LTEe3VlqWKKk9JfBt59HT9rzbfRIRDbHpMFFfS8BCcjeBpoeeUNM= Received: by 10.141.171.6 with SMTP id y6mr1810490rvo.1193442912117; Fri, 26 Oct 2007 16:55:12 -0700 (PDT) Received: from ?10.1.1.7? ( [222.153.14.113]) by mx.google.com with ESMTPS id l27sm6604177rvb.2007.10.26.16.55.10 (version=SSLv3 cipher=RC4-MD5); Fri, 26 Oct 2007 16:55:11 -0700 (PDT) Message-ID: <47227E5A.9090207@gmail.com> Date: Sat, 27 Oct 2007 12:55:06 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ietf@ietf.org Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-27 11:13, Bernard Aboba wrote: >> I agree. The DOS attack on this list seems to be from people >> who haven't read RFC 2026 and use meaningless phrases like >> "experimental standard." In fact, publishing this as an experiment >> to see if it gets implemented and deployed despite the IPR issue >> seems like *exactly* the right thing to do. > > I agree that experimental status is the right thing here, but I > am not clear that this determination is being made consistently. > > If one judges by the level of encumbrance, maturity, etc. then this > specification is actually in much better shape than other specifications > that been approved as Proposed Standard, some not too long ago. > > So, the question is whether the IETF has some kind of process and > procedure by which to make these decisions -- or whether we just allow > decisions to be made based on whether a particular > specification gets on people's radar screen and "interpretation" of the > resulting emails by the IESG. Actually, yes, we do leave the IESG to make the judgement, subject to appeal to the IAB. I also think it's reasonably clear that the IESG is allowed to recognize that "circumstances alter cases" rather than to automatically follow precedents. But that's certainly a matter of interpretation. > With respect to judging whether a particular set of emails > constitutes a DoS attack or an expression of the will of the IETF > community -- RFC 2026 doesn't impose a "poll tax" on posters, requiring > that they demonstrate knowledge of IETF process to express their opinions. That's quite correct. But when judging the rough consensus of the IETF, I believe that the IESG is fully entitled to consider whether multiple similar messages from people who have rarely if ever participated in IETF activities carry as much weight as messages from active participants. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 20:06:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlYs6-0005mc-4v; Fri, 26 Oct 2007 19:45:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlYs4-0005lr-Hj for ietf@ietf.org; Fri, 26 Oct 2007 19:45:44 -0400 Received: from rv-out-0910.google.com ([209.85.198.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlYru-0000w7-Ax for ietf@ietf.org; Fri, 26 Oct 2007 19:45:40 -0400 Received: by rv-out-0910.google.com with SMTP id l15so836408rvb for ; Fri, 26 Oct 2007 16:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=gIWD1TdaOY0W7lk6PFeTQwA/XL0BBeVfp/3+Qv5cJWY=; b=r4JZ+wvoLoqUdnVt26O5tdxKHk6vF1XD5uHQPI5PrQHiY2aMIHPZtD+8B/JX6vwSB04/K0NYmIoDGlJyQboKppNdTQXgiN0w2XW+ZlPcM23YqtdRCyYAaknXu3l8TPutInzPLvLy7N8qZxfSNwCxRZfggtmcZLWzydVCiwelVrM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=gd5Nm9naUZvq6u0bvS+vrkUeWk60q/vkLIb3GquHsc4JwSQpzVSOrEDmZVmWmkB4SX6DqOlNOTPX0IpIKeqhHm5NW17bOpED4/b/Eh60SldW+5QGSARehLY9Nw0IpeEDYsb+4IbXdLIZX+qRaSSSpDR4pF/lURA2eKWsQV2jRQM= Received: by 10.140.250.14 with SMTP id x14mr1811267rvh.1193442271238; Fri, 26 Oct 2007 16:44:31 -0700 (PDT) Received: from ?10.1.1.7? ( [222.153.14.113]) by mx.google.com with ESMTPS id c20sm7600967rvf.2007.10.26.16.44.28 (version=SSLv3 cipher=RC4-MD5); Fri, 26 Oct 2007 16:44:30 -0700 (PDT) Message-ID: <47227BD9.7090701@gmail.com> Date: Sat, 27 Oct 2007 12:44:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Frank Ellermann References: <20071018193104.GD2537@always.joy.eth.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ietf@ietf.org Subject: Re: Megatron X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Afaik, non-member postings to the list are automatically held in moderation to trap spam, and moderators are only human. Brian On 2007-10-27 08:41, Frank Ellermann wrote: > Apparently Megatron put a bunch of messages on hold for eight days, > compare : > > | Original-Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) > | by megatron.ietf.org with esmtp (Exim 4.43) > | id 1IlT12-0002lZ-Jq; Fri, 26 Oct 2007 13:30:36 -0400 > | Original-Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) > | by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiaz1-0005pF-56 > | for ietf@ietf.org; Thu, 18 Oct 2007 15:24:39 -0400 > | Original-Received: from sceptre.pobox.com ([207.106.133.20]) > | by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iiayl-0006I3-OX > | for ietf@ietf.org; Thu, 18 Oct 2007 15:24:24 -0400 > > As far as I can see it only Peter noted that something's wrong... > > ...and solved it by simply trying again after about twelve hours: > > > Frank > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 20:06:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlZ04-000193-Tn; Fri, 26 Oct 2007 19:54:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlZ03-00018w-50 for ietf@ietf.org; Fri, 26 Oct 2007 19:53:59 -0400 Received: from wx-out-0506.google.com ([66.249.82.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlYzw-00019r-6V for ietf@ietf.org; Fri, 26 Oct 2007 19:53:59 -0400 Received: by wx-out-0506.google.com with SMTP id s8so902844wxc for ; Fri, 26 Oct 2007 16:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=5H1ayvzZf8eol5lU5cHqcQ3fajYKJNZWka6/xgHcOy8=; b=j++IKGkSmH4Ce+bYl9xHIu3K5NX2SOzvOILJ4VZfNJ2qLWc+rtIyueUxpVKRZa900cF8K6MjVx8obsGEUUavk72Rz0cMzauaYHFI7N1Lua3BEB3pv6ba2u62ASt1g0VshlCTzL0IoqKpQWuV+3cGvbec8+66PtDTfKbhV+M3kYU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cqHCzUtdQcti2LDlELOCzhPRwiW1NCCa9E+h0pcVvxRJJsLFUQL4Ir4zMZEnh0MjM5mIo5KjnSabSf+hP5vxPqicWjHb/0l3zxrKh6lxGAc3P9tBDl8DiOYs2Zg7+l+wxBkFIzuqJ90c/Rzl1AQqI8U+jCnIlVMPks2BVyUObvI= Received: by 10.90.102.20 with SMTP id z20mr2910275agb.1193442814897; Fri, 26 Oct 2007 16:53:34 -0700 (PDT) Received: by 10.90.97.17 with HTTP; Fri, 26 Oct 2007 16:53:34 -0700 (PDT) Message-ID: Date: Fri, 26 Oct 2007 16:53:34 -0700 From: "Bill Fenner" To: "Hallam-Baker, Phillip" In-Reply-To: <2788466ED3E31C418E9ACC5C3166155707A4C9@mou1wnexmb09.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200710190047.59493.pupeno@pupeno.com> <2788466ED3E31C418E9ACC5C3166155707A4C9@mou1wnexmb09.vcorp.ad.vrsn.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: "=?ISO-8859-1?Q?J._Pablo_Fern=E1ndez?=" , ietf@ietf.org Subject: Re: A pattented standard is not a standard X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 10/26/07, Hallam-Baker, Phillip wrote: > Is this an official FSF campaign? Yes, http://www.fsf.org/news/oppose-tls-authz-standard.html Bill _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 20:06:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlYs6-0005mc-4v; Fri, 26 Oct 2007 19:45:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlYs4-0005lr-Hj for ietf@ietf.org; Fri, 26 Oct 2007 19:45:44 -0400 Received: from rv-out-0910.google.com ([209.85.198.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlYru-0000w7-Ax for ietf@ietf.org; Fri, 26 Oct 2007 19:45:40 -0400 Received: by rv-out-0910.google.com with SMTP id l15so836408rvb for ; Fri, 26 Oct 2007 16:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=gIWD1TdaOY0W7lk6PFeTQwA/XL0BBeVfp/3+Qv5cJWY=; b=r4JZ+wvoLoqUdnVt26O5tdxKHk6vF1XD5uHQPI5PrQHiY2aMIHPZtD+8B/JX6vwSB04/K0NYmIoDGlJyQboKppNdTQXgiN0w2XW+ZlPcM23YqtdRCyYAaknXu3l8TPutInzPLvLy7N8qZxfSNwCxRZfggtmcZLWzydVCiwelVrM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=gd5Nm9naUZvq6u0bvS+vrkUeWk60q/vkLIb3GquHsc4JwSQpzVSOrEDmZVmWmkB4SX6DqOlNOTPX0IpIKeqhHm5NW17bOpED4/b/Eh60SldW+5QGSARehLY9Nw0IpeEDYsb+4IbXdLIZX+qRaSSSpDR4pF/lURA2eKWsQV2jRQM= Received: by 10.140.250.14 with SMTP id x14mr1811267rvh.1193442271238; Fri, 26 Oct 2007 16:44:31 -0700 (PDT) Received: from ?10.1.1.7? ( [222.153.14.113]) by mx.google.com with ESMTPS id c20sm7600967rvf.2007.10.26.16.44.28 (version=SSLv3 cipher=RC4-MD5); Fri, 26 Oct 2007 16:44:30 -0700 (PDT) Message-ID: <47227BD9.7090701@gmail.com> Date: Sat, 27 Oct 2007 12:44:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Frank Ellermann References: <20071018193104.GD2537@always.joy.eth.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ietf@ietf.org Subject: Re: Megatron X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Afaik, non-member postings to the list are automatically held in moderation to trap spam, and moderators are only human. Brian On 2007-10-27 08:41, Frank Ellermann wrote: > Apparently Megatron put a bunch of messages on hold for eight days, > compare : > > | Original-Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) > | by megatron.ietf.org with esmtp (Exim 4.43) > | id 1IlT12-0002lZ-Jq; Fri, 26 Oct 2007 13:30:36 -0400 > | Original-Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) > | by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiaz1-0005pF-56 > | for ietf@ietf.org; Thu, 18 Oct 2007 15:24:39 -0400 > | Original-Received: from sceptre.pobox.com ([207.106.133.20]) > | by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iiayl-0006I3-OX > | for ietf@ietf.org; Thu, 18 Oct 2007 15:24:24 -0400 > > As far as I can see it only Peter noted that something's wrong... > > ...and solved it by simply trying again after about twelve hours: > > > Frank > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 20:06:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlZ04-000193-Tn; Fri, 26 Oct 2007 19:54:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlZ03-00018w-50 for ietf@ietf.org; Fri, 26 Oct 2007 19:53:59 -0400 Received: from wx-out-0506.google.com ([66.249.82.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlYzw-00019r-6V for ietf@ietf.org; Fri, 26 Oct 2007 19:53:59 -0400 Received: by wx-out-0506.google.com with SMTP id s8so902844wxc for ; Fri, 26 Oct 2007 16:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=5H1ayvzZf8eol5lU5cHqcQ3fajYKJNZWka6/xgHcOy8=; b=j++IKGkSmH4Ce+bYl9xHIu3K5NX2SOzvOILJ4VZfNJ2qLWc+rtIyueUxpVKRZa900cF8K6MjVx8obsGEUUavk72Rz0cMzauaYHFI7N1Lua3BEB3pv6ba2u62ASt1g0VshlCTzL0IoqKpQWuV+3cGvbec8+66PtDTfKbhV+M3kYU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cqHCzUtdQcti2LDlELOCzhPRwiW1NCCa9E+h0pcVvxRJJsLFUQL4Ir4zMZEnh0MjM5mIo5KjnSabSf+hP5vxPqicWjHb/0l3zxrKh6lxGAc3P9tBDl8DiOYs2Zg7+l+wxBkFIzuqJ90c/Rzl1AQqI8U+jCnIlVMPks2BVyUObvI= Received: by 10.90.102.20 with SMTP id z20mr2910275agb.1193442814897; Fri, 26 Oct 2007 16:53:34 -0700 (PDT) Received: by 10.90.97.17 with HTTP; Fri, 26 Oct 2007 16:53:34 -0700 (PDT) Message-ID: Date: Fri, 26 Oct 2007 16:53:34 -0700 From: "Bill Fenner" To: "Hallam-Baker, Phillip" In-Reply-To: <2788466ED3E31C418E9ACC5C3166155707A4C9@mou1wnexmb09.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200710190047.59493.pupeno@pupeno.com> <2788466ED3E31C418E9ACC5C3166155707A4C9@mou1wnexmb09.vcorp.ad.vrsn.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: "=?ISO-8859-1?Q?J._Pablo_Fern=E1ndez?=" , ietf@ietf.org Subject: Re: A pattented standard is not a standard X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 10/26/07, Hallam-Baker, Phillip wrote: > Is this an official FSF campaign? Yes, http://www.fsf.org/news/oppose-tls-authz-standard.html Bill _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 20:28:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlZQX-0005iB-JE; Fri, 26 Oct 2007 20:21:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlZQW-0005eM-B1 for ietf@ietf.org; Fri, 26 Oct 2007 20:21:20 -0400 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlZQM-00023F-Cv for ietf@ietf.org; Fri, 26 Oct 2007 20:21:17 -0400 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1IlZQ6-0001eR-3x; Fri, 26 Oct 2007 20:20:54 -0400 Message-ID: <47228445.2080807@ca.afilias.info> Date: Fri, 26 Oct 2007 20:20:21 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian E Carpenter References: <47227E5A.9090207@gmail.com> In-Reply-To: <47227E5A.9090207@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ietf@ietf.org, Bernard Aboba Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Brian E Carpenter wrote: > That's quite correct. But when judging the rough consensus of the IETF, > I believe that the IESG is fully entitled to consider whether multiple > similar messages from people who have rarely if ever participated in > IETF activities carry as much weight as messages from active > participants. One would hope that their respective roles in the larger community would also be given appropriate weight. The likes of implementers (of protocols), whether in the open-source community or as an employee of a vendor of hardware or software, should be given as much, if not more, consideration. Ditto folks who are involved in designing/building host operating systems or equivalent embedded systems. Remember, the whole "Internet" thing is only a way for computers to talk... and every "router" or "gateway", is basically a general-purpose computer optionally with some extra, special-purpose hardware attached. Brian D _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 20:28:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlZNJ-0007hr-OX; Fri, 26 Oct 2007 20:18:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlZNH-0007d3-RR for ietf@ietf.org; Fri, 26 Oct 2007 20:17:59 -0400 Received: from rv-out-0910.google.com ([209.85.198.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlZN6-0001wF-IS for ietf@ietf.org; Fri, 26 Oct 2007 20:17:54 -0400 Received: by rv-out-0910.google.com with SMTP id l15so841869rvb for ; Fri, 26 Oct 2007 17:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=i8G2kU9eWVyanzavNzBkFELIZWki95prU8lH6ZThgmI=; b=VyfebBrmo9OLkD9/X399SG+oPrxN1hzzsBzvp/tR43MV+sGmrXJPURKsGSJk63XSh0tf4/EryIJOA4ium9r9gaay6rfCniBkyIRTz+nfgy0FzOTMv6st19+xWoFQNfy64pG46iPFAzHpRbYJtaItyd0Eqgyr7zsO1k54/KZGADA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=sbTgCzEla9O22hd3eenIuof4oOCckCL61IoxkFO5oTJl7+4STJL09SrxNXfRn6WJXWTWR5JuiLhBeOCTEeD1HLUqIc3SyV28PlffMh/mz2Ct87EKgfSagNuMHDGTuSGNF3eqe9mbIdYEevXpG1vqfBT08RJWUVNdcg2L38Jnd6Q= Received: by 10.141.196.13 with SMTP id y13mr1808059rvp.1193444232909; Fri, 26 Oct 2007 17:17:12 -0700 (PDT) Received: from ?10.1.1.7? ( [222.153.14.113]) by mx.google.com with ESMTPS id c36sm6620723rvf.2007.10.26.17.17.11 (version=SSLv3 cipher=RC4-MD5); Fri, 26 Oct 2007 17:17:12 -0700 (PDT) Message-ID: <47228384.9080608@gmail.com> Date: Sat, 27 Oct 2007 13:17:08 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ietf@ietf.org References: <001d01c815e8$b2b966b0$6401a8c0@LROSENTOSHIBA> <015101c81624$3357e090$0a01a8c0@rodage.dyndns.org> In-Reply-To: <015101c81624$3357e090$0a01a8c0@rodage.dyndns.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: Re: A priori IPR choices X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org (Cross posting removed) On 2007-10-24 22:56, Philippe Verdy wrote: ... > However, the FSF recognizes that, until now, the IETF was more strict about > the licensing conditions, rejecting proposals that included royalties-maker > licenses and explicit personal agreement between the licensor and the > licensees (under this scheme, if it was accepted, nothing would prevent a > licensor to start charging yearly royalties to each licensor for exercising > the patented rights. In that case the FSF recognized wrong... the IETF has often approved standards track documents with IPR disclosures setting RAND conditions. On 2007-10-26 21:13, Norbert Bollow wrote: ... > The question is this: Is copyleft open source / free software so > unimportant with regard to any area of internet standards that it > would be justifiable to adopt any specification with fundamentally > incompatible patent situation as a standards-track RFC? > > I believe that the answer to this question very clearly is no! Norbert, you seem to miss the point that the IETF's criterion for advancing documents along the standards track is *empirical* (has interoperability been demonstrated in the real world?) and emphatically not faith-based (do we *believe* that the standard is good and the IPR issues unimportant?). The question at issue is whether we should change the empirical criteria to explicitly include the availability of at least one implementation that is both interoperable and free. On 2007-10-27 07:22, Hallam-Baker, Phillip wrote: ... > It is not a major change in principle. But it does have some practical changes. > > When we chartered KEYPROV I was told that the IPR regime should not be in the charter, this was not a concern to me there because all the proposals were OK IPR wise. But I do want to have the option of the forcing function in the charter as explained. This is standard in OASIS and in W3C there is only one regime that the WGs can chose. I think it really is an enormous change in principle, from an empirical to a faith-based approach. On 2007-10-27 08:06, SM wrote: ... > Patents do raise some concerns about interoperability in regards to open source/free software. From a technical point of view, there is nothing that prevents implementation if the specifications are available. But then, we are taking a narrowed view of interoperability. Well, that's exactly the reason for the IETF's empirical approach; we don't even need to consider IPR as a separate issue when testing interoperability. The simple existence of interoperable implementations tells us that IPR conditions must be reasonable. If we extend that to include at least one free implementation, that tells us that IPR conditions for free software must be reasonable. QED. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 20:41:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlZdC-0008TX-55; Fri, 26 Oct 2007 20:34:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlZdA-0007wg-UY for ietf@ietf.org; Fri, 26 Oct 2007 20:34:24 -0400 Received: from mho-02-bos.mailhop.org ([63.208.196.179]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlZd6-0004rf-G6 for ietf@ietf.org; Fri, 26 Oct 2007 20:34:20 -0400 Received: from c-71-197-208-131.hsd1.or.comcast.net ([71.197.208.131] helo=internaut.com) by mho-02-bos.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1IlZd5-000IwV-PL; Sat, 27 Oct 2007 00:34:19 +0000 Received: by internaut.com (Postfix, from userid 1000) id 03FA182968; Fri, 26 Oct 2007 17:34:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id EB2D282933; Fri, 26 Oct 2007 17:34:18 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.197.208.131 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19ucfOF7MAxBNqU6rUmLFJ+ Date: Fri, 26 Oct 2007 17:34:18 -0700 (PDT) From: Bernard Aboba To: Brian E Carpenter In-Reply-To: <47227E5A.9090207@gmail.com> Message-ID: References: <47227E5A.9090207@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ietf@ietf.org Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > Actually, yes, we do leave the IESG to make the judgement, subject > to appeal to the IAB. I also think it's reasonably clear that the > IESG is allowed to recognize that "circumstances alter cases" rather > than to automatically follow precedents. But that's certainly a > matter of interpretation. As I see it, the use of the Experimental designation for situations like this one is quite appropriate. Part of what we lost with the decline of the Draft Standard was the ability to judge the effect of encumbrance based on whether multiple interoperable implementations were precluded. As a result, the IETF is now publishing wave after wave of encumbered "Proposed Standards" whose prospects for widespread implementation are uncertain at best. It would be interesting to look at the data to see if the average "Proposed Standard" would be any more likely to be implemented than your average "Experimental" or even "Informational" RFC. > > With respect to judging whether a particular set of emails constitutes a DoS > > attack or an expression of the will of the IETF community -- RFC 2026 > > doesn't impose a "poll tax" on posters, requiring that they demonstrate > > knowledge of IETF process to express their opinions. > > That's quite correct. But when judging the rough consensus of the IETF, > I believe that the IESG is fully entitled to consider whether multiple > similar messages from people who have rarely if ever participated in > IETF activities carry as much weight as messages from active > participants. In this case, it's quite clear that many of the postings are the result of a "campaign": http://www.fsf.org/news/oppose-tls-authz-standard.html This is not the first time this has happened, nor will it be the last. However, it would be desirable for the IETF to have a consistent approach to such things. One thing I like about the Experimental designation approach is that it allows the determination of the effect of encumbrance to be evaluated in retrospect, allowing the IETF Last Call to focus on technical arguments. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 20:55:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlZpI-0008Hy-QH; Fri, 26 Oct 2007 20:46:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlZpH-00089y-06 for ietf@ietf.org; Fri, 26 Oct 2007 20:46:55 -0400 Received: from mho-01-bos.mailhop.org ([63.208.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlZp6-0002dH-Nt for ietf@ietf.org; Fri, 26 Oct 2007 20:46:49 -0400 Received: from c-71-197-208-131.hsd1.or.comcast.net ([71.197.208.131] helo=internaut.com) by mho-01-bos.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1IlZos-000PMT-Dg; Sat, 27 Oct 2007 00:46:30 +0000 Received: by internaut.com (Postfix, from userid 1000) id D3AF282968; Fri, 26 Oct 2007 17:46:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id C533682933; Fri, 26 Oct 2007 17:46:29 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.197.208.131 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+U/xhPQFJnI3wO6dOo94id Date: Fri, 26 Oct 2007 17:46:29 -0700 (PDT) From: Bernard Aboba To: Brian Dickson In-Reply-To: <47228445.2080807@ca.afilias.info> Message-ID: References: <47227E5A.9090207@gmail.com> <47228445.2080807@ca.afilias.info> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ietf@ietf.org Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > The likes of implementers (of protocols), whether in the open-source community > or as an employee of a vendor of hardware or software, should be given as > much, if not more, consideration. > > Ditto folks who are involved in designing/building host operating systems or > equivalent embedded systems. I fully agree with this. Yet the opinions of "implementers" may not be easy to distinguish initially. For example, some of the IETF's most famous "controversies" turned out not to be much of a contest when looked at in retrospect -- the implementers ended up all on one side of the debate. The question is whether this was obvious at the time, and whether we could have settled the arguments sooner. There are some current situations in the IETF, where IMHO it is quite obvious that a consensus of implementers exists, as judged by interoperable implementations. Yet the IETF persists in taking an alternate path with (seemingly) little prospect of success. Often in these cases the "bogo-standards" are being pushed by the WG chair(s) or ADs with little or no real backing from the IETF community. I'd suggest it would be preferrable for these efforts to "fail early" rather than taking years to meet their inevitable demise. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 20:56:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlZue-0002fo-Sq; Fri, 26 Oct 2007 20:52:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlZub-0001iA-El for ietf@ietf.org; Fri, 26 Oct 2007 20:52:25 -0400 Received: from rv-out-0910.google.com ([209.85.198.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlZuS-0002o8-89 for ietf@ietf.org; Fri, 26 Oct 2007 20:52:22 -0400 Received: by rv-out-0910.google.com with SMTP id l15so847880rvb for ; Fri, 26 Oct 2007 17:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=EDXfJsC9aYPqbcwmNfpSeL8Hr74bwz6kJqHP5oZC7mY=; b=sIK5l/6KpAUpeYp8yigD1dRWnNyMOSt68Iu3AhDAy6GOCoqMSsnrrbs5CnPE2KlUxP3Bnd9nCCgt6rL7v8TCKjtT5CDLjNQSuQQhxNg6pzGRIYpePuF97p7s0beL8YrvhLDWyEYhAk/naySiNQ2f4yORbCmrP5ml81daDi4HBVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=MvtZX5Vn92EC/ZiTaHIiQtSuswV+8U6vnqNv+3DO+PycOPKxYFtVRJd5dNudHETiNjSDaDoYX82S92p6ai9BFr8u9AMSxGCuNlpQcnU+JsdDWG/OzOGnkgdyGy6pXnC2GOVm2Mn5WVemkcj32arAE4/v6/qk38btlsosUoHSXDI= Received: by 10.141.196.13 with SMTP id y13mr1815835rvp.1193446313356; Fri, 26 Oct 2007 17:51:53 -0700 (PDT) Received: from ?10.1.1.7? ( [222.153.14.113]) by mx.google.com with ESMTPS id b5sm7746245rva.2007.10.26.17.51.51 (version=SSLv3 cipher=RC4-MD5); Fri, 26 Oct 2007 17:51:52 -0700 (PDT) Message-ID: <47228B9E.5040000@gmail.com> Date: Sat, 27 Oct 2007 13:51:42 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ietf@ietf.org References: <47227E5A.9090207@gmail.com> <47228445.2080807@ca.afilias.info> In-Reply-To: <47228445.2080807@ca.afilias.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org To dispel any possible doubt, I agree violently with what Brian D says below. Brian C On 2007-10-27 13:20, Brian Dickson wrote: > Brian E Carpenter wrote: >> That's quite correct. But when judging the rough consensus of the IETF, >> I believe that the IESG is fully entitled to consider whether multiple >> similar messages from people who have rarely if ever participated in >> IETF activities carry as much weight as messages from active >> participants. > One would hope that their respective roles in the larger community would > also be given appropriate weight. > > The likes of implementers (of protocols), whether in the open-source > community > or as an employee of a vendor of hardware or software, should be given > as much, > if not more, consideration. > > Ditto folks who are involved in designing/building host operating > systems or > equivalent embedded systems. > > Remember, the whole "Internet" thing is only a way for computers to talk... > and every "router" or "gateway", is basically a general-purpose computer > optionally with some extra, special-purpose hardware attached. > > Brian D > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Fri Oct 26 22:22:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlavK-00031n-HL; Fri, 26 Oct 2007 21:57:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilav9-0002ze-Cl for ietf@ietf.org; Fri, 26 Oct 2007 21:57:03 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ilauu-0004UA-C7 for ietf@ietf.org; Fri, 26 Oct 2007 21:56:49 -0400 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l9R1qm7e024549; Fri, 26 Oct 2007 18:52:48 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Oct 2007 18:55:53 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 26 Oct 2007 18:52:22 -0700 Message-ID: <2788466ED3E31C418E9ACC5C3166155707A511@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DOS (was: Experimental makes sense for tls-authz) Thread-Index: AcgYHaoBzRz9FJR7RIysgb9CLKWp9QAHiqgQ From: "Hallam-Baker, Phillip" To: "Frank Ellermann" , X-OriginalArrivalTime: 27 Oct 2007 01:55:53.0456 (UTC) FILETIME=[81C86F00:01C8183C] X-Spam-Score: -4.0 (----) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: RE: DOS (was: Experimental makes sense for tls-authz) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1535449915==" Errors-To: ietf-bounces@ietf.org --===============1535449915== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 WW91IGFyZSByZW1pbmRlZCBvZiBNQVJJRD8NCg0KVGhhdCB3YXMgdGhlIGxhc3QgdGltZSBSTVMg aGFkIG9uZSBvZiB0aGVzZSB3cml0ZSBpbiBjYW1wYWlnbnMuIFRoYXQgdGhlbiBsZWQgdG8gYSBj b3VudGVyLXdyaXRlLWluIGNhbXBhaWducy4NCg0KTGV0cyBhbGwgd3JpdGUgQ29uZ3Jlc3Mgd2hp bGUgd2UgYXJlIGF0IGl0LiANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBGcmFuayBFbGxlcm1hbm4gW21haWx0bzpub2JvZHlAeHl6enkuY2xhcmFuZXQuZGVdIA0KPiBT ZW50OiBGcmlkYXksIE9jdG9iZXIgMjYsIDIwMDcgNTo1NyBQTQ0KPiBUbzogaWV0ZkBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBET1MgKHdhczogRXhwZXJpbWVudGFsIG1ha2VzIHNlbnNlIGZvciB0bHMt YXV0aHopDQo+IA0KPiBCcmlhbiBFIENhcnBlbnRlciB3cm90ZToNCj4gDQo+ID4gVGhlIERPUyBh dHRhY2sgb24gdGhpcyBsaXN0IHNlZW1zIHRvIGJlIGZyb20gcGVvcGxlIHdobyANCj4gaGF2ZW4n dCByZWFkIA0KPiA+IFJGQyAyMDI2IGFuZCB1c2UgbWVhbmluZ2xlc3MgcGhyYXNlcyBsaWtlICJl eHBlcmltZW50YWwgc3RhbmRhcmQuIg0KPiANCj4gV2hhdCB3YXMgaXQsIDMwIG1lc3NhZ2VzIGNv bGxlY3RlZCBieSBNZWdhdHJvbiBvdmVyIGVpZ2h0IGRheXMgPw0KPiBGWUkgMzYgPGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzQ5NDkjcGFnZS0xMDE+IG9mZmVycyBhIA0KPiBkZWZpbml0 aW9uIGZvciAiZGVuaWFsIG9mIHNlcnZpY2UiLg0KPiANCj4gT2YgY291cnNlIHNvbWUgbWVzc2Fn ZXMgYWJvdXQgYSAic3RhbmRhcmQgb24gZXhwZXJpbWVudGFsIHRyYWNrIg0KPiBvciBzaW1pbGFy IGtpbmQgb2YgbWlzcyB0aGUgcG9pbnQuICBBcyBhICJjYW1wYWlnbiIgaXQgDQo+IHJlbWluZGVk IG1lIG9mIHRoZSB3ZWlyZCAieWVzLCB3ZSB3aWxsIGRlcGxveSBzZW5kZXItaWQiIA0KPiBwYXJh ZGUgaW4gTUFSSUQuDQo+IA0KPiBPdGhlciBtZXNzYWdlcyB3ZXJlIHBlcmZlY3RseSBvbiB0b3Bp YywgYXBwYXJlbnRseSBmcm9tIA0KPiBjb25jZXJuZWQgZm9sa3MuICBJIGFncmVlIHdpdGggdGhl IGRyaWZ0IGluIHRoZSByZXN0IG9mIHlvdXIgDQo+IG1lc3NhZ2UsIGJ1dCBvZiBjb3Vyc2UgSSB3 b24ndCBzYXkgYW55dGhpbmcgYWJvdXQgdGhlIA0KPiBzcGVjaWZpYyBJLUQgaW4gYW4gSUVURiBM YXN0IENhbGwsIGZvciBzdGFydGVycyBJIGRpZG4ndCByZWFkIGl0LiAgDQo+IA0KPiBPVE9IIEkg YWxzbyBhZ3JlZSB3aXRoIHRoZSBkcmlmdCBvZiBwYWdlcyBsaWtlIA0KPiA8aHR0cDovL2ZmaWku b3JnPiwgdGhhdCBpbmNsdWRlcyBhIGNhc2Ugd2hlcmUgImF0dGFjayIgd291bGQgDQo+IGJlIHB1 dHRpbmcgaXQgbWlsZGx5Lg0KPiANCj4gIEZyYW5rDQo+IA0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSWV0ZiBtYWlsaW5nIGxpc3QNCj4g SWV0ZkBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p ZXRmDQo+IA0K --===============1535449915== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============1535449915==-- From ietf-bounces@ietf.org Fri Oct 26 22:48:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlbYF-0000bI-Qq; Fri, 26 Oct 2007 22:37:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlbYE-0000bD-GY for ietf@ietf.org; Fri, 26 Oct 2007 22:37:26 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlbY7-0005Xq-0H for ietf@ietf.org; Fri, 26 Oct 2007 22:37:26 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 136BA2596F6; Sat, 27 Oct 2007 04:37:08 +0200 (CEST) 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 02998-05; Sat, 27 Oct 2007 04:37:03 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id F21E42596EF; Sat, 27 Oct 2007 04:37:02 +0200 (CEST) Message-ID: <4722A467.3090501@alvestrand.no> Date: Sat, 27 Oct 2007 04:37:27 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Brian E Carpenter References: <20071018193104.GD2537@always.joy.eth.net> <47227BD9.7090701@gmail.com> In-Reply-To: <47227BD9.7090701@gmail.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Frank Ellermann , ietf@ietf.org Subject: Re: Megatron X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Brian E Carpenter skrev: > Afaik, non-member postings to the list are automatically held in > moderation to trap spam, and moderators are only human. And I do think that one reason why letter-writing campaigns against the IETF have been rare is that it's hard to argue that people who care *shouldn't* subscribe to the relevant mailing lists at least for the duration of the discussion - which means that they get copies of all the campaign letters too :-) Harald _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 01:30:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ildw5-00046w-Gb; Sat, 27 Oct 2007 01:10:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ildw3-00046d-N4 for ietf@ietf.org; Sat, 27 Oct 2007 01:10:11 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ildw3-0001xU-AH for ietf@ietf.org; Sat, 27 Oct 2007 01:10:11 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Ildvu-0006WP-Bj for ietf@ietf.org; Sat, 27 Oct 2007 05:10:02 +0000 Received: from eth595.vic.adsl.internode.on.net ([150.101.214.82]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Oct 2007 05:10:02 +0000 Received: from ben+ietf by eth595.vic.adsl.internode.on.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Oct 2007 05:10:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: Ben Finney Date: Sat, 27 Oct 2007 15:09:17 +1000 Lines: 25 Message-ID: <87tzodgn42.fsf@benfinney.id.au> References: <20071026210538.6D71E872CA@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: eth595.vic.adsl.internode.on.net X-Public-Key-ID: 0xBD41714B X-Public-Key-Fingerprint: 9CFE 12B0 791A 4267 887F 520C B7AC 2E51 BD41 714B X-Public-Key-URL: http://www.benfinney.id.au/contact/bfinney-gpg.asc X-Post-From: Ben Finney User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Cancel-Lock: sha1:5iAI0qB5NlrjkxcO/h4MIeCLmJc= X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org jnc@mercury.lcs.mit.edu (Noel Chiappa) writes: > I concur [with ignoring requests to reject > 'draft-housley-tls-authz-extns' on grounds of patent encumbrance] - > and I think this is the action we should take, no matter how many > emails we see from people we've never heard from before (and > probably never will again). These people you speak of are users of the internet, and in many cases software developers, expressing specific concern over an IETF process they see as harmful to the foundation of the internet: namely, validation of a patent-encumbered technology by progressing it through a standards process. In the past it has been expressed on this list that the only qualification for getting involved in IETF policy is exactly that, getting involved -- in particular, on this list. Are you saying that people who take the time to post in this forum will be ignored merely because what they say is not what you want to hear? -- \ "Courage is resistance to fear, mastery of fear — not absence | `\ of fear. -- Mark Twain, _Pudd'n'head Wilson_ | _o__) | Ben Finney _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 01:30:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ildtw-0002tS-9x; Sat, 27 Oct 2007 01:08:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ildtt-0002q6-VX for ietf@ietf.org; Sat, 27 Oct 2007 01:07:57 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ildtj-0000fC-Jl for ietf@ietf.org; Sat, 27 Oct 2007 01:07:53 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IldtN-0006DF-Fg for ietf@ietf.org; Sat, 27 Oct 2007 05:07:25 +0000 Received: from eth595.vic.adsl.internode.on.net ([150.101.214.82]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Oct 2007 05:07:25 +0000 Received: from ben+ietf by eth595.vic.adsl.internode.on.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Oct 2007 05:07:25 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: Ben Finney Date: Sat, 27 Oct 2007 15:07:15 +1000 Lines: 39 Message-ID: <87y7dpgn7g.fsf@benfinney.id.au> References: <003e01c817fa$b09cfb80$6801a8c0@oemcomputer> <20071026191611.C65F27E13@bender.tigertech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: eth595.vic.adsl.internode.on.net X-Public-Key-ID: 0xBD41714B X-Public-Key-Fingerprint: 9CFE 12B0 791A 4267 887F 520C B7AC 2E51 BD41 714B X-Public-Key-URL: http://www.benfinney.id.au/contact/bfinney-gpg.asc X-Post-From: Ben Finney User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Cancel-Lock: sha1:S1uGfIPzzUwh507IYKIZgQKpDx8= X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org "Joel M. Halpern" writes: > We have published encumbered experimental and informational > documents on many occasions. I can see no reason not to do so in > this case. The reasons are the same as they have always been. Making a mistake in the past is no reason to continue making that same mistake. Software idea patents place control over *every* independent implementation of an idea in the hands of *one* entity, who then gets to dictate whatever terms they like. This is unjust, and is a practical hindrance on every software developer since it adds to the minefield of ideas that they must avoid using when designing their code. Even developers who are not intending to use ideas encumbered by a particular patent can independently arrive at some specific method described in that patent, and inadvertantly violate the patent rules. In such cases the violation will not be discovered for some unknown amount of time. The burden on software developers thus mounts with every patent on a software idea. To allow a technology, encumbered by any known patent holder's monopoly, as a proposed standard (even experimental or informational or any other status) is to give legitimacy to this system that directly harms development of all software, and especially harms the goal of interoperability that is part of the purpose of a standards process. Please explicitly reject technologies from any part of the standards process that are encumbered by software idea patents. I encourage the IETF to start by rejecting 'draft-housley-tls-authz-extns'. -- \ "Holy bouncing boiler-plated fits, Batman!" -- Robin | `\ | _o__) | Ben Finney _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 02:34:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iletz-0003ra-I1; Sat, 27 Oct 2007 02:12:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iletx-0003rU-HV for ietf@ietf.org; Sat, 27 Oct 2007 02:12:05 -0400 Received: from email.xpasc.com ([65.85.17.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iletr-0002Bf-9e for ietf@ietf.org; Sat, 27 Oct 2007 02:12:05 -0400 Received: from bslepgate.xpasc.com (localhost.localdomain [127.0.0.1]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id 4C1B010058A for ; Fri, 26 Oct 2007 23:11:44 -0700 (PDT) X-Propel-Return-Path: Received: from email.xpasc.com ([10.1.2.88]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 2.1.7.8167-src $Rev: 8148 $) id iz6Ur7ar6bH0; Fri, 26 Oct 2007 23:11:44 -0700 Received: from xpasc.com (egate.xpasc.com [10.1.2.49]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id E2410100585 for ; Fri, 26 Oct 2007 23:11:43 -0700 (PDT) Received: from egate.xpasc.com (egate.xpasc.com [10.1.2.49]) by xpasc.com (8.11.2/8.11.2) with ESMTP id l9R6Bg714584 for ; Fri, 26 Oct 2007 23:11:42 -0700 Date: Fri, 26 Oct 2007 23:11:41 -0700 (PDT) From: David Morris cc: In-Reply-To: <87tzodgn42.fsf@benfinney.id.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Propel-ID: iz6Ur7ar6bH0 X-Spam-Score: 1.6 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Sat, 27 Oct 2007, Ben Finney wrote: > jnc@mercury.lcs.mit.edu (Noel Chiappa) writes: > getting involved -- in particular, on this list. Are you saying that > people who take the time to post in this forum will be ignored merely > because what they say is not what you want to hear? Absolutely, if they don't bother to stick around and read the subsequent discussion. Merely spaming this list does provide validity to the poster's point of view. Hanging around and participating and having the rest of the community observe the poster's qualifications first hand as they re-inforce their points is how they earn respect in this organization. Repeated posts of what were essentially copies of boilerplate text by multiple people doesn't engender credibility. An frankly, cut and paste political campaigns beg to be ignored. We are not politicians and have no need to measure the support of ideas by the weight of mail received. David Morris _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 04:48:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlhDm-00052r-Oa; Sat, 27 Oct 2007 04:40:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlhDl-00051e-8M for ietf@ietf.org; Sat, 27 Oct 2007 04:40:41 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlhDZ-0006WL-Tu for ietf@ietf.org; Sat, 27 Oct 2007 04:40:36 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IlhD8-0004KI-Gx for ietf@ietf.org; Sat, 27 Oct 2007 08:40:02 +0000 Received: from eth595.vic.adsl.internode.on.net ([150.101.214.82]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Oct 2007 08:40:02 +0000 Received: from ben+ietf by eth595.vic.adsl.internode.on.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Oct 2007 08:40:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: Ben Finney Date: Sat, 27 Oct 2007 18:39:54 +1000 Lines: 37 Message-ID: <87prz1gdd1.fsf@benfinney.id.au> References: <87tzodgn42.fsf@benfinney.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: eth595.vic.adsl.internode.on.net X-Public-Key-ID: 0xBD41714B X-Public-Key-Fingerprint: 9CFE 12B0 791A 4267 887F 520C B7AC 2E51 BD41 714B X-Public-Key-URL: http://www.benfinney.id.au/contact/bfinney-gpg.asc X-Post-From: Ben Finney User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Cancel-Lock: sha1:PV8otKMog/lO7KXqS+XMqmhDQbA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org David Morris writes: > On Sat, 27 Oct 2007, Ben Finney wrote: > > getting involved -- in particular, on this list. Are you saying > > that people who take the time to post in this forum will be > > ignored merely because what they say is not what you want to hear? > > Absolutely, if they don't bother to stick around and read the > subsequent discussion. Merely spaming this list does provide > validity to the poster's point of view. Hanging around and > participating and having the rest of the community observe the > poster's qualifications first hand as they re-inforce their points > is how they earn respect in this organization. These people are asking that IETF reject technologies encumbered by patents from the standards process, because they use the internet and will be harmed by that. The reasons have been stated many times, and remain valid even if not *every* poster makes them plain. What qualifications are required to say "please don't allow patent holders to use IETF to undermine the internet"? > Repeated posts of what were essentially copies of boilerplate text > by multiple people doesn't engender credibility. An frankly, cut and > paste political campaigns beg to be ignored. You must have read different messages to the ones I did. The first hundred or so messages protesting the progression of patent-encumbered 'tls-authz' through the standards process were *all* different, written in the words of different people. They were not "boilerplate text" nor a "cut and paste political campaign". -- \ "A cynic is a man who, when he smells flowers, looks around for | `\ a coffin." -- Henry L. Mencken | _o__) | Ben Finney _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 04:48:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilgy8-0004N1-Cg; Sat, 27 Oct 2007 04:24:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilgy5-0004G4-5F for ietf@ietf.org; Sat, 27 Oct 2007 04:24:29 -0400 Received: from iluvatar.zemris.fer.hr ([161.53.65.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ilgxy-0005y1-QI for ietf@ietf.org; Sat, 27 Oct 2007 04:24:29 -0400 Received: from localhost (unknown [127.0.0.1]) by iluvatar.zemris.fer.hr (Postfix) with ESMTP id 9AA67174024; Sat, 27 Oct 2007 08:19:53 +0000 (UTC) X-Virus-Scanned: by amavisd-new at zemris.fer.hr Received: from iluvatar.zemris.fer.hr ([127.0.0.1]) by localhost (iluvatar.zemris.fer.hr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VW0PoQwh-367; Sat, 27 Oct 2007 10:19:45 +0200 (CEST) Received: from [193.198.86.161] (vipnet161-86.mobile.carnet.hr [193.198.86.161]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by iluvatar.zemris.fer.hr (Postfix) with ESMTP id BA91D174027; Sat, 27 Oct 2007 10:19:40 +0200 (CEST) From: Stjepan Gros To: Randy Presuhn In-Reply-To: <003e01c817fa$b09cfb80$6801a8c0@oemcomputer> References: <003e01c817fa$b09cfb80$6801a8c0@oemcomputer> Content-Type: text/plain Organization: FER - ZEMRIS Date: Sat, 27 Oct 2007 10:21:49 +0200 Message-Id: <1193473309.3143.20.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-4.fc7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ietf@ietf.org Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Fri, 2007-10-26 at 11:04 -0700, Randy Presuhn wrote: > Hi - > > The existence of IPR claims potentially relevant to the implementation > of a specification has never been sufficient grounds to block the > publication of that specification as an RFC. Given the unfortunate > history of this work, publication of draft-housley-tls-authz-extns > as experimental seems to be the most sensible path out of this mess. > > If the IPR terms are indeed so onerous as to preclude widespread > implementation, as seems to be the concern of some, then it will > simply gather dust with other "experiments" that didn't work out, > and the open source community need not worry. If, on the other > hand, this technology is so superior to anything the open source > community can offer as an alternative, then Darwin will go to work. > > None of the recent argumentation has been technical. None of the > recent argumentation has provided a convincing procedural reason > to block publication of draft-housley-tls-authz-extns. Let's just > hand it over to the RFC editor and be done with it. Personally, I'm against publishing anything in any kind of RFC that has unresolved IPR issues. As for experimental RFC. I think it's not hard to force majority into it's use, especially if it's a good idea and solves a real problem. If, e.g. some large web server/browser vendor decides that it's easier to pay for this patent that to reinvent it, and then implements it, then the others must follow, and in general, we have interoperability problems. The most problematic in this case is Open Source, and the fact is that Open Source can not be ignored, if nothing else, because Internet was built on such software. Note that this is the only one, and very simple, scenario to reach the goal of having Experimental RFC ad hoc standard. And in my opinion, not so unrealistic. Furthermore, shouldn't be the burden of development of alternative, non IPR problematic technologies, IETF's task? Stjepan > Randy > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 05:42:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilhyo-0003A7-IS; Sat, 27 Oct 2007 05:29:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilhyl-0002zo-1P for ietf@ietf.org; Sat, 27 Oct 2007 05:29:15 -0400 Received: from mail.globalsuite.net ([69.46.103.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ilhyb-0008AL-Sf for ietf@ietf.org; Sat, 27 Oct 2007 05:29:12 -0400 X-AuditID: c0a8013c-ad9bebb00000090e-dc-472304cc2737 Received: from Harrington73653 (streamline120.sjccnet.com [207.87.51.120]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 57A614DC011; Sat, 27 Oct 2007 03:28:44 -0600 (MDT) From: "David Harrington" To: "'Joel M. Halpern'" , References: <003e01c817fa$b09cfb80$6801a8c0@oemcomputer> <20071026191611.C65F27E13@bender.tigertech.net> Date: Sat, 27 Oct 2007 02:28:31 -0700 Message-ID: <01f601c8187b$bded7900$3f8011ac@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <20071026191611.C65F27E13@bender.tigertech.net> Thread-Index: AcgYBbRdlBt5RzbpQL6VXYSPL3LNBAAdgBFQ X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: RE: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Friday, October 26, 2007 12:16 PM > To: ietf@ietf.org > Subject: Experimental makes sense for tls-authz > > Given the current email activity on this issue, I want to > echo Randy's support. > We have published encumbered experimental and informational documents > on many occasions. I can see no reason not to do so in this > case. Given that it appears that experimental publication is > sufficient for the registration needs that go with this document, I > strongly support publication. > > Yours, > Joel M. Halpern > +1 David Harrington dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 07:24:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IljPy-0002qK-SE; Sat, 27 Oct 2007 07:01:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IljPx-0002pq-Di for ietf@ietf.org; Sat, 27 Oct 2007 07:01:25 -0400 Received: from fk-out-0910.google.com ([209.85.128.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IljPt-0002Aj-3c for ietf@ietf.org; Sat, 27 Oct 2007 07:01:21 -0400 Received: by fk-out-0910.google.com with SMTP id z23so1030627fkz for ; Sat, 27 Oct 2007 04:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=1XTzBSbBbi35IZwOjoo0cdfHBzUWjU85EI2EDWHDlK8=; b=t4Q1ndZjBeDrBM7By2zyj9Jsyr5pySILseq1yx8rM569L/j+yGEwCGClOS3AL4OAnFDCRIyOYbXFyCX24zHVq28+UcEZ0Q0HGPmEgb68aHe8mGGdnGGqOefADrUHanYkKxxj1tZg9772tJaI5jxXW8UftsPSs13D5KeQs2D9Els= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=B8oAqEQzkM2nt2RpujkC3aZTWf5ioUgx5HhaXF02Y2sLAuWEGPHogfEHPMuKqCLT9Y7D4YsZzEU+miAW1UQoWjMhQRiNwdxwaqxE/bEkxUjC/LVWXYZIIOzFU+D0j4vm37Nea7i8NeQ2nR2qYklzwvd5GBeC8EpI+wzOBXx2/gc= Received: by 10.82.165.13 with SMTP id n13mr7718414bue.1193482859310; Sat, 27 Oct 2007 04:00:59 -0700 (PDT) Received: by 10.82.148.11 with HTTP; Sat, 27 Oct 2007 04:00:59 -0700 (PDT) Message-ID: <558a39a60710270400s1346579dn267c7c6408bbcff0@mail.gmail.com> Date: Sat, 27 Oct 2007 19:00:59 +0800 From: "James Seng" To: ietf@ietf.org In-Reply-To: <20071026210538.6D71E872CA@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071026210538.6D71E872CA@mercury.lcs.mit.edu> X-Google-Sender-Auth: 492d056b17d8593a X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Not that I am not sympathetic to what GNU and FSF is campaigning for, the working principle of IETF is based on running codes and rough consensus. "Votes" or "Petitions" is not part of IETF process the last time I check. I am not familiar with draft-housley-tls-authz-extns but if the only objections is that there are patents surrounding it, I don't see any harm proceeding it as an Experimental RFC. If there are other valid reasons to stop the publication of the draft, we should review it. It is also important to note how many objected to the publication. I suggest the moderator (if there is one) to held up all petition furthers and just post a summary of how many petitions received at the end. -James Seng On 10/27/07, Noel Chiappa wrote: > > From: "Joel M. Halpern" > > > We have published encumbered experimental and informational documents > > on many occasions. I can see no reason not to do so in this case. Given > > that it appears that experimental publication is sufficient for the > > registration needs that go with this document, I strongly support > > publication. > > I concur - and I think this is the action we should take, no matter how many > emails we see from people we've never heard from before (and probably never > will again). > > Noel > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 08:57:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlkuB-00020v-8G; Sat, 27 Oct 2007 08:36:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlkuA-00020p-5I for ietf@ietf.org; Sat, 27 Oct 2007 08:36:42 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ilku3-0003wv-Ut for ietf@ietf.org; Sat, 27 Oct 2007 08:36:42 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ilktp-0004tQ-RN for ietf@ietf.org; Sat, 27 Oct 2007 12:36:21 +0000 Received: from 1cust39.tnt3.hbg2.deu.da.uu.net ([149.225.14.39]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Oct 2007 12:36:21 +0000 Received: from nobody by 1cust39.tnt3.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Oct 2007 12:36:21 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: "Frank Ellermann" Date: Sat, 27 Oct 2007 14:36:11 +0200 Organization: http://purl.net/xyzzy Lines: 15 Message-ID: References: <20071018193104.GD2537@always.joy.eth.net> <47227BD9.7090701@gmail.com> <4722A467.3090501@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 1cust39.tnt3.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: Re: Megatron X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Harald Alvestrand wrote: > I do think that one reason why letter-writing campaigns against the > IETF have been rare is that it's hard to argue that people who care > *shouldn't* subscribe to the relevant mailing lists at least for the > duration of the discussion - which means that they get copies of all > the campaign letters too :-) Just to be sure, I hope you saw that one of my two examples was about an article in the "unicode-escapes" Last Call posted by Peter. =20 If a serious delay is the side-effect of "moderation" I hope that "they" would inform "us" (i.e. the list in addition to the posters). Frank _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 09:20:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IllOr-0000h4-ME; Sat, 27 Oct 2007 09:08:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IllOq-0000Qp-83 for ietf@ietf.org; Sat, 27 Oct 2007 09:08:24 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IllOf-0004f1-4d for ietf@ietf.org; Sat, 27 Oct 2007 09:08:19 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id CFB7887304; Sat, 27 Oct 2007 09:07:52 -0400 (EDT) To: ietf@ietf.org Message-Id: <20071027130752.CFB7887304@mercury.lcs.mit.edu> Date: Sat, 27 Oct 2007 09:07:52 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: jnc@mercury.lcs.mit.edu Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > From: Ben Finney > In the past it has been expressed on this list that the only > qualification for getting involved in IETF policy is exactly that, > getting involved -- in particular, on this list. The IETF is open to anyone who want to join our community. However, 'joining our community' means just that - joining, not just dropping off a drive-by, based on a superficial understanding of the issues, as inaccurately reported by someone with an axe to grind? How is that substantially different from company X telling everyone who works for it 'we want standard X approved, please send in email to the IETF list asking for it to be approved'. You wouldn't think that was useful? No, I didn't think so. Noel _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 10:09:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilm2u-0001u3-4y; Sat, 27 Oct 2007 09:49:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilm2r-0001tZ-Ua for ietf@ietf.org; Sat, 27 Oct 2007 09:49:46 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ilm2i-0005jy-N7 for ietf@ietf.org; Sat, 27 Oct 2007 09:49:42 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ilm2X-0003NI-EI for ietf@ietf.org; Sat, 27 Oct 2007 13:49:25 +0000 Received: from 1cust39.tnt3.hbg2.deu.da.uu.net ([149.225.14.39]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Oct 2007 13:49:25 +0000 Received: from nobody by 1cust39.tnt3.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Oct 2007 13:49:25 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: "Frank Ellermann" Date: Sat, 27 Oct 2007 15:45:56 +0200 Organization: http://purl.net/xyzzy Lines: 23 Message-ID: References: <2788466ED3E31C418E9ACC5C3166155707A511@mou1wnexmb09.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 1cust39.tnt3.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: Re: DOS X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hallam-Baker, Phillip wrote: > You are reminded of MARID? Yes. And also of the http://noooxml.org/ petition where I violated my own "never sign any online petition if you don't get a backlink" rule. =20 > That was the last time RMS had one of these write in campaigns. > That then led to a counter-write-in campaigns. The "shuffle those deck chairs" thread _here_ wasn't what I had in mind, it was quite interesting. The parade of folks stating that they would deploy sender-id, after not contributing any technical article, wasn't here, it was on the MARID list in reply to a poll. Even that was no DOS, identifying hundreds of hit and run posters on a WG list simple. Maybe a mad approximation of a DOS. Frank --=20 See also and the corresponding Plan B: _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 10:09:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlmCz-0005CH-F5; Sat, 27 Oct 2007 10:00:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlmCy-0005Bh-5Y for ietf@ietf.org; Sat, 27 Oct 2007 10:00:12 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlmCx-0005LM-TC for ietf@ietf.org; Sat, 27 Oct 2007 10:00:12 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sat, 27 Oct 2007 10:00:11 -0400 id 01588387.4723446B.000034B8 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1AF7FC4E-CF81-44E5-A122-266CE63980D3@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Sat, 27 Oct 2007 10:00:09 -0400 To: David Morris X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ietf@ietf.org Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 27, 2007, at 2:11 AM, David Morris wrote: > Absolutely, if they don't bother to stick around and read the > subsequent > discussion. Merely spaming this list does provide validity to the > poster's > point of view. Hanging around and participating and having the rest > of the > community observe the poster's qualifications first hand as they > re-inforce their points is how they earn respect in this organization. How do you square this against working group sessions that have obviously been packed, where previous sessions were only moderately attended but many new faces show up in anticipation of a very important hum? I'm all for making the best decision in the face of outside coercion, but better guidelines (not processes) need to be given regarding how the IETF and working groups judge a participant as a valid participant. And they need to be consistent across the various flavors of IETF participation. Until then, I do not favor dismissing these emails. -andy _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 10:22:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlmRG-0002Bv-Vw; Sat, 27 Oct 2007 10:14:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlmRF-0002As-HG for ietf@ietf.org; Sat, 27 Oct 2007 10:14:57 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlmR9-0006NA-EE for ietf@ietf.org; Sat, 27 Oct 2007 10:14:57 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sat, 27 Oct 2007 10:14:16 -0400 id 01588387.472347B8.000039EB In-Reply-To: References: <47227E5A.9090207@gmail.com> <47228445.2080807@ca.afilias.info> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <19F2930A-D8E5-4237-97E2-945E2B29A141@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Sat, 27 Oct 2007 10:14:13 -0400 To: Bernard Aboba X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ietf@ietf.org Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 26, 2007, at 8:46 PM, Bernard Aboba wrote: > There are some current situations in the IETF, where IMHO it is quite > obvious that a consensus of implementers exists, as judged by > interoperable implementations. Yet the IETF persists in taking an > alternate path with (seemingly) little prospect of success. Often in > these cases the "bogo-standards" are being pushed by the WG chair > (s) or > ADs with little or no real backing from the IETF community. I agree, though I wouldn't place the blame only on WG chairs and ADs. Sometimes this is done by small but load "clicks" of people. And it does seem that the IETF does not put enough emphasis on interoperable implementations... or as much as it should. This does not mean the existence of interoperable implementations trumps all other concerns, but in cases where they do exist the bar should be set higher. -andy _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 11:21:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iln9A-0005eG-O9; Sat, 27 Oct 2007 11:00:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iln99-0005cd-Rg for ietf@ietf.org; Sat, 27 Oct 2007 11:00:19 -0400 Received: from email.xpasc.com ([65.85.17.142]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iln99-0006g4-85 for ietf@ietf.org; Sat, 27 Oct 2007 11:00:19 -0400 Received: from bslepgate.xpasc.com (localhost.localdomain [127.0.0.1]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id 41853100585 for ; Sat, 27 Oct 2007 08:00:19 -0700 (PDT) X-Propel-Return-Path: Received: from email.xpasc.com ([10.1.2.88]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 2.1.7.8167-src $Rev: 8148 $) id iz6Ur7arf0i0; Sat, 27 Oct 2007 08:00:19 -0700 Received: from xpasc.com (egate.xpasc.com [10.1.2.49]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id B02A7100091 for ; Sat, 27 Oct 2007 08:00:18 -0700 (PDT) Received: from egate.xpasc.com (egate.xpasc.com [10.1.2.49]) by xpasc.com (8.11.2/8.11.2) with ESMTP id l9RF0H719398 for ; Sat, 27 Oct 2007 08:00:17 -0700 Date: Sat, 27 Oct 2007 08:00:16 -0700 (PDT) From: David Morris cc: In-Reply-To: <1AF7FC4E-CF81-44E5-A122-266CE63980D3@hxr.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Propel-ID: iz6Ur7arf0i0 X-Spam-Score: 1.6 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Sat, 27 Oct 2007, Andrew Newton wrote: > How do you square this against working group sessions that have > obviously been packed, where previous sessions were only moderately > attended but many new faces show up in anticipation of a very > important hum? Well for starters, the drive-by hummers have to sit through the session and be present for the discussion (note I intentionally did not say listen). They have to demonstrate enough interest in the IETF process to actually pay the costs of attending the session. And under IETF process, concensus isn't determined in a F2F meeting. The IETF is supposed to be fostering the engineering of the Internet. Refusing to foster the engineering process based on religious or political or even phantom economic concerns doesn't foster better operation of the Internet. It is in the greater interest of the Internet to have ANY protocol used to define the meaning of some bits on the wires of the Internet well documented. At least three reasons come to mind .. a) I can better understand the impact of the protocol on other traffic and perhaps even document issues to the originator of the traffic if what I observe doesn't agree with the documentation AND seems to be causing my organization a problem. b) Better to know about a documented patent claim than to have it hidden and waiting to bite me when I re-invent it, etc. c) Folks concerned about security vulnerabilities have starting point for their analysis In my mind, experimental RFCs are created to allow two or more parties to participate in an experiment in a well specified context and to allow other parties to understand and comment on the experiment. Informational RFCs exist to allow pretty much anyone to document a 'private' protocol for the reasons I've noted. If an evil giant (pick your virtual enemy du jour) believes there is an advantage for them in implementing and deploying patent encumbered technology, they will do so with or without the technology being documented by the IETF. Hence, I am in favor of publishing Informational/Experimental RFCs which provide clear documentation of engineering related topics of concern to the design and operation of the Internet. Dave Morris _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 13:17:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilorp-0006ys-Q9; Sat, 27 Oct 2007 12:50:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iloro-0006yX-AW for ietf@ietf.org; Sat, 27 Oct 2007 12:50:32 -0400 Received: from [2002:9be6:9d5d:1::1] (helo=izb.knu.ac.kr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ilori-0001LW-1i for ietf@ietf.org; Sat, 27 Oct 2007 12:50:27 -0400 Received: by draba.izb.knu.ac.kr (Postfix, from userid 59) id 0133A3EA6; Sun, 28 Oct 2007 01:50:08 +0900 (KST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on draba.izb.knu.ac.kr X-Spam-Level: X-Spam-Status: No, score=-16.5 required=15.1 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VERIFIED autolearn=disabled version=3.2.3 X-Spam-Comment: DKIM? See http://www.google.com/search?btnI&q=RFC+4871 Received: from izb.knu.ac.kr (localhost.izb.knu.ac.kr [127.0.0.1]) by draba.izb.knu.ac.kr (Postfix) with ESMTP id 976393EA4; Sun, 28 Oct 2007 01:50:07 +0900 (KST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=izb.knu.ac.kr; h=subject: from:reply-to:to:cc:in-reply-to:references:content-type: content-transfer-encoding:date:message-id:mime-version; q= dns/txt; s=s1024; bh=06ywS/OhzMeeZns4sNj1WTmLjAA=; b=NXIalx0zvH4 hcw/zGOd4QqSPCYCsxy6qmpBm4jUa9BuiaT+uNpJi/kcRvDEUm5Mqs7VImr5fSnR m7XnllhsEEYIupcTAtUUNhLzMAHMKof0Oeyt/toHrXieB/v2vL2e2qhUZKiyW5rm 0OHmcRzezJGBvQi4xWD4aKRlO7nGrlDo= Received: from viola.izb.knu.ac.kr (viola.izb.knu.ac.kr [IPv6:2002:9be6:9d5d:3::3]) by draba.izb.knu.ac.kr (Postfix) with ESMTP id 797203E94; Sun, 28 Oct 2007 01:50:07 +0900 (KST) Received: by viola.izb.knu.ac.kr (Postfix, from userid 1001) id 708825E10; Sun, 28 Oct 2007 01:50:08 +0900 (KST) From: Byung-Hee HWANG To: "Hallam-Baker, Phillip" In-Reply-To: <2788466ED3E31C418E9ACC5C3166155707A4C9@mou1wnexmb09.vcorp.ad.vrsn.com> References: <2788466ED3E31C418E9ACC5C3166155707A4C9@mou1wnexmb09.vcorp.ad.vrsn.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: InZealBomb Date: Sun, 28 Oct 2007 01:50:07 +0900 Message-Id: <1193503807.1088.21.camel@viola.izb.knu.ac.kr> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port X-Spam-Score: -1.4 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "J. Pablo =?ISO-8859-1?Q?Fern=E1ndez?=" , ietf@ietf.org Subject: RE: A pattented standard is not a standard X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bh@izb.knu.ac.kr List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Dear Mr. Hallam-Baker, On Fri, 2007-10-26 at 11:35 -0700, Hallam-Baker, Phillip wrote: > Is this an official FSF campaign? > > My past experience is ... [...snip...] Hello, And please, you should be done bottom-posting. You may have a look . If you have another opinions, give me mail without any hesitancy. Sincerely, -- "I spoke for the good of the Family, not for myself. I can take care of myself." -- Tessio, "Chapter 28", page 399 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 13:45:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlpbG-0000GT-1G; Sat, 27 Oct 2007 13:37:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlpbE-0000GE-O6 for ietf@ietf.org; Sat, 27 Oct 2007 13:37:28 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ilpb8-0002XP-KV for ietf@ietf.org; Sat, 27 Oct 2007 13:37:28 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sat, 27 Oct 2007 13:36:51 -0400 id 01588692.47237733.000003F7 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Sat, 27 Oct 2007 13:36:24 -0400 To: David Morris X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ietf@ietf.org Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 27, 2007, at 11:00 AM, David Morris wrote: > Well for starters, the drive-by hummers have to sit through the > session > and be present for the discussion (note I intentionally did not say > listen). They have to demonstrate enough interest in the IETF > process to > actually pay the costs of attending the session. Most of the drive-by hummers have their head buried in their email or other laptop work, so the expense they run for looking up to hum once or twice isn't at all onerous. At least in this case, the drive-by emailers had to spend some thought cycles on the email they composed. Just because somebody is present at an IETF meeting to truly participate in working group A, doesn't mean they've invested much to casually swing by working group B and be a drive-by hummer. > And under IETF process, > concensus isn't determined in a F2F meeting. There is much lip-service about this, but in practice F2F meetings are given more importance in the deciding factors of the IETF. > The IETF is supposed to be fostering the engineering of the Internet. > Refusing to foster the engineering process based on religious or > political > or even phantom economic concerns doesn't foster better operation > of the > Internet. I agree with you in that these factors should not outweigh technical considerations. But the IETF should also not operate in a vacuum. That's the fastest way to irrelevance. > It is in the greater interest of the Internet to have ANY protocol > used to > define the meaning of some bits on the wires of the Internet well > documented. At least three reasons come to mind .. a) I can better > understand the impact of the protocol on other traffic and perhaps > even > document issues to the originator of the traffic if what I observe > doesn't > agree with the documentation AND seems to be causing my organization a > problem. b) Better to know about a documented patent claim than to > have it > hidden and waiting to bite me when I re-invent it, etc. c) Folks > concerned > about security vulnerabilities have starting point for their analysis These are all excellent points, but looking over this draft it is not obvious that there is a documented patent claim. I have to get to the boilerplate at the end, follow a link and do a bit of searching. Perhaps the IETF ought to consider a Known IPR Claims Section in drafts/RFCs. BTW, could a ToC be added to this doc before publication? -andy _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 13:45:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlpZW-0007ol-Mf; Sat, 27 Oct 2007 13:35:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlpZU-0007nn-Dk for ietf@ietf.org; Sat, 27 Oct 2007 13:35:40 -0400 Received: from [2002:9be6:9d5d:1::1] (helo=izb.knu.ac.kr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlpZR-0002Vo-44 for ietf@ietf.org; Sat, 27 Oct 2007 13:35:38 -0400 Received: by draba.izb.knu.ac.kr (Postfix, from userid 59) id 4E7793EA6; Sun, 28 Oct 2007 02:35:25 +0900 (KST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on draba.izb.knu.ac.kr X-Spam-Level: X-Spam-Status: No, score=-16.5 required=15.1 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VERIFIED autolearn=disabled version=3.2.3 X-Spam-Comment: DKIM? See http://www.google.com/search?btnI&q=RFC+4871 Received: from izb.knu.ac.kr (localhost.izb.knu.ac.kr [127.0.0.1]) by draba.izb.knu.ac.kr (Postfix) with ESMTP id 6733D3EA4; Sun, 28 Oct 2007 02:35:23 +0900 (KST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=izb.knu.ac.kr; h=subject: from:reply-to:to:cc:in-reply-to:references:content-type: content-transfer-encoding:date:message-id:mime-version; q= dns/txt; s=s1024; bh=a+UTHdff+bPvqFh7zMzgLYt12sQ=; b=Osm8Q+2EroA aHLByJhicbxaYtV/mLRQDTx3igkUPWS7NIDuBDIXAbLq02rG//5l8ZIxVCCJUSwe /62Yc8lRCC88eleuaQDjPD4E5gYKZdQ4rIbFt6W+s6nXxdgzZwpMrhx1KUFCDEEh n9OF7pG+E7WlNIVj9tfU/l8p1fwXrgCY= Received: from viola.izb.knu.ac.kr (viola.izb.knu.ac.kr [IPv6:2002:9be6:9d5d:3::3]) by draba.izb.knu.ac.kr (Postfix) with ESMTP id 4C8013E94; Sun, 28 Oct 2007 02:35:23 +0900 (KST) Received: by viola.izb.knu.ac.kr (Postfix, from userid 1001) id 5FB845E10; Sun, 28 Oct 2007 02:35:24 +0900 (KST) From: Byung-Hee HWANG To: "Joel M. Halpern" In-Reply-To: <20071027171104.A28507DB2@bender.tigertech.net> References: <2788466ED3E31C418E9ACC5C3166155707A4C9@mou1wnexmb09.vcorp.ad.vrsn.com> <1193503807.1088.21.camel@viola.izb.knu.ac.kr> <20071027171104.A28507DB2@bender.tigertech.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: InZealBomb Date: Sun, 28 Oct 2007 02:35:23 +0900 Message-Id: <1193506523.1088.32.camel@viola.izb.knu.ac.kr> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port X-Spam-Score: -1.4 (-) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ietf Subject: RE: A pattented standard is not a standard X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bh@izb.knu.ac.kr List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hello, On Sat, 2007-10-27 at 13:11 -0400, Joel M. Halpern wrote: > I actually strongly prefer reading top-postings. > More important content below, as a courtesy since you seem to prefer > postings in-line... > > At 12:50 PM 10/27/2007, you wrote: > >Dear Mr. Hallam-Baker, > > > >On Fri, 2007-10-26 at 11:35 -0700, Hallam-Baker, Phillip wrote: > > > Is this an official FSF campaign? > > > > > > My past experience is ... > >[...snip...] > > > >Hello, > > > >And please, you should be done bottom-posting. You may have a look > >. If you have another > >opinions, give me mail without any hesitancy. > > The important issue is that the IETF, and the IETF mailing lists, do > not have a policy on this matter. Therefore, it is up to the > individual posters how they choose to post, and it is quite > inappropriate to complain about the style another person > chooses. The issue of posting placement is an issue on which > reasonable people can and do differ. Okay i see. Never mind about that. Nevertheless, i will personally keep bottom-posting up. Sincerely, -- "I'll make him an offer he can't refuse." -- Michael Corleone, "Chapter 27", page 382 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 13:45:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlpbG-0000GT-1G; Sat, 27 Oct 2007 13:37:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlpbE-0000GE-O6 for ietf@ietf.org; Sat, 27 Oct 2007 13:37:28 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ilpb8-0002XP-KV for ietf@ietf.org; Sat, 27 Oct 2007 13:37:28 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sat, 27 Oct 2007 13:36:51 -0400 id 01588692.47237733.000003F7 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Sat, 27 Oct 2007 13:36:24 -0400 To: David Morris X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ietf@ietf.org Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 27, 2007, at 11:00 AM, David Morris wrote: > Well for starters, the drive-by hummers have to sit through the > session > and be present for the discussion (note I intentionally did not say > listen). They have to demonstrate enough interest in the IETF > process to > actually pay the costs of attending the session. Most of the drive-by hummers have their head buried in their email or other laptop work, so the expense they run for looking up to hum once or twice isn't at all onerous. At least in this case, the drive-by emailers had to spend some thought cycles on the email they composed. Just because somebody is present at an IETF meeting to truly participate in working group A, doesn't mean they've invested much to casually swing by working group B and be a drive-by hummer. > And under IETF process, > concensus isn't determined in a F2F meeting. There is much lip-service about this, but in practice F2F meetings are given more importance in the deciding factors of the IETF. > The IETF is supposed to be fostering the engineering of the Internet. > Refusing to foster the engineering process based on religious or > political > or even phantom economic concerns doesn't foster better operation > of the > Internet. I agree with you in that these factors should not outweigh technical considerations. But the IETF should also not operate in a vacuum. That's the fastest way to irrelevance. > It is in the greater interest of the Internet to have ANY protocol > used to > define the meaning of some bits on the wires of the Internet well > documented. At least three reasons come to mind .. a) I can better > understand the impact of the protocol on other traffic and perhaps > even > document issues to the originator of the traffic if what I observe > doesn't > agree with the documentation AND seems to be causing my organization a > problem. b) Better to know about a documented patent claim than to > have it > hidden and waiting to bite me when I re-invent it, etc. c) Folks > concerned > about security vulnerabilities have starting point for their analysis These are all excellent points, but looking over this draft it is not obvious that there is a documented patent claim. I have to get to the boilerplate at the end, follow a link and do a bit of searching. Perhaps the IETF ought to consider a Known IPR Claims Section in drafts/RFCs. BTW, could a ToC be added to this doc before publication? -andy _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 13:45:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlpZW-0007ol-Mf; Sat, 27 Oct 2007 13:35:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlpZU-0007nn-Dk for ietf@ietf.org; Sat, 27 Oct 2007 13:35:40 -0400 Received: from [2002:9be6:9d5d:1::1] (helo=izb.knu.ac.kr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlpZR-0002Vo-44 for ietf@ietf.org; Sat, 27 Oct 2007 13:35:38 -0400 Received: by draba.izb.knu.ac.kr (Postfix, from userid 59) id 4E7793EA6; Sun, 28 Oct 2007 02:35:25 +0900 (KST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on draba.izb.knu.ac.kr X-Spam-Level: X-Spam-Status: No, score=-16.5 required=15.1 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VERIFIED autolearn=disabled version=3.2.3 X-Spam-Comment: DKIM? See http://www.google.com/search?btnI&q=RFC+4871 Received: from izb.knu.ac.kr (localhost.izb.knu.ac.kr [127.0.0.1]) by draba.izb.knu.ac.kr (Postfix) with ESMTP id 6733D3EA4; Sun, 28 Oct 2007 02:35:23 +0900 (KST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=izb.knu.ac.kr; h=subject: from:reply-to:to:cc:in-reply-to:references:content-type: content-transfer-encoding:date:message-id:mime-version; q= dns/txt; s=s1024; bh=a+UTHdff+bPvqFh7zMzgLYt12sQ=; b=Osm8Q+2EroA aHLByJhicbxaYtV/mLRQDTx3igkUPWS7NIDuBDIXAbLq02rG//5l8ZIxVCCJUSwe /62Yc8lRCC88eleuaQDjPD4E5gYKZdQ4rIbFt6W+s6nXxdgzZwpMrhx1KUFCDEEh n9OF7pG+E7WlNIVj9tfU/l8p1fwXrgCY= Received: from viola.izb.knu.ac.kr (viola.izb.knu.ac.kr [IPv6:2002:9be6:9d5d:3::3]) by draba.izb.knu.ac.kr (Postfix) with ESMTP id 4C8013E94; Sun, 28 Oct 2007 02:35:23 +0900 (KST) Received: by viola.izb.knu.ac.kr (Postfix, from userid 1001) id 5FB845E10; Sun, 28 Oct 2007 02:35:24 +0900 (KST) From: Byung-Hee HWANG To: "Joel M. Halpern" In-Reply-To: <20071027171104.A28507DB2@bender.tigertech.net> References: <2788466ED3E31C418E9ACC5C3166155707A4C9@mou1wnexmb09.vcorp.ad.vrsn.com> <1193503807.1088.21.camel@viola.izb.knu.ac.kr> <20071027171104.A28507DB2@bender.tigertech.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: InZealBomb Date: Sun, 28 Oct 2007 02:35:23 +0900 Message-Id: <1193506523.1088.32.camel@viola.izb.knu.ac.kr> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port X-Spam-Score: -1.4 (-) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ietf Subject: RE: A pattented standard is not a standard X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bh@izb.knu.ac.kr List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hello, On Sat, 2007-10-27 at 13:11 -0400, Joel M. Halpern wrote: > I actually strongly prefer reading top-postings. > More important content below, as a courtesy since you seem to prefer > postings in-line... > > At 12:50 PM 10/27/2007, you wrote: > >Dear Mr. Hallam-Baker, > > > >On Fri, 2007-10-26 at 11:35 -0700, Hallam-Baker, Phillip wrote: > > > Is this an official FSF campaign? > > > > > > My past experience is ... > >[...snip...] > > > >Hello, > > > >And please, you should be done bottom-posting. You may have a look > >. If you have another > >opinions, give me mail without any hesitancy. > > The important issue is that the IETF, and the IETF mailing lists, do > not have a policy on this matter. Therefore, it is up to the > individual posters how they choose to post, and it is quite > inappropriate to complain about the style another person > chooses. The issue of posting placement is an issue on which > reasonable people can and do differ. Okay i see. Never mind about that. Nevertheless, i will personally keep bottom-posting up. Sincerely, -- "I'll make him an offer he can't refuse." -- Michael Corleone, "Chapter 27", page 382 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 14:51:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlqZR-0000bQ-2O; Sat, 27 Oct 2007 14:39:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlqZP-0000Hr-Sm for ietf@ietf.org; Sat, 27 Oct 2007 14:39:39 -0400 Received: from rv-out-0910.google.com ([209.85.198.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlqZ0-0004Kx-Eb for ietf@ietf.org; Sat, 27 Oct 2007 14:39:20 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1012017rvb for ; Sat, 27 Oct 2007 11:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=HxZDeU3fkExAlZiCxBE8yDqCKXNJhEXGwOXpoj/WXB8=; b=ZCoEov6PCRZPecea6hgV3a5L+tqQLNaDHtx4TKTUnFRv5Q1qhZmOyd9Q5qDmGxZqcq75NZAAxQFQqJGfyPx2LjkwZ7bDcRcZtRg6J71GbI51zC0xm87dekTA+QiUBKqbSNfuCfm0sWkcKJvZnVjcG8gonMTLFu+FTZQ1PImdtg0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mTdnwbkYG3e+ZPFTAAiKLy1YxxRW6f/iSMDES/SrOJvVtn6CveSoMcrWmmdw92kr78RfXKdCjLpZNXxr3fZFdHqsQFmhBB8THXSWJSwCJipC5Cc6frEA5fDuTMVtZPszVh81DIhQN+sD9x/0Yoi1kJwQpoe29jmpf/NTIGLJWUA= Received: by 10.142.79.15 with SMTP id c15mr1085436wfb.1193510323843; Sat, 27 Oct 2007 11:38:43 -0700 (PDT) Received: by 10.142.84.17 with HTTP; Sat, 27 Oct 2007 11:38:43 -0700 (PDT) Message-ID: <9a8fa98b0710271138h1f2b3f03w4281186c24671b47@mail.gmail.com> Date: Sat, 27 Oct 2007 19:38:43 +0100 From: "Rob Evans" To: "Andrew Newton" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ietf@ietf.org Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > > And under IETF process, > > concensus isn't determined in a F2F meeting. > > There is much lip-service about this, but in practice F2F meetings > are given more importance in the deciding factors of the IETF. In my (limited) experience, that very much depends. If the topic does not have much correspondence on a mailing list, then a hum in a room can certainly outweigh the deafening silence of a last-call on a list. If there is much discussion on a list, then that does tend to drown out the background hum of the physical meeting. Of course, your experience may differ. Cheers, Rob _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 14:59:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlqmT-0000yP-He; Sat, 27 Oct 2007 14:53:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlqmS-0000xV-6n for ietf@ietf.org; Sat, 27 Oct 2007 14:53:08 -0400 Received: from rv-out-0910.google.com ([209.85.198.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlqmM-0004jR-07 for ietf@ietf.org; Sat, 27 Oct 2007 14:53:08 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1014364rvb for ; Sat, 27 Oct 2007 11:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=aV4y8sBbvS+X1HQm3J0/zTNec1pTokd2oE4pqOgziEs=; b=iV+VjrAKAw1Cw6Mgq+Y8KgFbrCckgTI/c9b4QxGH6YbKVnfPAozeCSVWjmZj1vu1J3JM+T36teqQDtosxTFEThsSPUoMEkSLsVme4oaFGv27yEJ88QLR3n7ehTiEKC7Jy1XNhj38qXqarVHnFGBmoo7XKogPqkCwqw9KPYh/3eA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=IzXWfwjqbZnFRe2BniV9VA4ppemJrcdlIVb4n/9zzw9nl5TjQonI7rG8s0SFS9jwn8Rd+6RUeD+CNdYUqLkafPcYBJgdBZ+1NP/ZUlfmqRg9MAiAvXrk139w7EcROIeId1Rt1kadgQbJNg4iUcbTvlsetV2ylCv7STVmyHabj/g= Received: by 10.141.89.13 with SMTP id r13mr2094905rvl.1193511159304; Sat, 27 Oct 2007 11:52:39 -0700 (PDT) Received: from ?10.1.1.7? ( [222.153.14.113]) by mx.google.com with ESMTPS id f13sm7972105rvb.2007.10.27.11.52.36 (version=SSLv3 cipher=RC4-MD5); Sat, 27 Oct 2007 11:52:38 -0700 (PDT) Message-ID: <472388E9.8070700@gmail.com> Date: Sun, 28 Oct 2007 07:52:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andrew Newton References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ietf@ietf.org Subject: Non-participants [Re: Experimental makes sense for tls-authz] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-28 06:36, Andrew Newton wrote: > > On Oct 27, 2007, at 11:00 AM, David Morris wrote: >> Well for starters, the drive-by hummers have to sit through the session >> and be present for the discussion (note I intentionally did not say >> listen). They have to demonstrate enough interest in the IETF process to >> actually pay the costs of attending the session. > > Most of the drive-by hummers have their head buried in their email or > other laptop work, so the expense they run for looking up to hum once or > twice isn't at all onerous. At least in this case, the drive-by > emailers had to spend some thought cycles on the email they composed. [By the way, when I find myself in a WG meeting I'm not prepared for, I often have my head buried in the drafts being discussed, so as to be able to understand the issues. Don't assume that a head buried in a laptop is always doing email.] Firstly, apparent consensus in a WG face to face meeting is *not* consensus of the WG, which must be confirmed on the mailing list. Secondly, WG chairs and the responsible AD are well able to notice that a meeting has been packed, and to interpret any straw poll or hum accordingly. I think the process has proved to be rather resistant to packing of meetings, written statements distributed in the meeting room, and back-channel campaigns to have non-participants commenting on drafts they haven't read. None of which means we should *ignore* input from non-participants, but we should not be ashamed of making a judgement of its weight or lack thereof. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 19:37:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilupy-0002XO-P7; Sat, 27 Oct 2007 19:13:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilupx-0002XI-GK for ietf@ietf.org; Sat, 27 Oct 2007 19:13:01 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ilupq-00053h-Ea for ietf@ietf.org; Sat, 27 Oct 2007 19:13:01 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 98FF02596E7; Sun, 28 Oct 2007 01:12:48 +0200 (CEST) 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 32033-02; Sun, 28 Oct 2007 01:12:40 +0200 (CEST) Received: from htat43p-no.corp.google.com (unknown [65.91.246.2]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4E3292596E8; Sun, 28 Oct 2007 01:12:39 +0200 (CEST) Date: Sat, 27 Oct 2007 21:33:05 +0200 From: Harald Tveit Alvestrand To: Ismael Jones , ietf@ietf.org Message-ID: <0F055066A1161CC3198AC2D9@B50854F0A9192E8EC6CDA126> In-Reply-To: <20071019488.4885591192833263@tusojos.com> References: <20071019488.4885591192833263@tusojos.com> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 1.4 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: campaigns@fsf.org Subject: Re: Please reject proprietary standards. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org --On 19. oktober 2007 17:34 -0500 Ismael Jones wrote: > Best IETF, > > In response to the recent TLS submission, I would like to ask you > sincerely to reject at all levels any standard which relies on > proprietary or otherwise commercially-based technologies. Thank you very > much for your consideration. Dear letter-sender, I am happy to invite you to sign up to the IETF list (or the IETF's IPR WG list) in order to discuss these matters. It should be entertaining to read your detailed definition of "commercially-based technologies", since this is a term I have not heard before, and where my intuitive understanding of the term HAS to be wrong, since it would argue against standardization of such non-IETF technologies as Ethernet, electrical sockets, the CD record and the threads of screws. Just to mention a few examples of non-IETF standards; I'll let identification of relevant IETF standards that are "commercially-based" wait until I hear your definition of the term. Regards, Harald Alvestrand, chair of the IETF IPR WG _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 19:37:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IluwY-0006Jp-5v; Sat, 27 Oct 2007 19:19:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IluwX-0006Ji-45 for ietf@ietf.org; Sat, 27 Oct 2007 19:19:49 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IluwR-0005IJ-Cv for ietf@ietf.org; Sat, 27 Oct 2007 19:19:49 -0400 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9RNIeda024860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 27 Oct 2007 16:18:40 -0700 (PDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id l9RNIeEf024859; Sat, 27 Oct 2007 16:18:40 -0700 (PDT) Date: Sat, 27 Oct 2007 16:18:40 -0700 From: Bill Manning To: Brian E Carpenter Message-ID: <20071027231840.GA23714@boreas.isi.edu> References: <472388E9.8070700@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <472388E9.8070700@gmail.com> User-Agent: Mutt/1.4.2.2i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@boreas.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ietf@ietf.org Subject: Re: Non-participants [Re: Experimental makes sense for tls-authz] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Sun, Oct 28, 2007 at 07:52:25AM +1300, Brian E Carpenter wrote: > > I think the process has proved to be rather resistant to packing of > meetings, written statements distributed in the meeting room, and > back-channel campaigns to have non-participants commenting on drafts > they haven't read. None of which means we should *ignore* input from > non-participants, but we should not be ashamed of making a judgement > of its weight or lack thereof. > all of those activites indicate particpation to me. could you please clarify "non-participant" in the context of someone making a contribution (pro or con, independently or in concert with others). perhaps you have in mind "card-carrying" IETF members who pay their dues and send their employees to meetings? -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 19:41:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlvB2-0005IB-15; Sat, 27 Oct 2007 19:34:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlvB0-0005HH-BT for ietf@ietf.org; Sat, 27 Oct 2007 19:34:46 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlvB0-0004b2-1K for ietf@ietf.org; Sat, 27 Oct 2007 19:34:46 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 69D1E2596DB for ; Sun, 28 Oct 2007 01:34:45 +0200 (CEST) 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 32033-10 for ; Sun, 28 Oct 2007 01:34:36 +0200 (CEST) Received: from htat43p-no.corp.google.com (unknown [65.91.246.2]) by eikenes.alvestrand.no (Postfix) with ESMTP id 068232596E7 for ; Sun, 28 Oct 2007 01:34:35 +0200 (CEST) Date: Sun, 28 Oct 2007 01:32:01 +0200 From: Harald Tveit Alvestrand To: ietf@ietf.org Message-ID: <8434A8C6C4340EF7F86FFB33@B50854F0A9192E8EC6CDA126> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: Musical commentary from the RIPE meeting X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Can't believe nobody else posted first.... _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 20:49:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilw2D-0007J3-0N; Sat, 27 Oct 2007 20:29:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilw2B-00079t-OU for ietf@ietf.org; Sat, 27 Oct 2007 20:29:43 -0400 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ilw2B-0006LV-B1 for ietf@ietf.org; Sat, 27 Oct 2007 20:29:43 -0400 Received: from [192.168.0.3] (adsl-68-122-116-197.dsl.pltn13.pacbell.net [68.122.116.197]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l9S0TKLp030809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Oct 2007 17:29:20 -0700 Message-ID: <4723D7F3.1090408@dcrocker.net> Date: Sat, 27 Oct 2007 17:29:39 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Harald Tveit Alvestrand References: <8434A8C6C4340EF7F86FFB33@B50854F0A9192E8EC6CDA126> In-Reply-To: <8434A8C6C4340EF7F86FFB33@B50854F0A9192E8EC6CDA126> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ietf@ietf.org Subject: Re: Musical commentary from the RIPE meeting X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Harald Tveit Alvestrand wrote: > Can't believe nobody else posted first.... OMG. Can't believe how stellar the words and the performance were. Net Ops has moved into needing awards for "Oscar-worthy" efforts. Thank you SO much for posting that. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 21:04:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlwRK-0001yX-Vd; Sat, 27 Oct 2007 20:55:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlwRJ-0001xJ-5a for ietf@ietf.org; Sat, 27 Oct 2007 20:55:41 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlwRD-0000X1-0L for ietf@ietf.org; Sat, 27 Oct 2007 20:55:41 -0400 Received: from newton603 (c-24-61-11-96.hsd1.nh.comcast.net[24.61.11.96]) by comcast.net (rwcrmhc12) with SMTP id <20071028005518m1200gsfise>; Sun, 28 Oct 2007 00:55:19 +0000 From: "David B. Nelson" To: References: <8434A8C6C4340EF7F86FFB33@B50854F0A9192E8EC6CDA126> Date: Sat, 27 Oct 2007 20:55:20 -0400 Message-ID: <015a01c818fd$37925ab0$031716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <8434A8C6C4340EF7F86FFB33@B50854F0A9192E8EC6CDA126> thread-index: AcgY8uCjC/PVuQ8FRHGW0F9G1oLGbQACjOrw X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: RE: Musical commentary from the RIPE meeting X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Harald Tveit Alvestrand writes... > Can't believe nobody else posted first.... > > LOL. This is priceless... _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sat Oct 27 21:30:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilwn4-0001Ti-Cx; Sat, 27 Oct 2007 21:18:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilwn2-0001TY-G4 for ietf@ietf.org; Sat, 27 Oct 2007 21:18:08 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ilwmw-0001Ad-9z for ietf@ietf.org; Sat, 27 Oct 2007 21:18:08 -0400 X-IronPort-AV: E=Sophos;i="4.21,338,1188802800"; d="scan'208";a="183385347" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2007 18:16:56 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9S1Guh2023733; Sat, 27 Oct 2007 18:16:56 -0700 Received: from pita.cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l9S1GuTh016644; Sun, 28 Oct 2007 01:16:56 GMT Date: Sat, 27 Oct 2007 18:15:26 -0700 (PDT) From: Ole Jacobsen To: "David B. Nelson" In-Reply-To: <015a01c818fd$37925ab0$031716ac@NEWTON603> Message-ID: References: <8434A8C6C4340EF7F86FFB33@B50854F0A9192E8EC6CDA126> <015a01c818fd$37925ab0$031716ac@NEWTON603> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=805; t=1193534216; x=1194398216; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ole@cisco.com; z=From:=20Ole=20Jacobsen=20 |Subject:=20RE=3A=20Musical=20commentary=20from=20the=20RIPE=20meeting |Sender:=20; bh=Es1XFb0CnRhgAoGf8vh/mG+8yz2gYvwOnqVU+VRkh9M=; b=dnkQw51VhFebyqri5jneZC5de6L4TGsYIEyt1LddFkA6y14QH8sxPoJxfTWSeJnbb7I7ejM6 fd7N+xjleRNup/kL9hx/oMT9R66QIHOEuJI4Lh7tOq54KDfMiAyFGJzd; Authentication-Results: sj-dkim-3; header.From=ole@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ietf@ietf.org Subject: RE: Musical commentary from the RIPE meeting X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ole Jacobsen List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Can we invite him to the IETF plenary in Vancouver? It's wonderful, and I will clearly have to come up with some kind of "organdemo +" event in the future that does include performances like this one. Meanwhile, I did at least go to Haarlem to check out the Muller organ for a possible future event: http://www.yikes.com/~ole/BavoHaarlem/index-all.html Enjoy... Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: ole@cisco.com URL: http://www.cisco.com/ipj On Sat, 27 Oct 2007, David B. Nelson wrote: > Harald Tveit Alvestrand writes... > > > Can't believe nobody else posted first.... > > > > > > LOL. This is priceless... > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Oct 28 03:32:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Im29E-0006v7-Vw; Sun, 28 Oct 2007 03:01:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Im29D-0006uw-B4 for ietf@ietf.org; Sun, 28 Oct 2007 03:01:23 -0400 Received: from s-dc-exrq03.rcnet.cec.eu.int ([147.67.241.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Im295-0000xw-2f for ietf@ietf.org; Sun, 28 Oct 2007 03:01:21 -0400 Received: from S-DC-EXRJ80.net1.cec.eu.int ([158.167.59.167]) by s-dc-exrq03.rcnet.cec.eu.int with Microsoft SMTPSVC(6.0.3790.2499); Sun, 28 Oct 2007 08:00:53 +0100 Received: from S-DC-EXM15.net1.cec.eu.int ([158.167.183.14]) by S-DC-EXRJ80.net1.cec.eu.int with Microsoft SMTPSVC(6.0.3790.2499); Sun, 28 Oct 2007 08:00:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 28 Oct 2007 07:56:16 +0100 Message-ID: <971D6191A3F4BA4FB9223EAE77C57A360329D73C@S-DC-EXM15.net1.cec.eu.int> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Musical commentary from the RIPE meeting Thread-Index: AcgY8wi3ZzBJYLjdQd62NcrWj0K6LgAPJnKh References: <8434A8C6C4340EF7F86FFB33@B50854F0A9192E8EC6CDA126> From: To: X-OriginalArrivalTime: 28 Oct 2007 07:00:53.0972 (UTC) FILETIME=[48275140:01C81930] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: RE: Musical commentary from the RIPE meeting X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1278515375==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============1278515375== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81930.479C5752" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81930.479C5752 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable And so you can sing along... The words can be found at the usual place: http://www.secret-wg.org/Secret-Archive/ :-) Gordon -----Original Message----- From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] Sent: Sun 10/28/2007 1:32 AM To: ietf@ietf.org Subject: Musical commentary from the RIPE meeting =20 Can't believe nobody else posted first.... _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ------_=_NextPart_001_01C81930.479C5752 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Musical commentary from the RIPE meeting

And so you can sing along...

The words can be found at the usual place:

http://www.secret-wg.or= g/Secret-Archive/

:-)

Gordon

-----Original Message-----
From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no]
= Sent: Sun 10/28/2007 1:32 AM
To: ietf@ietf.org
Subject: Musical commentary from the RIPE meeting

Can't believe nobody else posted first....

<http://youtube.com/watc= h?v=3D_y36fG2Oba0>


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.or= g/mailman/listinfo/ietf


------_=_NextPart_001_01C81930.479C5752-- --===============1278515375== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============1278515375==-- From ietf-bounces@ietf.org Sun Oct 28 12:35:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImAeO-00044m-Kb; Sun, 28 Oct 2007 12:06:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImAeN-00044g-Ct for ietf@ietf.org; Sun, 28 Oct 2007 12:06:07 -0400 Received: from wr-out-0506.google.com ([64.233.184.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImAeI-000880-7n for ietf@ietf.org; Sun, 28 Oct 2007 12:06:07 -0400 Received: by wr-out-0506.google.com with SMTP id 70so864345wra for ; Sun, 28 Oct 2007 09:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=5SkYwPwq43seCtrouSE3HGjzqIMlvhXgR9JysBnXRl0=; b=gXTYIt4jGDXQPoSxUP8oYpD8gFj9QvMn1ddxsGh8/xca2x5bEW0PNSXlEy5rdAcMninO7bWNAXkQhhs74hcpgX/fpLvq1oRcjxKwV61w6fY0gjmNOkDTQ/Tyh8CfQ8JGove8/7jAdgvleiMjlD1UjYrAE2a4XDR6v1fLmgHGJ5w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=A/J7HqJLiyIz7laQttITI1R27hAHz/NlAdZWJ8Q3IXTK0G5C1GPUBYSYbK2MmIAV/RHzzP3rLaKpXe2ckAQ3AqKs+UW337U7s8eY0QOIDtVXGXNhXVWv2+R/LJgsyxRyDlzqUQbU1VFU88n1XOd3fptQScmOOhuoftMvEqqmQKA= Received: by 10.90.117.1 with SMTP id p1mr3948095agc.1193587542681; Sun, 28 Oct 2007 09:05:42 -0700 (PDT) Received: by 10.90.97.17 with HTTP; Sun, 28 Oct 2007 09:05:42 -0700 (PDT) Message-ID: Date: Sun, 28 Oct 2007 09:05:42 -0700 From: "Bill Fenner" To: "Andrew Newton" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ietf@ietf.org Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 10/27/07, Andrew Newton wrote: > These are all excellent points, but looking over this draft it is not > obvious that there is a documented patent claim. I have to get to > the boilerplate at the end, follow a link and do a bit of searching. > Perhaps the IETF ought to consider a Known IPR Claims Section in > drafts/RFCs. RFC 2026, section 10.4.(D), gives boilerplate to add to a document where there is known ipr: "The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights." RFC 3667 removed this policy, because the absence of a notice in the document doesn't mean that an ipr claim wasn't filed after the RFC was published. A notice can only tell you that there is a claim, but the absence of a notice only means that there was no claim at the time of publication, not that there is no claim. Changing this back would be a topic for the ipr wg. Bill _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Oct 28 16:36:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImEVI-0001Kd-RK; Sun, 28 Oct 2007 16:13:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImEVH-0001IC-IY for ietf@ietf.org; Sun, 28 Oct 2007 16:12:59 -0400 Received: from rv-out-0910.google.com ([209.85.198.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImEVB-0000XW-Cn for ietf@ietf.org; Sun, 28 Oct 2007 16:12:59 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1213608rvb for ; Sun, 28 Oct 2007 13:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=GmuL92BvIDifTOYqJSU9H5veIXrpaJDNWCuMnGj54pw=; b=p3soKlCyFdsVEcf7cTC3u56KrWip0rzVdZu5ncrg9Gx83JdsWRBql+6z6W6UFU4BM1ybX5nRfXIzVXPbZ8Gc/VW1ty598+G9aNBVUBcMK7qPxVRkrqlrsslZqeKcuwradrCYoEJzRvLyuWU6TDZ5FnN/ZQcplu9/rVgVNAapsZo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=iB89nIc2QZy9OT+Y6Zg+q3YlSgRXTOZPBcAnhRBvKGJHJzmt0zIpyES2vhFMMSHz3a0mm/1ENt09teSvBQOePpqn14bIfueTJV8moK/DTp6lACNNDuVxdaqKRW7qfDJneIZRYx2wZIgzNM3wU+pgEDeDDAOM0T2Hsa15z95zCCI= Received: by 10.141.35.21 with SMTP id n21mr2436445rvj.1193602350815; Sun, 28 Oct 2007 13:12:30 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id g39sm11065897rvb.2007.10.28.13.12.29 (version=SSLv3 cipher=RC4-MD5); Sun, 28 Oct 2007 13:12:30 -0700 (PDT) Message-ID: <4724ED26.20404@gmail.com> Date: Mon, 29 Oct 2007 09:12:22 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Bill Manning References: <472388E9.8070700@gmail.com> <20071027231840.GA23714@boreas.isi.edu> In-Reply-To: <20071027231840.GA23714@boreas.isi.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ietf@ietf.org Subject: Re: Non-participants [Re: Experimental makes sense for tls-authz] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-28 12:18, Bill Manning wrote: > On Sun, Oct 28, 2007 at 07:52:25AM +1300, Brian E Carpenter wrote: >> I think the process has proved to be rather resistant to packing of >> meetings, written statements distributed in the meeting room, and >> back-channel campaigns to have non-participants commenting on drafts >> they haven't read. None of which means we should *ignore* input from >> non-participants, but we should not be ashamed of making a judgement >> of its weight or lack thereof. >> > > all of those activites indicate particpation to me. > could you please clarify "non-participant" in the > context of someone making a contribution (pro or con, > independently or in concert with others). Contributing technical input to the discussion of a technical proposal. > > perhaps you have in mind "card-carrying" IETF members > who pay their dues and send their employees to meetings? No. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Oct 28 16:53:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImExe-0001fk-Hp; Sun, 28 Oct 2007 16:42:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImExc-0001fP-JJ for ietf@ietf.org; Sun, 28 Oct 2007 16:42:16 -0400 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImExc-00016q-5o for ietf@ietf.org; Sun, 28 Oct 2007 16:42:16 -0400 Received: from [192.168.0.3] (adsl-68-122-116-197.dsl.pltn13.pacbell.net [68.122.116.197]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l9SKfr9J008665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 28 Oct 2007 12:41:53 -0800 Message-ID: <4724F424.6050903@dcrocker.net> Date: Sun, 28 Oct 2007 13:42:12 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ietf@ietf.org References: <8434A8C6C4340EF7F86FFB33@B50854F0A9192E8EC6CDA126> <971D6191A3F4BA4FB9223EAE77C57A360329D73C@S-DC-EXM15.net1.cec.eu.int> In-Reply-To: <971D6191A3F4BA4FB9223EAE77C57A360329D73C@S-DC-EXM15.net1.cec.eu.int> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: Re: Musical commentary from the RIPE meeting X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org also at the youtube site. under the Subscribe button is a 'more info' link. d/ Gordon.Lennox@ec.europa.eu wrote: > And so you can sing along... > > The words can be found at the usual place: > > http://www.secret-wg.org/Secret-Archive/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Oct 28 17:51:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImFnN-0005ln-2C; Sun, 28 Oct 2007 17:35:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImFnE-0005cw-Sp for ietf@ietf.org; Sun, 28 Oct 2007 17:35:36 -0400 Received: from relay1.mail.vrmd.de ([81.28.232.18]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImFnD-00032d-GN for ietf@ietf.org; Sun, 28 Oct 2007 17:35:36 -0400 Received: from [87.79.236.249] (helo=[192.168.1.102]) by relay1.mail.vrmd.de with esmtpa (Exim 4.60) (envelope-from ) id 1ImFnA-00045q-3X for ietf@ietf.org; Sun, 28 Oct 2007 22:35:32 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <4724F424.6050903@dcrocker.net> References: <8434A8C6C4340EF7F86FFB33@B50854F0A9192E8EC6CDA126> <971D6191A3F4BA4FB9223EAE77C57A360329D73C@S-DC-EXM15.net1.cec.eu.int> <4724F424.6050903@dcrocker.net> X-Gpgmail-State: !signed Message-Id: From: Marc Manthey Date: Sun, 28 Oct 2007 22:35:00 +0100 To: ietf@ietf.org X-Mailer: Apple Mail (2.752.2) X-Relay-User: marc@let.de X-Spam-Score: 0.1 (/) X-Scan-Signature: bfef20db74c24e87b6dbcd42ea7ba67c Subject: Re: Musical commentary from the RIPE meeting X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0073046367==" Errors-To: ietf-bounces@ietf.org --===============0073046367== Content-Type: multipart/alternative; boundary=Apple-Mail-10-551735518 --Apple-Mail-10-551735518 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; format=flowed A long long time ago i can still remeber when my labtop could connect elswhere and i tell you all there was a day the network card i threw away had a purpose - and worked for you and me But 18 years complety wasted with each adress we=B4ve aggregated the tables overflowing the traffic just stopped flowing And now we=B4re bearing all the scars and all the traceroutes showing stars the packets would travel faster in cars... the day... the routers died ------------- Chorus ( ALL ) So bye bye , folks at RIPE 55 be persuaded zo upgrade it or your network will die Ipv6 just makes me let out a sight But i spose we=B4d better give it a try I suppose we=B4d better give it a try --------- Now did you write an RFC That dictated how we all should be Did we listen like we should that day Now were you back at RIPE fifty-four Where we heard the same things month before And people knew they=B4d have to change their ways... And we - knew that all ISPs Could be - future proof for centuries But that was then not now Spend too much time playing WOW ooh there was time we sat on IRC making jokes on how this day would be Now there=B4s no more use for TCP they day the routers died ------------- Chorus ( chime in now ) So bye bye , folks at RIPE 55 be persuaded zo upgrade it or your network will die Ipv6 just makes me let out a sight But i spose we=B4d better give it a try I suppose we=B4d better give it a try --------- i remember those old days i mourn Sitting in my room , downloading porn Yeah that=B4s how it used to be... When the packets flowed from A to B via routers that could talk IP there was data... that could be exchanged between you and me... Oh but- i could see you all ignore The fact - we=B4d fill up IPv4 But we all lost the nerve And we goz what we deserved ! And while... we threw our network kit away And wished we=B4d heard the things they say Put all our lives in disarray the day ... the routers died ------------- Chorus ( those silent will be shot ) So bye bye , folks at RIPE 55 be persuaded zo upgrade it or your network will die Ipv6 just makes me let out a sight But i spose we=B4d better give it a try I suppose we=B4d better give it a try --------- Saw a man with whom i used to peer Asked him to rescue my career He just sighed and turned away I went down to the net cafe that I used to visit everyday But the man there said i might as well just leave And now we=B4ve all lost our purpose my cisco shares completely worthless No future meetings for me At Hotel Krasnapolsky and me that make us push and push Like Geoff Huston and Rady Bush Should=B4ve listened to what they told us.... The day... the routers. died ------------- Chorus ( time to loose your voice ) So bye bye , folks at RIPE 55 be persuaded zo upgrade it or your network will die Ipv6 just makes me let out a sight But i spose we=B4d better give it a try I suppose we=B4d better give it a try --------- cheers Marc -- They said it couldn't be done but sometimes it doesn't work out that way. - Casey Stengel web: http://www.let.de READY FOR A CHANGE http://int.piratenpartei.de/List_of_Pirateparties --Apple-Mail-10-551735518 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
A=A0long long = time ago

i can still remeber
when my = labtop could connect elswhere
and i tell = you all there was a day
the network = card i threw away
had a purpose - and worked for = you and me
But 18 years complety = wasted

with each adress we=B4ve aggregated
the tables overflowing
the = traffic just stopped flowing

And now we=B4re bearing all the scars
and all the traceroutes showing stars
the packets would travel faster in cars...
the day... the routers died
-------------
Chorus=A0 = =A0(=A0ALL )
So bye bye , folks at RIPE = 55
be persuaded zo upgrade it or your network will = die

Ipv6 just makes me let out a sight
But i spose we=B4d better give it a try
I suppose we=B4d better give it a try


Now did you write an RFC
That dictated how we all should be
Did we listen like we should that day
Now were you back at RIPE fifty-four
Where we heard the same things month = before
And people knew they=B4d have to = change their ways...
And we - knew that all = ISPs=A0
Could be - future proof for = centuries
But that was then not = now
Spend too much time playing = WOW
ooh there was time we sat on = IRC
making jokes on how this day = would be
Now there=B4s no more use for = TCP
they day the routers = died

-------------
Chorus (=A0 = chime in now )
So bye bye , folks at RIPE = 55
be persuaded zo upgrade it or your network will = die
Ipv6 just makes me let out a = sight
But i spose we=B4d better give = it a try
I suppose we=B4d better give it = a try

---------

i remember those old days i mourn
Sitting in my room , downloading porn
Yeah that=B4s how it used to be...
When the packets flowed from A to B
via routers that could talk IP
there was data... that could be exchanged
between you and me...
Oh but- i could see you all = ignore
The fact - we=B4d fill up = IPv4
But we all lost the = nerve
And we goz what we deserved = !
And while... we threw our network kit = away
And wished we=B4d heard the = things they say
Put all our lives in = disarray
the day ... the routers = died

-------------
Chorus =A0 ( = those silent will be shot )
So bye bye , = folks at RIPE 55
be persuaded zo upgrade it or = your network will die
Ipv6 just makes me let out = a sight
But i spose we=B4d better give = it a try
I suppose we=B4d better give it = a try

---------

Saw a man with whom i used to peer
Asked him to rescue my career
He just sighed and turned away
I went down to the net cafe
that I used to visit everyday
But the man there said i might as well just = leave

And now we=B4ve= all lost our purpose
my cisco shares completely = worthless
No future meetings for = me
At Hotel Krasnapolsky
and me that make us push and push
Like Geoff Huston and Rady Bush
Should=B4ve listened to what they told = us....
The day... the routers. = died

-------------
Chorus =A0 ( = time to loose your voice )
So bye bye , = folks at RIPE 55
be persuaded zo upgrade it or = your network will die
Ipv6 just makes me let out = a sight
But i spose we=B4d better give = it a try
I suppose we=B4d better give it = a try

---------

cheers=A0

Marc
--
They said it couldn't be = done but sometimes it
doesn't work out that = way.
=A0=A0- Casey Stengel


READY FOR A = CHANGE

= --Apple-Mail-10-551735518-- --===============0073046367== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0073046367==-- From ietf-bounces@ietf.org Sun Oct 28 20:22:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImI5b-000593-1w; Sun, 28 Oct 2007 20:02:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImI5V-00058h-Mi for ietf@ietf.org; Sun, 28 Oct 2007 20:02:37 -0400 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImI5M-0000yk-3n for ietf@ietf.org; Sun, 28 Oct 2007 20:02:37 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 0D4345C84F for ; Mon, 29 Oct 2007 00:02:18 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <917D43E5-30EF-49A9-9DD3-02DC87A35AD4@insensate.co.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF Discussion From: lconroy Date: Mon, 29 Oct 2007 00:02:09 +0000 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: About referenced documents... X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi Folks, in the process of re-writing the ENUM Experiences draft, I wanted to check that its statement on the characters that can be found in POSIX Extended Regular Expressions (as called up in RFC 3402) is correct. However, the referenced standard is an IEEE document that those fine chaps want money to purchase. I had thought that the IETF didn't like normative references that were not available to all (without paying for them). Am I misunderstanding the situation? There are any number of different documents "out there" that talk about Regular Expressions, and in practice is it going to be hard to find a library that only does POSIX ERE processing, but... should we be referring to a standard document that is only available at a cost? There have certainly been enough complaints about mobile standards (at least until the message got through that 3GPP and ITU standards were available at no cost). How many such "paid only" standards are referenced in IETF documents, I wonder? all the best, Lawrence _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Oct 28 21:18:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImIzk-0008Br-IW; Sun, 28 Oct 2007 21:00:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImIzi-0008Am-Q9 for ietf@ietf.org; Sun, 28 Oct 2007 21:00:42 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImIzi-0001Ua-H3 for ietf@ietf.org; Sun, 28 Oct 2007 21:00:42 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=chncCygRfBmnwzR9SpeAaA6iswYFRqj0T/LYIMr4FejVpConOAwRau1PCu7xoWDm; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.137.241] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1ImIzh-0001yX-Pi for ietf@ietf.org; Sun, 28 Oct 2007 21:00:42 -0400 Message-ID: <000401c819cf$982d7620$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "IETF Discussion" References: <917D43E5-30EF-49A9-9DD3-02DC87A35AD4@insensate.co.uk> Date: Sun, 28 Oct 2007 18:01:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31a56097f88f4a86ab7d223553977bb6c07350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.137.241 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: Re: About referenced documents... X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi - > From: "lconroy" > To: "IETF Discussion" > Sent: Sunday, October 28, 2007 4:02 PM > Subject: About referenced documents... ... > I had thought that the IETF didn't like normative references that > were not available to all (without paying for them). > > Am I misunderstanding the situation? ... Many participants in the IETF have a preference for freely available specifications, but nothing prohibits a normative reference to a specification that needs to be purchased. Factors to consider include how widely implemented the specification in question is, and whether that specification is clearer than or technically superior to its "competition." Randy _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 09:11:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImTzs-00038q-QM; Mon, 29 Oct 2007 08:45:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IljLV-0001vG-U5; Sat, 27 Oct 2007 06:56:49 -0400 Received: from smtp-out4.libero.it ([212.52.84.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IljLS-00024P-IZ; Sat, 27 Oct 2007 06:56:47 -0400 Received: from MailRelay09.libero.it (192.168.32.116) by smtp-out4.libero.it (7.3.120) id 4688F3500CB12CED; Sat, 27 Oct 2007 12:56:25 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAB62IkeXOQ8i/2dsb2JhbAAMkDo Received: from unknown (HELO [192.168.0.6]) ([151.57.15.34]) by outrelay-b09.libero.it with ESMTP; 27 Oct 2007 12:56:23 +0200 Message-ID: <4723194D.8010908@gentoo.org> Date: Sat, 27 Oct 2007 12:56:13 +0200 From: Luca Barbato User-Agent: Thunderbird 2.0.0.0 (X11/20070607) MIME-Version: 1.0 To: Spencer Dawkins References: <10cb01c81816$1bb34620$6501a8c0@china.huawei.com> In-Reply-To: <10cb01c81816$1bb34620$6501a8c0@china.huawei.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad X-Mailman-Approved-At: Mon, 29 Oct 2007 08:45:31 -0400 Cc: ext Cullen Jennings , General Area Review Team , draft-ietf-avt-rtp-vorbis@tools.ietf.org, avt-chairs@tools.ietf.org, ietf@ietf.org Subject: Re: Gen-ART Last Call review of draft-ietf-avt-rtp-vorbis-06 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Spencer Dawkins wrote: > Document: draft-ietf-avt-rtp-vorbis-06 > Reviewer: Spencer Dawkins > Review Date: 26 Oct 2007 (sorry, late!) > IETF LC End Date: 22 Oct 2007 > IESG Telechat date: > > Summary: This document is close to ready for publication as a Proposed > Standard. I have a small number of questions, mostly involving clarity > or 2119 language. Please take a look at the question in 7.1, especially. > > Comments: I have included "nits" in this review for the convenience of > authors and editors later in the process. Nits are not part of a Gen-ART > review. > > 1. Introduction > > Vorbis is a general purpose perceptual audio codec intended to allow > maximum encoder flexibility, thus allowing it to scale competitively > over an exceptionally wide range of bitrates. At the high quality/ > bitrate end of the scale (CD or DAT rate stereo, 16/24 bits), it is > in the same league as AAC. Vorbis is also intended for lower and > > Spencer (nit): AAC? has not been expanded previously. I edited as MPEG-4 AAC, should an informative reference be useful? > > higher sample rates (from 8kHz telephony to 192kHz digital masters) > and a range of channel representations (monaural, polyphonic, stereo, > quadraphonic, 5.1, ambisonic, or up to 255 discrete channels). > > 2.2. Payload Header > > Vorbis Data Type (VDT): 2 bits > > This field specifies the kind of Vorbis data stored in this RTP > packet. There are currently three different types of Vorbis > payloads. Each packet MUST contain only a single type of Vorbis > payload (e.g. you MUST not aggregate configuration and comment > > Spencer: this is close to a nit, but 2119 language is important. This is > just restating the previous MUST. I'd suggest either "must" in lower > case or "MUST NOT" - if there's a reason to have two 2119 requirements > that say the same thing. lowercased > > payload in the same packet) > > 0 = Raw Vorbis payload > 1 = Vorbis Packed Configuration payload > 2 = Legacy Vorbis Comment payload > 3 = Reserved > > The packets with a VDT of value 3 MUST be ignored > > The last 4 bits represent the number of complete packets in this > payload. This provides for a maximum number of 15 Vorbis packets in > the payload. If the packet contains fragmented data the number of > packets MUST be set to 0. > > Spencer (nit): what type of fragmentation is this? Please provide an > adjective :-) Or rephrase as: "If the F field is nonzero the number of packets MUST be set to 0" ? > > 2.3. Payload Data > > The Vorbis packet length header is the length of the Vorbis data > block only and does not count the length field. > > Spencer (nit): s/count/include/, I think. applied > > The payload packing of the Vorbis data packets MUST follow the > guidelines set-out in [3] where the oldest packet occurs immediately > > Spencer: again, adjectives are good. This is saying "the oldest Vorbis > packet", right? It would be better if the specification doesn't use > language like "the oldest packet in the packet" with no adjectives - > that doesn't take us to a good place. Right > > after the RTP packet header. Subsequent packets, if any, MUST follow > in temporal order. > > Spencer: "Subsequent Vorbis packets", right? right > what does the receiver do if the "follow in temporal order" MUST is violated? It doesn't have a way to figure out so it will decode the stream assuming the samples aren't misordered. > > 3.1.1. Packed Configuration > > A Vorbis Packed Configuration is indicated with the Vorbis Data Type > field set to 1. Of the three headers defined in the Vorbis I > specification [10], the identification and the setup MUST be packed > as they are, while the comment header MAY be replaced with a dummy > one. The packed configuration follows a generic way to store xiph > codec configurations: The first field stores the number of the > following packets minus one (count field), the next ones represent > the size of the headers (length fields), the headers immediately > follow the list of length fields. The size of the last header is > implicit. The count and the length fields are encoded using the > following logic: the data is in network order, every byte has the > > Spencer (nit): c/network order/network byte order/, and there are > multiple occurrences in the document... applied two times. > > most significant bit used as flag and the following 7 used to store > the value. The first N bit are to be taken, where N is number of > bits representing the value modulo 7, and stored in the first byte. > If there are more bits, the flag bit is set to 1 and the subsequent > 7bit are stored in the following byte, if there are remaining bits > set the flag to 1 and the same procedure is repeated. The ending > byte has the flag bit set to 0. In order to decode it is enough to > iterate over the bytes until the flag bit set to 0, for every byte > the data is added to the accumulated value multiplied by 128. The > headers are packed in the same order they are present in ogg: > identification, comment, setup. > > 3.2. Out of Band Transmission > > This section, as stated above, does not cover all the possible out- > of-band delivery methods since they rely on different protocols and > are linked to specific applications. The following packet definition > SHOULD be used in out-of-band delivery and MUST be used when > > Spencer: is there an obvious reason to violate the SHOULD? If the underlying transport has other syntax providing already the minimal framing and tagging features required would be an unnecessary overhead. > > Configuration is inlined in the SDP. > > 5.1. Example Fragmented Vorbis Packet > > The Fragment type field is set to 2 and the number of packets field > is set to 0. For large Vorbis fragments there can be several of > these type of payload packets. The maximum packet size SHOULD be no > > Spencer (nit): s/these type/this type/? fixed > > Spencer: why is this a SHOULD? sctp does a better job than fragmenting at rtp level. > > greater than the path MTU, including all RTP and payload headers. > The sequence number has been incremented by one but the timestamp > field remains the same as the initial packet. > > 5.2. Packet Loss > > As there is no error correction within the Vorbis stream, packet loss > will result in a loss of signal. Packet loss is more of an issue for > fragmented Vorbis packets as the client will have to cope with the > handling of the Fragment Type. In case of loss of fragments the > client MUST discard all the remaining fragments and decode the > > Spencer (nit) - "remaining Vorbis fragments" and "incomplete Vorbis > packet"? right. > > incomplete packet. If we use the fragmented Vorbis packet example > above and the first packet is lost the client MUST detect that the > > Spencer (nit) - "and the first RTP packet is lost"? right. > > next packet has the packet count field set to 0 and the Fragment type > 2 and MUST drop it. The next packet, which is the final fragmented > packet, MUST be dropped in the same manner. If the missing packet is > the last, the received two fragments will be kept and the incomplete > vorbis packet decoded. > > 6. IANA Considerations > > configuration-uri: the URI [4] of the configuration headers in > case of out of band transmission. In the form of > "protocol://path/to/resource/", depending on the specific > > Spencer: isn't this "scheme://path/to/resource"? good call =) > > method, a single configuration packet could be retrived by its > Ident number, or multiple packets could be aggregated in a > single stream. Non hierarchical protocols MAY point to a > resource using their specific syntax. > > 7.1. Mapping Media Type Parameters into SDP > > The information carried in the Media Type media type specification > has a specific mapping to fields in the Session Description Protocol > (SDP) [5], which is commonly used to describe RTP sessions. When SDP > is used to specify sessions the mapping are as follows: > > Spencer: is there anything you can say about Receiver behavior when the > Media Type and SDP don't map correctly? Should I explicitly state that the Receiver should drop the session? > > 7.1.1. SDP Example > > The following example shows a basic SDP single stream. The first > configuration packet is inlined in the sdp, other configurations > > Spencer (nit): it would be great if SDP, URI etc. were consistently > capitalized. Done > > could be fetched at any time from the first provided uri using or all > > Spencer: is this "the URI currently in use"? but the sentence doesn't > parse as written. Relic from a previous revision, removed. > > the known configuration could be downloaded using the second uri. > The inline base64 [9] configuration string is trimmed because of the > > Spencer: is this "is folded in this example due to RFC line length > limitations"? yes > > length. > c=IN IP4 192.0.2.1 > m=audio RTP/AVP 98 > a=rtpmap:98 vorbis/44100/2 > a=fmtp:98 delivery-method=inline; > configuration=AAAAAZ2f4g9NAh4aAXZvcmJpcwA...; delivery- > method=out_band; configuration-uri=rtsp://path/to/the/resource; > delivery-method=out_band; > configuration-uri=http://another/path/to/resource/; > > Note that the payload format (encoding) names are commonly shown in > upper case. Media Type subtypes are commonly shown in lower case. > These names are case-insensitive in both places. Similarly, > parameter names are case-insensitive both in Media Type types and in > the default mapping to the SDP a=fmtp attribute. The exception > regarding case sensitivity is the configuration-uri URI which MUST be > regarded as being case sensitive. The a=fmtp line is a single line > > Spencer: "shown as multiple lines in this document for clarity"? > ok > even if it is presented broken because of clarity. > > 7.2. Usage with the SDP Offer/Answer Model > > The only paramenter negotiable is the delivery method. All the > > Spencer (nit): c/paramenter negotiable/negotiable parameter/ > > others are declarative: the offer, as described in An Offer/Answer > Model Session Description Protocol [8], may contain a large number of > delivery methods per single fmtp attribute, the answerer MUST remove > every delivery-method and configuration-uri not supported. All the > parameters MUST not be altered on answer otherwise. > > 8. Congestion Control > > Vorbis clients SHOULD send regular receiver reports detailing > > Spencer: is there a well-understood definition of "regular" within this > community? to my best knowledge it is. > > congestion. A mechanism for dynamically downgrading the stream, > known as bitrate peeling, will allow for a graceful backing off of > the stream bitrate. This feature is not available at present so an > alternative would be to redirect the client to a lower bitrate stream > if one is available. > > 9.1. Stream Radio > > This is one of the most common situation: one single server streaming > content in multicast, the clients may start a session at random time. > The content itself could be a mix of live stream, as the wj's voice, > > Spencer (nit): "wj's"? please spell this out (I'm guessing what this means) webjockey > > and stored streams as the music she plays. > -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 09:11:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImTzq-00038J-KV; Mon, 29 Oct 2007 08:45:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlYgH-0007Oy-U1 for ietf@ietf.org; Fri, 26 Oct 2007 19:33:33 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlYg5-0000fn-39 for ietf@ietf.org; Fri, 26 Oct 2007 19:33:29 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IlYfV-0000U0-Bs for ietf@ietf.org; Fri, 26 Oct 2007 23:32:45 +0000 Received: from eth595.vic.adsl.internode.on.net ([150.101.214.82]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Oct 2007 23:32:45 +0000 Received: from ben by eth595.vic.adsl.internode.on.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Oct 2007 23:32:45 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: Ben Finney Date: Sat, 27 Oct 2007 09:31:52 +1000 Lines: 29 Message-ID: <87lk9pihav.fsf@benfinney.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: eth595.vic.adsl.internode.on.net X-Public-Key-ID: 0xBD41714B X-Public-Key-Fingerprint: 9CFE 12B0 791A 4267 887F 520C B7AC 2E51 BD41 714B X-Public-Key-URL: http://www.benfinney.id.au/contact/bfinney-gpg.asc X-Post-From: Ben Finney User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Cancel-Lock: sha1:V/riesSYS6NiMGpIZrtPAitzHK8= X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Mon, 29 Oct 2007 08:45:31 -0400 Subject: Please oppose patent-encumbered technologies, including draft-housley-tls-authz-extns X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org To whom it may concern, I have been made aware that the technology described in the 'draft-housley-tls-authz-extns' proposal is encumbered by patents held by entities with a history of patent enforcement. All software developers, regardless of whether they produce free software or proprietary, are hindered in their work by software idea patents. A technology thus encumbered by patents is available only to a select few, and their work is subject to whatever whims the holder of the patent decides to impose. If a technology is known to be encumbered by patents, yet is proposed as a standard for the internet, it would be harmful to all software users. It is also folly to give legitimacy to the practice of patenting software algorithms by recognising such patents and endorsing the technology in any form of standards process. Please, reject 'draft-housley-tls-authz-extns' from any consideration by IETF processes until the technology it describes is explicitly free for everyone to implement for any purpose. -- \ "A 'No' uttered from deepest conviction is better and greater | `\ than a 'Yes' merely uttered to please, or what is worse, to | _o__) avoid trouble." —Mahatma Gandhi | Ben Finney _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 09:11:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImTzq-00038J-KV; Mon, 29 Oct 2007 08:45:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlYgH-0007Oy-U1 for ietf@ietf.org; Fri, 26 Oct 2007 19:33:33 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlYg5-0000fn-39 for ietf@ietf.org; Fri, 26 Oct 2007 19:33:29 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IlYfV-0000U0-Bs for ietf@ietf.org; Fri, 26 Oct 2007 23:32:45 +0000 Received: from eth595.vic.adsl.internode.on.net ([150.101.214.82]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Oct 2007 23:32:45 +0000 Received: from ben by eth595.vic.adsl.internode.on.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Oct 2007 23:32:45 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: Ben Finney Date: Sat, 27 Oct 2007 09:31:52 +1000 Lines: 29 Message-ID: <87lk9pihav.fsf@benfinney.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: eth595.vic.adsl.internode.on.net X-Public-Key-ID: 0xBD41714B X-Public-Key-Fingerprint: 9CFE 12B0 791A 4267 887F 520C B7AC 2E51 BD41 714B X-Public-Key-URL: http://www.benfinney.id.au/contact/bfinney-gpg.asc X-Post-From: Ben Finney User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Cancel-Lock: sha1:V/riesSYS6NiMGpIZrtPAitzHK8= X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Mon, 29 Oct 2007 08:45:31 -0400 Subject: Please oppose patent-encumbered technologies, including draft-housley-tls-authz-extns X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org To whom it may concern, I have been made aware that the technology described in the 'draft-housley-tls-authz-extns' proposal is encumbered by patents held by entities with a history of patent enforcement. All software developers, regardless of whether they produce free software or proprietary, are hindered in their work by software idea patents. A technology thus encumbered by patents is available only to a select few, and their work is subject to whatever whims the holder of the patent decides to impose. If a technology is known to be encumbered by patents, yet is proposed as a standard for the internet, it would be harmful to all software users. It is also folly to give legitimacy to the practice of patenting software algorithms by recognising such patents and endorsing the technology in any form of standards process. Please, reject 'draft-housley-tls-authz-extns' from any consideration by IETF processes until the technology it describes is explicitly free for everyone to implement for any purpose. -- \ "A 'No' uttered from deepest conviction is better and greater | `\ than a 'Yes' merely uttered to please, or what is worse, to | _o__) avoid trouble." —Mahatma Gandhi | Ben Finney _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 09:11:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImTzs-00038k-53; Mon, 29 Oct 2007 08:45:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlZ6U-0001Ci-6E for ietf@ietf.org; Fri, 26 Oct 2007 20:00:38 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlZ6T-00042v-Pp for ietf@ietf.org; Fri, 26 Oct 2007 20:00:38 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IlZ6N-0004fI-R2 for ietf@ietf.org; Sat, 27 Oct 2007 00:00:31 +0000 Received: from eth595.vic.adsl.internode.on.net ([150.101.214.82]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Oct 2007 00:00:31 +0000 Received: from bignose+hates-spam by eth595.vic.adsl.internode.on.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Oct 2007 00:00:31 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: Ben Finney Date: Sat, 27 Oct 2007 10:00:26 +1000 Lines: 25 Message-ID: <878x5pifz9.fsf@benfinney.id.au> References: <20071026210538.6D71E872CA@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: eth595.vic.adsl.internode.on.net X-Public-Key-ID: 0xBD41714B X-Public-Key-Fingerprint: 9CFE 12B0 791A 4267 887F 520C B7AC 2E51 BD41 714B X-Public-Key-URL: http://www.benfinney.id.au/contact/bfinney-gpg.asc X-Post-From: Ben Finney User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Cancel-Lock: sha1:hZhZ3e1Ao8fflV4Fp6z86IsjXUU= X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Mon, 29 Oct 2007 08:45:31 -0400 Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org jnc@mercury.lcs.mit.edu (Noel Chiappa) writes: > I concur [with ignoring requests to reject > 'draft-housley-tls-authz-extns' on grounds of patent encumbrance] - > and I think this is the action we should take, no matter how many > emails we see from people we've never heard from before (and > probably never will again). These people you speak of are users of the internet, and in many cases software developers, expressing specific concern over a process they see as harmful to the foundation of the internet: namely, validation of a patent-encumbered technology by progressing it through a standards process. In the past it has been expressed on this list that the only qualification for getting involved in IETF policy is exactly that, getting involved -- in particular, on this list. Are you saying that people who take the time to post in this forum will be ignored merely because what they say is not what you want to hear? -- \ "Courage is resistance to fear, mastery of fear — not absence | `\ of fear. -- Mark Twain, _Pudd'n'head Wilson_ | _o__) | Ben Finney _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 09:11:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImTzt-00038w-Bd; Mon, 29 Oct 2007 08:45:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilo30-0004q9-HF for ietf@ietf.org; Sat, 27 Oct 2007 11:58:02 -0400 Received: from eastrmmtao102.cox.net ([68.230.240.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ilo2q-000070-HO for ietf@ietf.org; Sat, 27 Oct 2007 11:57:58 -0400 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao102.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20071027155723.INPD3771.eastrmmtao102.cox.net@eastrmimpo01.cox.net> for ; Sat, 27 Oct 2007 11:57:23 -0400 Received: from [10.30.20.61] ([68.10.112.80]) by eastrmimpo01.cox.net with bizsmtp id 5TxE1Y00V1k7mf00000000; Sat, 27 Oct 2007 11:57:14 -0400 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <6130F950-2671-4612-9334-BB5723458DCB@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ietf@ietf.org From: RJ Atkinson Date: Sat, 27 Oct 2007 11:57:21 -0400 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-Mailman-Approved-At: Mon, 29 Oct 2007 08:45:31 -0400 Subject: Silly TLS Auth lobbying X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Some important things that the FSF folks seem NOT to understand, and frankly seem to aggressively NOT want to understand, are: - Many RFCs are *not* on the IETF standards track. - Any "Experimental RFC" is *not* on the IETF standards track. So there is no "endorsement" by IETF in publishing such. - The IETF has published real standards-track documents that required patented technology and were known to have *difficult* license terms on the publication date (think cryptographic algorithms and scan backwards in rfc-index.txt). - There is no history of IETF requiring technology to be freely available (for either common definition of free). I support the idea that virtually any document ought to be able to be published as an Informational RFC or Experimental RFC. Technology that is useful will be adopted if economically sensible, whether in an RFC or not, whether made a formal standard or not. By having an open specification, users can at least understand the properties of the technology that is documented openly. Just to be crystal clear, I do support publishing draft-housley-* as either Informational RFC or Experimental RFC. Yours, Ran rja@extremenetworks.com _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -53; Mon, 29 Oct 2007 08:45:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlZ6U-0001Ci-6E for ietf@ietf.org; Fri, 26 Oct 2007 20:00:38 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlZ6T-00042v-Pp for ietf@ietf.org; Fri, 26 Oct 2007 20:00:38 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IlZ6N-0004fI-R2 for ietf@ietf.org; Sat, 27 Oct 2007 00:00:31 +0000 Received: from eth595.vic.adsl.internode.on.net ([150.101.214.82]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Oct 2007 00:00:31 +0000 Received: from bignose+hates-spam by eth595.vic.adsl.internode.on.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Oct 2007 00:00:31 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: Ben Finney Date: Sat, 27 Oct 2007 10:00:26 +1000 Lines: 25 Message-ID: <878x5pifz9.fsf@benfinney.id.au> References: <20071026210538.6D71E872CA@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: eth595.vic.adsl.internode.on.net X-Public-Key-ID: 0xBD41714B X-Public-Key-Fingerprint: 9CFE 12B0 791A 4267 887F 520C B7AC 2E51 BD41 714B X-Public-Key-URL: http://www.benfinney.id.au/contact/bfinney-gpg.asc X-Post-From: Ben Finney User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Cancel-Lock: sha1:hZhZ3e1Ao8fflV4Fp6z86IsjXUU= X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Mon, 29 Oct 2007 08:45:31 -0400 Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org jnc@mercury.lcs.mit.edu (Noel Chiappa) writes: > I concur [with ignoring requests to reject > 'draft-housley-tls-authz-extns' on grounds of patent encumbrance] - > and I think this is the action we should take, no matter how many > emails we see from people we've never heard from before (and > probably never will again). These people you speak of are users of the internet, and in many cases software developers, expressing specific concern over a process they see as harmful to the foundation of the internet: namely, validation of a patent-encumbered technology by progressing it through a standards process. In the past it has been expressed on this list that the only qualification for getting involved in IETF policy is exactly that, getting involved -- in particular, on this list. Are you saying that people who take the time to post in this forum will be ignored merely because what they say is not what you want to hear? -- \ "Courage is resistance to fear, mastery of fear — not absence | `\ of fear. -- Mark Twain, _Pudd'n'head Wilson_ | _o__) | Ben Finney _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 09:11:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImTzt-00038w-Bd; Mon, 29 Oct 2007 08:45:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilo30-0004q9-HF for ietf@ietf.org; Sat, 27 Oct 2007 11:58:02 -0400 Received: from eastrmmtao102.cox.net ([68.230.240.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ilo2q-000070-HO for ietf@ietf.org; Sat, 27 Oct 2007 11:57:58 -0400 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao102.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20071027155723.INPD3771.eastrmmtao102.cox.net@eastrmimpo01.cox.net> for ; Sat, 27 Oct 2007 11:57:23 -0400 Received: from [10.30.20.61] ([68.10.112.80]) by eastrmimpo01.cox.net with bizsmtp id 5TxE1Y00V1k7mf00000000; Sat, 27 Oct 2007 11:57:14 -0400 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <6130F950-2671-4612-9334-BB5723458DCB@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ietf@ietf.org From: RJ Atkinson Date: Sat, 27 Oct 2007 11:57:21 -0400 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-Mailman-Approved-At: Mon, 29 Oct 2007 08:45:31 -0400 Subject: Silly TLS Auth lobbying X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Some important things that the FSF folks seem NOT to understand, and frankly seem to aggressively NOT want to understand, are: - Many RFCs are *not* on the IETF standards track. - Any "Experimental RFC" is *not* on the IETF standards track. So there is no "endorsement" by IETF in publishing such. - The IETF has published real standards-track documents that required patented technology and were known to have *difficult* license terms on the publication date (think cryptographic algorithms and scan backwards in rfc-index.txt). - There is no history of IETF requiring technology to be freely available (for either common definition of free). I support the idea that virtually any document ought to be able to be published as an Informational RFC or Experimental RFC. Technology that is useful will be adopted if economically sensible, whether in an RFC or not, whether made a formal standard or not. By having an open specification, users can at least understand the properties of the technology that is documented openly. Just to be crystal clear, I do support publishing draft-housley-* as either Informational RFC or Experimental RFC. Yours, Ran rja@extremenetworks.com _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 09:11:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImTzq-00038J-KV; Mon, 29 Oct 2007 08:45:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlYgH-0007Oy-U1 for ietf@ietf.org; Fri, 26 Oct 2007 19:33:33 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlYg5-0000fn-39 for ietf@ietf.org; Fri, 26 Oct 2007 19:33:29 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IlYfV-0000U0-Bs for ietf@ietf.org; Fri, 26 Oct 2007 23:32:45 +0000 Received: from eth595.vic.adsl.internode.on.net ([150.101.214.82]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Oct 2007 23:32:45 +0000 Received: from ben by eth595.vic.adsl.internode.on.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Oct 2007 23:32:45 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: Ben Finney Date: Sat, 27 Oct 2007 09:31:52 +1000 Lines: 29 Message-ID: <87lk9pihav.fsf@benfinney.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: eth595.vic.adsl.internode.on.net X-Public-Key-ID: 0xBD41714B X-Public-Key-Fingerprint: 9CFE 12B0 791A 4267 887F 520C B7AC 2E51 BD41 714B X-Public-Key-URL: http://www.benfinney.id.au/contact/bfinney-gpg.asc X-Post-From: Ben Finney User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Cancel-Lock: sha1:V/riesSYS6NiMGpIZrtPAitzHK8= X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Mon, 29 Oct 2007 08:45:31 -0400 Subject: Please oppose patent-encumbered technologies, including draft-housley-tls-authz-extns X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org To whom it may concern, I have been made aware that the technology described in the 'draft-housley-tls-authz-extns' proposal is encumbered by patents held by entities with a history of patent enforcement. All software developers, regardless of whether they produce free software or proprietary, are hindered in their work by software idea patents. A technology thus encumbered by patents is available only to a select few, and their work is subject to whatever whims the holder of the patent decides to impose. If a technology is known to be encumbered by patents, yet is proposed as a standard for the internet, it would be harmful to all software users. It is also folly to give legitimacy to the practice of patenting software algorithms by recognising such patents and endorsing the technology in any form of standards process. Please, reject 'draft-housley-tls-authz-extns' from any consideration by IETF processes until the technology it describes is explicitly free for everyone to implement for any purpose. -- \ "A 'No' uttered from deepest conviction is better and greater | `\ than a 'Yes' merely uttered to please, or what is worse, to | _o__) avoid trouble." —Mahatma Gandhi | Ben Finney _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 09:11:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImTzs-00038k-53; Mon, 29 Oct 2007 08:45:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlZ6U-0001Ci-6E for ietf@ietf.org; Fri, 26 Oct 2007 20:00:38 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlZ6T-00042v-Pp for ietf@ietf.org; Fri, 26 Oct 2007 20:00:38 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IlZ6N-0004fI-R2 for ietf@ietf.org; Sat, 27 Oct 2007 00:00:31 +0000 Received: from eth595.vic.adsl.internode.on.net ([150.101.214.82]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Oct 2007 00:00:31 +0000 Received: from bignose+hates-spam by eth595.vic.adsl.internode.on.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Oct 2007 00:00:31 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: Ben Finney Date: Sat, 27 Oct 2007 10:00:26 +1000 Lines: 25 Message-ID: <878x5pifz9.fsf@benfinney.id.au> References: <20071026210538.6D71E872CA@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: eth595.vic.adsl.internode.on.net X-Public-Key-ID: 0xBD41714B X-Public-Key-Fingerprint: 9CFE 12B0 791A 4267 887F 520C B7AC 2E51 BD41 714B X-Public-Key-URL: http://www.benfinney.id.au/contact/bfinney-gpg.asc X-Post-From: Ben Finney User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Cancel-Lock: sha1:hZhZ3e1Ao8fflV4Fp6z86IsjXUU= X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Mon, 29 Oct 2007 08:45:31 -0400 Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org jnc@mercury.lcs.mit.edu (Noel Chiappa) writes: > I concur [with ignoring requests to reject > 'draft-housley-tls-authz-extns' on grounds of patent encumbrance] - > and I think this is the action we should take, no matter how many > emails we see from people we've never heard from before (and > probably never will again). These people you speak of are users of the internet, and in many cases software developers, expressing specific concern over a process they see as harmful to the foundation of the internet: namely, validation of a patent-encumbered technology by progressing it through a standards process. In the past it has been expressed on this list that the only qualification for getting involved in IETF policy is exactly that, getting involved -- in particular, on this list. Are you saying that people who take the time to post in this forum will be ignored merely because what they say is not what you want to hear? -- \ "Courage is resistance to fear, mastery of fear — not absence | `\ of fear. -- Mark Twain, _Pudd'n'head Wilson_ | _o__) | Ben Finney _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 09:11:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImTzt-00038w-Bd; Mon, 29 Oct 2007 08:45:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilo30-0004q9-HF for ietf@ietf.org; Sat, 27 Oct 2007 11:58:02 -0400 Received: from eastrmmtao102.cox.net ([68.230.240.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ilo2q-000070-HO for ietf@ietf.org; Sat, 27 Oct 2007 11:57:58 -0400 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao102.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20071027155723.INPD3771.eastrmmtao102.cox.net@eastrmimpo01.cox.net> for ; Sat, 27 Oct 2007 11:57:23 -0400 Received: from [10.30.20.61] ([68.10.112.80]) by eastrmimpo01.cox.net with bizsmtp id 5TxE1Y00V1k7mf00000000; Sat, 27 Oct 2007 11:57:14 -0400 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <6130F950-2671-4612-9334-BB5723458DCB@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ietf@ietf.org From: RJ Atkinson Date: Sat, 27 Oct 2007 11:57:21 -0400 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-Mailman-Approved-At: Mon, 29 Oct 2007 08:45:31 -0400 Subject: Silly TLS Auth lobbying X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Some important things that the FSF folks seem NOT to understand, and frankly seem to aggressively NOT want to understand, are: - Many RFCs are *not* on the IETF standards track. - Any "Experimental RFC" is *not* on the IETF standards track. So there is no "endorsement" by IETF in publishing such. - The IETF has published real standards-track documents that required patented technology and were known to have *difficult* license terms on the publication date (think cryptographic algorithms and scan backwards in rfc-index.txt). - There is no history of IETF requiring technology to be freely available (for either common definition of free). I support the idea that virtually any document ought to be able to be published as an Informational RFC or Experimental RFC. Technology that is useful will be adopted if economically sensible, whether in an RFC or not, whether made a formal standard or not. By having an open specification, users can at least understand the properties of the technology that is documented openly. Just to be crystal clear, I do support publishing draft-housley-* as either Informational RFC or Experimental RFC. Yours, Ran rja@extremenetworks.com _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 09:11:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImTzr-00038Y-Gv; Mon, 29 Oct 2007 08:45:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlZ0G-0001Mp-Tn for ietf@ietf.org; Fri, 26 Oct 2007 19:54:12 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlZ0G-0003sd-B6 for ietf@ietf.org; Fri, 26 Oct 2007 19:54:12 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IlZ09-0003vM-47 for ietf@ietf.org; Fri, 26 Oct 2007 23:54:05 +0000 Received: from eth595.vic.adsl.internode.on.net ([150.101.214.82]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Oct 2007 23:54:05 +0000 Received: from bignose+hates-spam by eth595.vic.adsl.internode.on.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Oct 2007 23:54:05 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: Ben Finney Date: Sat, 27 Oct 2007 09:53:51 +1000 Lines: 39 Message-ID: <87fxzxiga8.fsf@benfinney.id.au> References: <003e01c817fa$b09cfb80$6801a8c0@oemcomputer> <20071026191611.C65F27E13@bender.tigertech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: eth595.vic.adsl.internode.on.net X-Public-Key-ID: 0xBD41714B X-Public-Key-Fingerprint: 9CFE 12B0 791A 4267 887F 520C B7AC 2E51 BD41 714B X-Public-Key-URL: http://www.benfinney.id.au/contact/bfinney-gpg.asc X-Post-From: Ben Finney User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Cancel-Lock: sha1:3GnIpWhP0mTLyTwexsB2c4uDezk= X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-Mailman-Approved-At: Mon, 29 Oct 2007 08:45:31 -0400 Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org "Joel M. Halpern" writes: > We have published encumbered experimental and informational > documents on many occasions. I can see no reason not to do so in > this case. The reasons are the same as they have always been. Making a mistake in the past is no reason to continue making that same mistake. Software idea patents place control over *every* independent implementation of an idea in the hands of *one* entity, who then gets to dictate whatever terms they like. This is unjust, and is a practical hindrance on every software developer since it adds to the minefield of ideas that they must avoid using when designing their code. Even developers who are not intending to use ideas encumbered by a particular patent can independently arrive at some specific method described in that patent, and inadvertantly violate the patent rules. In such cases the violation will not be discovered for some unknown amount of time. The burden on software developers thus mounts with every patent on a software idea. To allow a technology, encumbered by any known patent holder's monopoly, as a proposed standard (even experimental or informational or any other status) is to give legitimacy to this system that directly harms development of all software, and especially harms the goal of interoperability that is part of the purpose of a standards process. Please explicitly reject technologies from any part of the standards process that are encumbered by software idea patents. I encourage you to start with the rejection of 'draft-housley-tls-authz-extns'. -- \ "Holy bouncing boiler-plated fits, Batman!" -- Robin | `\ | _o__) | Ben Finney _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 09:38:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImUgC-0005Gs-Lq; Mon, 29 Oct 2007 09:29:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImUgB-0005CW-7s for ietf@ietf.org; Mon, 29 Oct 2007 09:29:19 -0400 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ImUgA-0000Ky-JL for ietf@ietf.org; Mon, 29 Oct 2007 09:29:19 -0400 Received: (qmail 79743 invoked from network); 29 Oct 2007 13:49:20 -0000 Received: from softbank219001188028.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.28) by necom830.hpcl.titech.ac.jp with SMTP; 29 Oct 2007 13:49:20 -0000 Message-ID: <4725E025.6040804@necom830.hpcl.titech.ac.jp> Date: Mon, 29 Oct 2007 22:29:09 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: RJ Atkinson References: <6130F950-2671-4612-9334-BB5723458DCB@extremenetworks.com> In-Reply-To: <6130F950-2671-4612-9334-BB5723458DCB@extremenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ietf@ietf.org Subject: Re: Silly TLS Auth lobbying X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org RJ Atkinson wrote: > Some important things that the FSF folks seem NOT to understand, > and frankly seem to aggressively NOT want to understand, are: > > - Many RFCs are *not* on the IETF standards track. > > - Any "Experimental RFC" is *not* on the IETF standards track. > So there is no "endorsement" by IETF in publishing such. A lot more silly fact, these days, is that all the published RFCs require IESG "endorsement". That being so, I fully agree with FSF folks against publication of silly RFCs. > I support the idea that virtually any document ought to be able > to be published as an Informational RFC or Experimental RFC. I do agree with the idea. And, it was the real practice in good old days when Jon was the RFC editor. Masataka Ohta _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 09:44:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImUpn-0007Lc-TF; Mon, 29 Oct 2007 09:39:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImUpm-0007Gw-9A for ietf@ietf.org; Mon, 29 Oct 2007 09:39:14 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImUpg-0000i3-Oh for ietf@ietf.org; Mon, 29 Oct 2007 09:39:09 -0400 Received: from E03MVC4-UKBR.domain1.systemhost.net ([193.113.197.116]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 13:39:07 +0000 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" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Oct 2007 13:41:49 -0000 Message-ID: In-Reply-To: <6130F950-2671-4612-9334-BB5723458DCB@extremenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Silly TLS Auth lobbying Thread-Index: AcgaLIqNoCj2bc2ESkuASltFz/0CwQAA9Ukg References: <6130F950-2671-4612-9334-BB5723458DCB@extremenetworks.com> From: To: X-OriginalArrivalTime: 29 Oct 2007 13:39:07.0761 (UTC) FILETIME=[145FEE10:01C81A31] X-Spam-Score: -1.0 (-) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: RE: Silly TLS Auth lobbying X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > - Many RFCs are *not* on the IETF standards track. One of the commenters mentioned that even Informational RFCs are seen, by the uninitiated, as having the force of a standard. > - Any "Experimental RFC" is *not* on the IETF standards track. > So there is no "endorsement" by IETF in publishing such. In fact, designating an RFC with IPR concerns to Experimental status is a kind of "purgatory" for the RFC. It gives opponents a chance rally implementation efforts using alternatives so that the Experimental RFC never goes anywhere. But, if it turns out that there are no viable alternatives or that the IPR owner is being fair and reasonable, then the RFC can come out of Experimental status after the work has proven itself. If the FSF and others understood that Experimental RFCs are a form of purgatory, I think many of them would be satisfied. > able to be published as an Informational RFC or Experimental RFC. > Technology that is useful will be adopted if economically=20 > sensible, whether in an RFC or not, whether made a formal=20 > standard or not. > By having an open specification, users can at least=20 > understand the properties of the technology that is documented openly. And people who dislike an IPR-encumbered design are free to publish an alternative that satisfies the same needs. If they succeed in getting their design published as an Informational or Experimental RFC, then they have reached "IETF feature parity". I am in favor of publishing draft-housley as Experimental --Michael Dillon _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 09:58:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImV2i-0004YM-2K; Mon, 29 Oct 2007 09:52:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImV2h-0004YH-Ev for ietf@ietf.org; Mon, 29 Oct 2007 09:52:35 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImV2h-0001CN-63 for ietf@ietf.org; Mon, 29 Oct 2007 09:52:35 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 802CA4A45; Mon, 29 Oct 2007 09:52:33 -0400 (EDT) From: Sam Hartman To: RJ Atkinson References: <6130F950-2671-4612-9334-BB5723458DCB@extremenetworks.com> Date: Mon, 29 Oct 2007 09:52:33 -0400 In-Reply-To: <6130F950-2671-4612-9334-BB5723458DCB@extremenetworks.com> (RJ Atkinson's message of "Sat, 27 Oct 2007 11:57:21 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ietf@ietf.org Subject: Re: Silly TLS Auth lobbying X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>>>> "RJ" == RJ Atkinson writes: RJ> I support the idea that virtually any document ought to be RJ> able to be published as an Informational RFC or Experimental RJ> RFC. Technology that is useful will be adopted if RJ> economically sensible, whether in an RFC or not, whether made RJ> a formal standard or not. By having an open specification, RJ> users can at least understand the properties of the technology RJ> that is documented openly. I agree with this general principle. I continue to be unclear on how this principle interacts with IETF consensus IANA actions, nor how it should interact. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 09:58:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImV1F-0003pz-IS; Mon, 29 Oct 2007 09:51:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImV1E-0003Rk-9f for ietf@ietf.org; Mon, 29 Oct 2007 09:51:04 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImV16-0007jf-5O for ietf@ietf.org; Mon, 29 Oct 2007 09:51:02 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F272B4A45; Mon, 29 Oct 2007 09:50:38 -0400 (EDT) From: Sam Hartman To: Ben Finney References: <87lk9pihav.fsf@benfinney.id.au> Date: Mon, 29 Oct 2007 09:50:38 -0400 In-Reply-To: <87lk9pihav.fsf@benfinney.id.au> (Ben Finney's message of "Sat, 27 Oct 2007 09:31:52 +1000") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ietf@ietf.org Subject: Re: Please oppose patent-encumbered technologies, including draft-housley-tls-authz-extns X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>>>> "Ben" == Ben Finney writes: Ben> To whom it may concern, I have been made aware that the Ben> technology described in the 'draft-housley-tls-authz-extns' Ben> proposal is encumbered by patents held by entities with a Ben> history of patent enforcement. I'd appreciate your evidence for both of these claims. 1) That the technology is covered by patents. 2) That those claiming these patents have a history of enforcing. I'm aware of evidence that a party has claimed to have patents that cover the technology. That's significantly weaker than your claim 1. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 10:03:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImV7H-0007kU-UJ; Mon, 29 Oct 2007 09:57:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImV7G-0007jo-Qu for ietf@ietf.org; Mon, 29 Oct 2007 09:57:18 -0400 Received: from newdev.eecs.harvard.edu ([140.247.60.212]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImV7G-0001Q4-KT for ietf@ietf.org; Mon, 29 Oct 2007 09:57:18 -0400 Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 01F35600459; Mon, 29 Oct 2007 09:55:06 -0400 (EDT) To: ietf@ietf.org Message-Id: <20071029135506.01F35600459@newdev.eecs.harvard.edu> Date: Mon, 29 Oct 2007 09:55:06 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: Free? Software Foundation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org it is interesting that the "free" software foundation is espousing censorship Scott _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 10:21:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImVQ9-0004sn-Ei; Mon, 29 Oct 2007 10:16:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImVQ6-0004p2-Kx for ietf@ietf.org; Mon, 29 Oct 2007 10:16:46 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImVQ6-0002KD-9j for ietf@ietf.org; Mon, 29 Oct 2007 10:16:46 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id C62941C00EF; Mon, 29 Oct 2007 15:16:45 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id C1AFB1C00E6; Mon, 29 Oct 2007 15:16:45 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id B563858EBBF; Mon, 29 Oct 2007 15:16:45 +0100 (CET) Date: Mon, 29 Oct 2007 15:16:45 +0100 From: Stephane Bortzmeyer To: "Scott O. Bradner" Message-ID: <20071029141645.GA22116@nic.fr> References: <20071029135506.01F35600459@newdev.eecs.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071029135506.01F35600459@newdev.eecs.harvard.edu> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ietf@ietf.org Subject: Re: Free? Software Foundation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Mon, Oct 29, 2007 at 09:55:06AM -0400, Scott O. Bradner wrote a message of 9 lines which said: > it is interesting that the "free" software foundation is espousing > censorship It is absolutely ridiculous to call "censorship" a call to NOT publish in *our* RFC series a document. "Censorship" would be if IETF exerciced powers (which it does not have) to prevent ANY publication of this document anywhere. If I do not publish your rants on my blog, for instance, it it not censorship, you can always publish it elsewehere. Your misusage of words could be excused only if english were not your native language. Such an outrageous claim is common on /. or similar sites but I did not expect it on an IETF mailing list (except by JFC or similar trolls). _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 10:29:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImVVl-0001NG-QE; Mon, 29 Oct 2007 10:22:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImVVj-0001MK-Ko for ietf@ietf.org; Mon, 29 Oct 2007 10:22:35 -0400 Received: from newdev.eecs.harvard.edu ([140.247.60.212]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImVVj-0002Zs-C9 for ietf@ietf.org; Mon, 29 Oct 2007 10:22:35 -0400 Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 04E96600545; Mon, 29 Oct 2007 10:20:23 -0400 (EDT) To: bortzmeyer@nic.fr, sob@harvard.edu In-Reply-To: <20071029141645.GA22116@nic.fr> Message-Id: <20071029142023.04E96600545@newdev.eecs.harvard.edu> Date: Mon, 29 Oct 2007 10:20:23 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ietf@ietf.org Subject: Re: Free? Software Foundation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I seem to have hit a nerve you are asking the IETF to not publish an IETF doucment - what else can you call it? Scott --- On Mon, Oct 29, 2007 at 09:55:06AM -0400, Scott O. Bradner wrote a message of 9 lines which said: > it is interesting that the "free" software foundation is espousing > censorship It is absolutely ridiculous to call "censorship" a call to NOT publish in *our* RFC series a document. "Censorship" would be if IETF exerciced powers (which it does not have) to prevent ANY publication of this document anywhere. If I do not publish your rants on my blog, for instance, it it not censorship, you can always publish it elsewehere. Your misusage of words could be excused only if english were not your native language. Such an outrageous claim is common on /. or similar sites but I did not expect it on an IETF mailing list (except by JFC or similar trolls). _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 10:41:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImVhP-0007ox-GU; Mon, 29 Oct 2007 10:34:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImVhO-0007iB-6a for ietf@ietf.org; Mon, 29 Oct 2007 10:34:38 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImVhE-0001pw-Cr for ietf@ietf.org; Mon, 29 Oct 2007 10:34:35 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1209F8734F; Mon, 29 Oct 2007 10:34:11 -0400 (EDT) To: ietf@ietf.org Message-Id: <20071029143411.1209F8734F@mercury.lcs.mit.edu> Date: Mon, 29 Oct 2007 10:34:11 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: jnc@mercury.lcs.mit.edu Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > From: Ben Finney > .. idea patents place control over *every* independent implementation of > an idea in the hands of *one* entity, who then gets to dictate whatever > terms they like. This is unjust ... Even developers who are not > intending to use ideas encumbered by a particular patent can > independently arrive at some specific method described in that patent, > and inadvertantly violate the patent rules. In such cases the violation > will not be discovered for some unknown amount of time. The burden on > .. developers thus mounts with every patent on a[n] .. idea. All these points are true of things with physical instantiations, not just software. Are you therefore advocating getting rid of patents in general? > To allow a technology, encumbered by any known patent holder's > monopoly, as .. any other status) is to give legitimacy to this system > that directly harms development of all software, RMS' (and the FSF's), hostility to the concept of software intellectual property is well known. I wasn't impressed with it the first time I heard it (circa 1982, IIRC), and I'm not impressed with it now. If you all want to mount a campaign against software patents, feel free. I think they are mostly pretty lame, and there have been many excesses allowed by the US patent office (not sure of the status elsewhere). However, please leave the IETF, as an organzation, out. (Individual IETF contibutors are of course free to support you.) The IETF has orthagonal goals. Noel _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 11:00:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImVuf-0006zK-Oq; Mon, 29 Oct 2007 10:48:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImVud-0006tU-Vr for ietf@ietf.org; Mon, 29 Oct 2007 10:48:20 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImVud-0003Y6-IV for ietf@ietf.org; Mon, 29 Oct 2007 10:48:19 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 2AFE81C0103; Mon, 29 Oct 2007 15:48:19 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 267C11C00FD; Mon, 29 Oct 2007 15:48:19 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 19AE758EBBF; Mon, 29 Oct 2007 15:48:19 +0100 (CET) Date: Mon, 29 Oct 2007 15:48:19 +0100 From: Stephane Bortzmeyer To: "Scott O. Bradner" Message-ID: <20071029144819.GA26810@nic.fr> References: <20071029141645.GA22116@nic.fr> <20071029142023.04E96600545@newdev.eecs.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071029142023.04E96600545@newdev.eecs.harvard.edu> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ietf@ietf.org Subject: Re: Free? Software Foundation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Mon, Oct 29, 2007 at 10:20:23AM -0400, Scott O. Bradner wrote a message of 31 lines which said: > you are asking the IETF to not publish an IETF doucment - what else > can you call it? So, each time in a Last Call, someone says "This document should not be published", it is censorship? That's quite insulting for the victims of real censorship. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 11:08:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImW7z-0003aD-W4; Mon, 29 Oct 2007 11:02:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImW7x-0003Zg-UH for ietf@ietf.org; Mon, 29 Oct 2007 11:02:05 -0400 Received: from newdev.eecs.harvard.edu ([140.247.60.212]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImW7x-00049J-M1 for ietf@ietf.org; Mon, 29 Oct 2007 11:02:05 -0400 Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id ED62F6006AF; Mon, 29 Oct 2007 10:59:53 -0400 (EDT) To: bortzmeyer@nic.fr, sob@harvard.edu In-Reply-To: <20071029144819.GA26810@nic.fr> Message-Id: <20071029145953.ED62F6006AF@newdev.eecs.harvard.edu> Date: Mon, 29 Oct 2007 10:59:53 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ietf@ietf.org Subject: Re: Free? Software Foundation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > So, each time in a Last Call, someone says "This document should not >be published", it is censorship? That's quite insulting for the > victims of real censorship. I do not recall another case where the IETF got requests to not publish documents in last call - most of the time there are constructive comments pointing out technical issues that might get fixed before publication. I have seen requests to not publish or delay publishing RFCs that had been submitted to a working group but were not chosen - those requesters were worried about the potential for confusion with the working group output - if memory serves, the RFC was published in almost all of tehse cases - but after a delay so the working group version could get published first in some cases. Scott _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 11:08:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImW35-0006NL-6z; Mon, 29 Oct 2007 10:57:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImW33-0006Md-QA for ietf@ietf.org; Mon, 29 Oct 2007 10:57:01 -0400 Received: from yxa.extundo.com ([83.241.177.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImW2s-00032t-G5 for ietf@ietf.org; Mon, 29 Oct 2007 10:56:56 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l9TEu9hg028839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Oct 2007 15:56:14 +0100 From: Simon Josefsson To: RJ Atkinson References: <6130F950-2671-4612-9334-BB5723458DCB@extremenetworks.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071029:rja@extremenetworks.com::KVLoS1S8nMd4DmDT:40me X-Hashcash: 1:22:071029:ietf@ietf.org::FJjd3acEb35OL4rf:HnPq Date: Mon, 29 Oct 2007 15:56:09 +0100 In-Reply-To: <6130F950-2671-4612-9334-BB5723458DCB@extremenetworks.com> (RJ Atkinson's message of "Sat, 27 Oct 2007 11:57:21 -0400") Message-ID: <874pgageba.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ietf@ietf.org Subject: Re: Silly TLS Auth lobbying X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Did you consider that the IANA allocation policy for the two IANA values required by the document is "IETF Consensus"? The standards track status of the document doesn't matter then. What matters is if the registration meets "IETF Consensus", and the IESG decides this. I think the policies around what "IETF Consensus" means could be made more explicit, especially when it is applied to a document that itself do not require consensus to be published. I do think that the intention is clear, though, to be that registration should only be done if there is consensus in the IETF community that the IANA allocation should be done. /Simon RJ Atkinson writes: > Some important things that the FSF folks seem NOT to understand, > and frankly seem to aggressively NOT want to understand, are: > > - Many RFCs are *not* on the IETF standards track. > > - Any "Experimental RFC" is *not* on the IETF standards track. > So there is no "endorsement" by IETF in publishing such. > > - The IETF has published real standards-track documents that > required patented technology and were known to have > *difficult* license terms on the publication date (think > cryptographic algorithms and scan backwards in rfc-index.txt). > > - There is no history of IETF requiring technology to be freely > available (for either common definition of free). > > > I support the idea that virtually any document ought to be able > to be published as an Informational RFC or Experimental RFC. > Technology that is useful will be adopted if economically sensible, > whether in an RFC or not, whether made a formal standard or not. > By having an open specification, users can at least understand > the properties of the technology that is documented openly. > > Just to be crystal clear, I do support publishing draft-housley-* > as either Informational RFC or Experimental RFC. > > Yours, > > Ran > rja@extremenetworks.com _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 11:28:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImWRV-00058w-4H; Mon, 29 Oct 2007 11:22:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImWRT-00056a-FG for ietf@ietf.org; Mon, 29 Oct 2007 11:22:15 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImWRS-0004Tv-4k for ietf@ietf.org; Mon, 29 Oct 2007 11:22:15 -0400 X-IronPort-AV: E=Sophos;i="4.21,343,1188802800"; d="scan'208";a="183536859" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 29 Oct 2007 08:22:13 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9TFMCS5021066; Mon, 29 Oct 2007 11:22:12 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9TFMCdM029692; Mon, 29 Oct 2007 15:22:12 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id l9TFMC55024876; Mon, 29 Oct 2007 11:22:12 -0400 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) In-reply-to: Your message of Mon, 29 Oct 2007 10:34:11 -0400. <20071029143411.1209F8734F@mercury.lcs.mit.edu> Date: Mon, 29 Oct 2007 11:22:12 -0400 Message-ID: <24875.1193671332@erosen-linux> From: Eric Rosen DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1867; t=1193671332; x=1194535332; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20 |Subject:=20Re=3A=20Experimental=20makes=20sense=20for=20tls-authz=20 |Sender:=20 |To:=20jnc@mercury.lcs.mit.edu=20(Noel=20Chiappa); bh=rH0NfCQDrewRccTirvXKNOouKTPEwBiygFk5UH4tCPg=; b=CX9qXoYqpTsnz6ZYkM2ndff4ttCGUw6IxiQjHvjPb3pnJbVb4WA7YyTfnVTbtKiBBmR8JIrH 7qubOo0LGaZoBIPaHMXYYYCCEhaZPFOS5SZ/UgDvm0empgcYBWmfKjcr; Authentication-Results: rtp-dkim-2; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ietf@ietf.org Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org As a personal political view, I happen to be opposed to the notion of software patents. But I still think that the document in question should be published as Experimental: - It's quite plain that this political view has never been adopted by IETF consensus. (I also think it plain that it has no chance of being adopted by IETF consensus.) - I don't think the IETF considers "this document offends my political point of view" to be a legitimate reason for opposing the document. The degree of passion and/or repetition with which the political view is expressed is irrelevant. (The suppression of a document for political reasons is frequently called "censorship", even if other avenues of publication still exist.) - It's really within the province of each WG to determine whether its standards are implementable by whoever needs to implement them in order for the standard to be successful. This may or may not include open source implementations. - If a particular proposal is technically sound, but not adopted because the WG thinks that its patent encumbrances are a bar to implementation, then it is perfectly valid to publish the proposal as a non-standard track RFC. The only real criterion is that the technical content be interesting or otherwise worth preserving. With regard to the coordinated letter writing attack being waged on this list, well, we're all familiar with the situation in which folks try to get their way by getting lots of non-participants to send scripted messages. Often you can tell that the message writers don't even know what the issues are, but at least most of the letter writing campaigns pretend to be about technical issues; the current campaign doesn't even bother with the pretense! _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 11:34:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImWYd-0005AJ-Mn; Mon, 29 Oct 2007 11:29:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImWYc-0004w2-22 for ietf@ietf.org; Mon, 29 Oct 2007 11:29:38 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImWYN-0004wE-LC for ietf@ietf.org; Mon, 29 Oct 2007 11:29:33 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9TFSqJT020104; Mon, 29 Oct 2007 08:28:52 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9TFSnt0013856; Mon, 29 Oct 2007 08:28:51 -0700 Received: from 172.24.29.58 ([172.24.29.58]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 29 Oct 2007 15:28:50 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 29 Oct 2007 11:28:42 -0400 From: Eric Burger To: Message-ID: Thread-Topic: rejection of patents and standards Thread-Index: AcgaQGLtoTmspIYzEdyuvwAWy4mm/w== In-Reply-To: <200710182147.l9ILl8J09639@f7.net> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: campaigns@fsf.org Subject: Re: rejection of patents and standards X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hate to say it, but the Subject says it all: If you reject *any* standard that infringes on *any* patent, you will be rejecting *standards*. PLEASE talk to a real lawyer before playing one. Just about everything dealing with communications and computing has *some* encumbrance. Since it is expired, it is safe to talk about this example: You invent a really great voice coding algorithm. It is a huge improvement to, but based on, PCM. Guess what - that violates the original PCM patent. Substitute PCM for most any basic technology, and you will most likely be disappointed to see someone has a lock on it. Is this a good thing? Probably not. Is it right? Probably not. Does it promote new technologies? May or may not. Is it the law? Most definitely, now world-wide given the U.S. is now more harmonized with the rest of the world. As we say in the IETF when someone raises an objection: Please write text. If you do not like the encumbered technology in the Housely draft, please submit a draft that you are willing to indemnify to us is not encumbered. If one cannot do something positive, please figure out a way to do something positive. Leaving us without a protocol to do this function is not positive. Thanks. On 10/18/07 5:47 PM, "Karl Berry" wrote: > I ask you to reject > http://tools.ietf.org/wg/tls/draft-housley-tls-authz-extns-07.txt > from the experimental track, as it was rejected on the official track. > A standard that can only be implemented with permission of and payment > to a software patent holder is no standard at all. > > As you know so well, software patents have no place in public standards. > > Thank you for the chance to comment, and all your efforts! > > Karl Berry (programmer) > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 12:28:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImXHK-0006cH-7I; Mon, 29 Oct 2007 12:15:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImXHI-0006by-1U for ietf@ietf.org; Mon, 29 Oct 2007 12:15:48 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImXH7-0007YV-DK for ietf@ietf.org; Mon, 29 Oct 2007 12:15:48 -0400 Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9TGFFZo022035 for ; Mon, 29 Oct 2007 16:15:16 GMT Received: from localhost.east.sun.com (vroom.East.Sun.COM [129.148.19.3]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id l9TGFEoT031004 for ; Mon, 29 Oct 2007 12:15:15 -0400 (EDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9TFX68l010690; Mon, 29 Oct 2007 11:33:06 -0400 (EDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9TFWwut010689; Mon, 29 Oct 2007 11:32:58 -0400 (EDT) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: Bill Fenner In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 29 Oct 2007 11:32:57 -0400 Message-Id: <1193671977.8346.53.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 X-Spam-Score: -1.0 (-) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ietf@ietf.org Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Sun, 2007-10-28 at 09:05 -0700, Bill Fenner wrote: > RFC 2026, section 10.4.(D), gives boilerplate to add to a document > where there is known ipr: > > "The IETF has been notified of intellectual property rights > claimed in regard to some or all of the specification contained > in this document. For more information consult the online list > of claimed rights." > > RFC 3667 removed this policy, because the absence of a notice in the > document doesn't mean that an ipr claim wasn't filed after the RFC was > published. A notice can only tell you that there is a claim, but the > absence of a notice only means that there was no claim at the time of > publication, not that there is no claim. IANAL, but my understanding is that the US patent system has a feature which rewards ignorance and penalizes knowledge: a plaintiff can get "treble" (triple) damages if they can show "willful" infringment -- in other words, if they can show that an infringer was aware of the patent. So notices of this form may help plaintiffs recover more damages in the event of a suit. Given that the boundaries of many/most software patents are vague, and the statements made in IPR disclosures also tend to be vague, it's not at all clear that these notices can protect implementors from being sued for infringement. So who benefits most from the notice? IMHO, it's the people who hold patents, rather than people who want to build things. The same can be said for the current FSF campaign targetting this list: by widely publicizing one or more patents, it makes it much harder for anyone charged with infringement to say they were unaware of the claims. If anyone's counting: I reject denial-of-service attacks on the IETF. I support publication of tls-authz as Experimental. - Bill _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 12:28:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImXOL-0005HI-Qr; Mon, 29 Oct 2007 12:23:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImXOJ-0005Er-HA for ietf@ietf.org; Mon, 29 Oct 2007 12:23:03 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImXOE-0007q9-Ee for ietf@ietf.org; Mon, 29 Oct 2007 12:22:59 -0400 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l9TGIpjh017319; Mon, 29 Oct 2007 09:18:52 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Oct 2007 16:22:28 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 29 Oct 2007 09:22:27 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557084F1F@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Silly TLS Auth lobbying Thread-Index: AcgaLHs8ITLSJVbpQMOMmJi9DMf/9QAGMfJ+ References: <6130F950-2671-4612-9334-BB5723458DCB@extremenetworks.com> From: "Hallam-Baker, Phillip" To: "RJ Atkinson" , X-OriginalArrivalTime: 29 Oct 2007 16:22:28.0237 (UTC) FILETIME=[E5E9E3D0:01C81A47] X-Spam-Score: 1.8 (+) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: Subject: RE: Silly TLS Auth lobbying X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1316695427==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============1316695427== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81A47.E5938F97" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81A47.E5938F97 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If we create confusion by labelling everything RFC we are going to feel = the ill effects caused by that confusion. =20 I know we keep comming across the problem that the RFC numbers are = welded into the infrastructure and nobody seems to want STDs. But we = still have a problem. =20 Perhaps a variant of Klensin's suggestion of documents describing a set = of standards. If this was reduced down to the bare essentials of merely = a set of references we might have documents of the form: =20 IETF-SMTP-2007 =20 [boilerplate] =20 The following documents are normative components of the SMTP standard: RFC 2821 RFC 2822 =20 The following documents are not part of the SMTP standard but SMTP has = normative references to them: None =20 The following documents are non normative: [whatever] =20 [IPR boilerplate] =20 There would be no other content. The document would be credited to IETF. =20 =20 Such a document would replace the current STANDARD designation. All the = documents referenced in such a document would have to be DRAFT or better = on submission and would automatically become STANDARD status on the = document being published. =20 This would not represent a significant change in current practice except = to the extent that at present almost all protocols stick at DRAFT.=20 =20 =20 I would anticipate there being relatively few such standards but the = terms are much more likely to be used. I am not going to remember two = sets of numeric designations and I don't think anyone else will either. =20 Switching from the term STD to IETF reminds people of where the = documents come from. It also avoids an unfortunate choice of acronym. = Semiotics do matter. =20 =20 The use of a year designator would allow reference to be made to a = particular version of the SMTP specification if that was appropriate. = Year designators are preferred over version numbers in this case as = version numbers have semantics associated with them. They also remind = people when a standard has not been revised for some time.=20 =20 ________________________________ From: RJ Atkinson [mailto:rja@extremenetworks.com] Sent: Sat 27/10/2007 11:57 AM To: ietf@ietf.org Subject: Silly TLS Auth lobbying Some important things that the FSF folks seem NOT to understand, and frankly seem to aggressively NOT want to understand, are: - Many RFCs are *not* on the IETF standards track. - Any "Experimental RFC" is *not* on the IETF standards track. So there is no "endorsement" by IETF in publishing such. - The IETF has published real standards-track documents that required patented technology and were known to have *difficult* license terms on the publication date (think cryptographic algorithms and scan backwards in rfc-index.txt). - There is no history of IETF requiring technology to be freely available (for either common definition of free). I support the idea that virtually any document ought to be able to be published as an Informational RFC or Experimental RFC. Technology that is useful will be adopted if economically sensible, whether in an RFC or not, whether made a formal standard or not. By having an open specification, users can at least understand the properties of the technology that is documented openly. Just to be crystal clear, I do support publishing draft-housley-* as either Informational RFC or Experimental RFC. Yours, Ran rja@extremenetworks.com _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ------_=_NextPart_001_01C81A47.E5938F97 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Silly TLS Auth lobbying=0A= =0A= =0A= =0A=
=0A=
If we create = confusion by labelling everything RFC we are going to feel the ill = effects caused by that confusion.
=0A=
 
=0A=
I know we keep comming across = the problem that the RFC numbers are welded into the infrastructure and = nobody seems to want STDs. But we still have a problem.
=0A=
 
=0A=
Perhaps a variant of = Klensin's suggestion of documents describing a set of standards. If this = was reduced down to the bare essentials of merely a set of references we = might have documents of the form:
=0A=
 
=0A=
IETF-SMTP-2007
=0A=
 
=0A=
[boilerplate]
=0A=
 
=0A=
The following documents are = normative components of the SMTP standard:
=0A=
    RFC = 2821
=0A=
    RFC = 2822
=0A=
 
=0A=
The following documents are = not part of the SMTP standard but SMTP has normative references to = them:
=0A=
    = None
=0A=
 
=0A=
The following documents are = non normative:
=0A=
    = [whatever]
=0A=
 
=0A=
[IPR boilerplate]
=0A=
 
=0A=
There would be no other = content. The document would be credited to IETF.
=0A=
 
=0A=
 
=0A=
Such a document would replace = the current STANDARD designation. All the documents referenced in such a = document would have to be DRAFT or better on submission and would = automatically become STANDARD status on the document being = published.
=0A=
 
=0A=
This would not represent a = significant change in current practice except to the extent that at = present almost all protocols stick at DRAFT.
=0A=
 
=0A=
 
=0A=
I would anticipate there = being relatively few such standards but the terms are much more likely = to be used. I am not going to remember two sets of numeric designations = and I don't think anyone else will either.
=0A=
 
=0A=
Switching from the term STD = to IETF reminds people of where the documents come from. It also avoids = an unfortunate choice of acronym. Semiotics do matter.
=0A=
 
=0A=
 
=0A=
The use of a year designator = would allow reference to be made to a particular version of the SMTP = specification if that was appropriate. Year designators are preferred = over version numbers in this case as version numbers have semantics = associated with them. They also remind people when a standard has not = been revised for some time.
=0A=
 
=0A=

=0A=
=0A= From: RJ Atkinson = [mailto:rja@extremenetworks.com]
Sent: Sat 27/10/2007 11:57 = AM
To: ietf@ietf.org
Subject: Silly TLS Auth = lobbying

=0A=

=0A=

Some important things that the FSF folks seem NOT to = understand,
and frankly seem to aggressively NOT want to understand, = are:

- Many RFCs are *not* on the IETF standards track.

- = Any "Experimental RFC" is *not* on the IETF standards = track.
   So there is no "endorsement" by IETF in = publishing such.

- The IETF has published real standards-track = documents that
   required patented technology and were = known to have
   *difficult* license terms on the = publication date (think
   cryptographic algorithms and = scan backwards in rfc-index.txt).

- There is no history of IETF = requiring technology to be freely
   available (for either = common definition of free).


I support the idea that virtually = any document ought to be able
to be published as an Informational RFC = or Experimental RFC.
Technology that is useful will be adopted if = economically sensible,
whether in an RFC or not, whether made a = formal standard or not.
By having an open specification, users can at = least understand
the properties of the technology that is documented = openly.

Just to be crystal clear, I do support publishing = draft-housley-*
as either Informational RFC or Experimental = RFC.

Yours,

Ran
rja@extremenetworks.com


_____= __________________________________________
Ietf mailing = list
Ietf@ietf.org
https://www1.ietf.or= g/mailman/listinfo/ietf

------_=_NextPart_001_01C81A47.E5938F97-- --===============1316695427== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============1316695427==-- From ietf-bounces@ietf.org Mon Oct 29 12:28:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImXHK-0006cH-7I; Mon, 29 Oct 2007 12:15:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImXHI-0006by-1U for ietf@ietf.org; Mon, 29 Oct 2007 12:15:48 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImXH7-0007YV-DK for ietf@ietf.org; Mon, 29 Oct 2007 12:15:48 -0400 Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9TGFFZo022035 for ; Mon, 29 Oct 2007 16:15:16 GMT Received: from localhost.east.sun.com (vroom.East.Sun.COM [129.148.19.3]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id l9TGFEoT031004 for ; Mon, 29 Oct 2007 12:15:15 -0400 (EDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9TFX68l010690; Mon, 29 Oct 2007 11:33:06 -0400 (EDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9TFWwut010689; Mon, 29 Oct 2007 11:32:58 -0400 (EDT) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: Bill Fenner In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 29 Oct 2007 11:32:57 -0400 Message-Id: <1193671977.8346.53.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 X-Spam-Score: -1.0 (-) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ietf@ietf.org Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Sun, 2007-10-28 at 09:05 -0700, Bill Fenner wrote: > RFC 2026, section 10.4.(D), gives boilerplate to add to a document > where there is known ipr: > > "The IETF has been notified of intellectual property rights > claimed in regard to some or all of the specification contained > in this document. For more information consult the online list > of claimed rights." > > RFC 3667 removed this policy, because the absence of a notice in the > document doesn't mean that an ipr claim wasn't filed after the RFC was > published. A notice can only tell you that there is a claim, but the > absence of a notice only means that there was no claim at the time of > publication, not that there is no claim. IANAL, but my understanding is that the US patent system has a feature which rewards ignorance and penalizes knowledge: a plaintiff can get "treble" (triple) damages if they can show "willful" infringment -- in other words, if they can show that an infringer was aware of the patent. So notices of this form may help plaintiffs recover more damages in the event of a suit. Given that the boundaries of many/most software patents are vague, and the statements made in IPR disclosures also tend to be vague, it's not at all clear that these notices can protect implementors from being sued for infringement. So who benefits most from the notice? IMHO, it's the people who hold patents, rather than people who want to build things. The same can be said for the current FSF campaign targetting this list: by widely publicizing one or more patents, it makes it much harder for anyone charged with infringement to say they were unaware of the claims. If anyone's counting: I reject denial-of-service attacks on the IETF. I support publication of tls-authz as Experimental. - Bill _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 12:28:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImXOL-0005HI-Qr; Mon, 29 Oct 2007 12:23:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImXOJ-0005Er-HA for ietf@ietf.org; Mon, 29 Oct 2007 12:23:03 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImXOE-0007q9-Ee for ietf@ietf.org; Mon, 29 Oct 2007 12:22:59 -0400 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l9TGIpjh017319; Mon, 29 Oct 2007 09:18:52 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Oct 2007 16:22:28 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 29 Oct 2007 09:22:27 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557084F1F@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Silly TLS Auth lobbying Thread-Index: AcgaLHs8ITLSJVbpQMOMmJi9DMf/9QAGMfJ+ References: <6130F950-2671-4612-9334-BB5723458DCB@extremenetworks.com> From: "Hallam-Baker, Phillip" To: "RJ Atkinson" , X-OriginalArrivalTime: 29 Oct 2007 16:22:28.0237 (UTC) FILETIME=[E5E9E3D0:01C81A47] X-Spam-Score: 1.8 (+) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: Subject: RE: Silly TLS Auth lobbying X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1316695427==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============1316695427== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81A47.E5938F97" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81A47.E5938F97 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If we create confusion by labelling everything RFC we are going to feel = the ill effects caused by that confusion. =20 I know we keep comming across the problem that the RFC numbers are = welded into the infrastructure and nobody seems to want STDs. But we = still have a problem. =20 Perhaps a variant of Klensin's suggestion of documents describing a set = of standards. If this was reduced down to the bare essentials of merely = a set of references we might have documents of the form: =20 IETF-SMTP-2007 =20 [boilerplate] =20 The following documents are normative components of the SMTP standard: RFC 2821 RFC 2822 =20 The following documents are not part of the SMTP standard but SMTP has = normative references to them: None =20 The following documents are non normative: [whatever] =20 [IPR boilerplate] =20 There would be no other content. The document would be credited to IETF. =20 =20 Such a document would replace the current STANDARD designation. All the = documents referenced in such a document would have to be DRAFT or better = on submission and would automatically become STANDARD status on the = document being published. =20 This would not represent a significant change in current practice except = to the extent that at present almost all protocols stick at DRAFT.=20 =20 =20 I would anticipate there being relatively few such standards but the = terms are much more likely to be used. I am not going to remember two = sets of numeric designations and I don't think anyone else will either. =20 Switching from the term STD to IETF reminds people of where the = documents come from. It also avoids an unfortunate choice of acronym. = Semiotics do matter. =20 =20 The use of a year designator would allow reference to be made to a = particular version of the SMTP specification if that was appropriate. = Year designators are preferred over version numbers in this case as = version numbers have semantics associated with them. They also remind = people when a standard has not been revised for some time.=20 =20 ________________________________ From: RJ Atkinson [mailto:rja@extremenetworks.com] Sent: Sat 27/10/2007 11:57 AM To: ietf@ietf.org Subject: Silly TLS Auth lobbying Some important things that the FSF folks seem NOT to understand, and frankly seem to aggressively NOT want to understand, are: - Many RFCs are *not* on the IETF standards track. - Any "Experimental RFC" is *not* on the IETF standards track. So there is no "endorsement" by IETF in publishing such. - The IETF has published real standards-track documents that required patented technology and were known to have *difficult* license terms on the publication date (think cryptographic algorithms and scan backwards in rfc-index.txt). - There is no history of IETF requiring technology to be freely available (for either common definition of free). I support the idea that virtually any document ought to be able to be published as an Informational RFC or Experimental RFC. Technology that is useful will be adopted if economically sensible, whether in an RFC or not, whether made a formal standard or not. By having an open specification, users can at least understand the properties of the technology that is documented openly. Just to be crystal clear, I do support publishing draft-housley-* as either Informational RFC or Experimental RFC. Yours, Ran rja@extremenetworks.com _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ------_=_NextPart_001_01C81A47.E5938F97 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Silly TLS Auth lobbying=0A= =0A= =0A= =0A=
=0A=
If we create = confusion by labelling everything RFC we are going to feel the ill = effects caused by that confusion.
=0A=
 
=0A=
I know we keep comming across = the problem that the RFC numbers are welded into the infrastructure and = nobody seems to want STDs. But we still have a problem.
=0A=
 
=0A=
Perhaps a variant of = Klensin's suggestion of documents describing a set of standards. If this = was reduced down to the bare essentials of merely a set of references we = might have documents of the form:
=0A=
 
=0A=
IETF-SMTP-2007
=0A=
 
=0A=
[boilerplate]
=0A=
 
=0A=
The following documents are = normative components of the SMTP standard:
=0A=
    RFC = 2821
=0A=
    RFC = 2822
=0A=
 
=0A=
The following documents are = not part of the SMTP standard but SMTP has normative references to = them:
=0A=
    = None
=0A=
 
=0A=
The following documents are = non normative:
=0A=
    = [whatever]
=0A=
 
=0A=
[IPR boilerplate]
=0A=
 
=0A=
There would be no other = content. The document would be credited to IETF.
=0A=
 
=0A=
 
=0A=
Such a document would replace = the current STANDARD designation. All the documents referenced in such a = document would have to be DRAFT or better on submission and would = automatically become STANDARD status on the document being = published.
=0A=
 
=0A=
This would not represent a = significant change in current practice except to the extent that at = present almost all protocols stick at DRAFT.
=0A=
 
=0A=
 
=0A=
I would anticipate there = being relatively few such standards but the terms are much more likely = to be used. I am not going to remember two sets of numeric designations = and I don't think anyone else will either.
=0A=
 
=0A=
Switching from the term STD = to IETF reminds people of where the documents come from. It also avoids = an unfortunate choice of acronym. Semiotics do matter.
=0A=
 
=0A=
 
=0A=
The use of a year designator = would allow reference to be made to a particular version of the SMTP = specification if that was appropriate. Year designators are preferred = over version numbers in this case as version numbers have semantics = associated with them. They also remind people when a standard has not = been revised for some time.
=0A=
 
=0A=

=0A=
=0A= From: RJ Atkinson = [mailto:rja@extremenetworks.com]
Sent: Sat 27/10/2007 11:57 = AM
To: ietf@ietf.org
Subject: Silly TLS Auth = lobbying

=0A=

=0A=

Some important things that the FSF folks seem NOT to = understand,
and frankly seem to aggressively NOT want to understand, = are:

- Many RFCs are *not* on the IETF standards track.

- = Any "Experimental RFC" is *not* on the IETF standards = track.
   So there is no "endorsement" by IETF in = publishing such.

- The IETF has published real standards-track = documents that
   required patented technology and were = known to have
   *difficult* license terms on the = publication date (think
   cryptographic algorithms and = scan backwards in rfc-index.txt).

- There is no history of IETF = requiring technology to be freely
   available (for either = common definition of free).


I support the idea that virtually = any document ought to be able
to be published as an Informational RFC = or Experimental RFC.
Technology that is useful will be adopted if = economically sensible,
whether in an RFC or not, whether made a = formal standard or not.
By having an open specification, users can at = least understand
the properties of the technology that is documented = openly.

Just to be crystal clear, I do support publishing = draft-housley-*
as either Informational RFC or Experimental = RFC.

Yours,

Ran
rja@extremenetworks.com


_____= __________________________________________
Ietf mailing = list
Ietf@ietf.org
https://www1.ietf.or= g/mailman/listinfo/ietf

------_=_NextPart_001_01C81A47.E5938F97-- --===============1316695427== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============1316695427==-- From ietf-bounces@ietf.org Mon Oct 29 13:27:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImYAf-0003RH-EJ; Mon, 29 Oct 2007 13:13:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImYAe-0003JC-5u for ietf@ietf.org; Mon, 29 Oct 2007 13:13:00 -0400 Received: from dhcp-18-188-10-61.dyn.mit.edu ([18.188.10.61] helo=carter-zimmerman.suchdamage.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImYAT-0002Sg-2I for ietf@ietf.org; Mon, 29 Oct 2007 13:12:55 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 809214A45; Mon, 29 Oct 2007 13:12:33 -0400 (EDT) From: Sam Hartman To: erosen@cisco.com References: <24875.1193671332@erosen-linux> Date: Mon, 29 Oct 2007 13:12:33 -0400 In-Reply-To: <24875.1193671332@erosen-linux> (Eric Rosen's message of "Mon, 29 Oct 2007 11:22:12 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Noel Chiappa , ietf@ietf.org Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>>>> "Eric" == Eric Rosen writes: Eric> - I don't think the IETF considers "this document offends my Eric> political point of view" to be a legitimate reason for Eric> opposing the document. The degree of passion and/or Eric> repetition with which the political view is expressed is Eric> irrelevant. (The suppression of a document for political Eric> reasons is frequently called "censorship", even if other Eric> avenues of publication still exist.) I have to disagree with you here. I think political issues, like everything else need to be considered in judging whether the IETF or a WG has rough consensus to publish a document. That said, judging whether the participants are engaged in the discussion, have taken the time to come up to speed on the issues, are involved in the IETF, etc is very appropriate when deciding how much to weigh opinions expressed. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 13:38:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImYPV-0006iM-2H; Mon, 29 Oct 2007 13:28:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImYPT-0006hd-Oj; Mon, 29 Oct 2007 13:28:19 -0400 Received: from dhcp-18-188-10-61.dyn.mit.edu ([18.188.10.61] helo=carter-zimmerman.suchdamage.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImYP6-0003GP-Ik; Mon, 29 Oct 2007 13:28:19 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F2C264A45; Mon, 29 Oct 2007 13:27:35 -0400 (EDT) From: Sam Hartman To: ietf@ietf.org,iesg@ietf.org, nicolas.williams@sun.com Date: Mon, 29 Oct 2007 13:27:35 -0400 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: saag@mit.edu Subject: Minor addition to draft-williams-on-channel-binding; one week to respond X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Folks, while attempting to use draft-williams-on-channel-binding in the SASL working group, we came across an ambiguity. In response to IETF last call comments we added the concept of a unique prefix and a registry of prefixes for channel binding type. We added a requirement that applications make sure that one channel could not conflict with another channel type. However we didn't specify how the prefix was to be used. This ambiguity made using specifications more complex than needed. So, we propose to actually say that the prefix needs to be a prefix. This change has the support of the authors, myself, and members of the SASL community including the author of the document trying to use this mechanism. In particular, we propose adding the following text: >> "Under this framework, channel bindings MUST start with the >> channel binding unique prefix followed by a colon (ASCII 0x3A). >> " The document is currently in auth48. I will approve this change if there are not objections in a week. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 14:01:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImYma-0000TS-Sn; Mon, 29 Oct 2007 13:52:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImYmZ-0000RX-1x for ietf@ietf.org; Mon, 29 Oct 2007 13:52:11 -0400 Received: from trinitario.schlyter.se ([195.47.254.10] helo=mail.schlyter.se) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImYmW-0003qM-Es for ietf@ietf.org; Mon, 29 Oct 2007 13:52:08 -0400 Received: from [172.27.173.126] (unknown [65.91.246.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: roy) by mail.schlyter.se (Postfix) with ESMTP id C273B2DCC3 for ; Mon, 29 Oct 2007 18:52:05 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ietf@ietf.org From: Roy Arends Date: Mon, 29 Oct 2007 10:52:02 -0700 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: Nominet position paper about Signing the Root. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Fellow IETF-ers. We (Nominet) have published a position paper that examines the issues currently preventing widespread adoption of DNSSEC with a special focus on the issues involved in signing the root zone. We also suggest a solution to signing the root that we believe balances the requirements of all those affected. The paper can be found here: http://www.nominet.org.uk/digitalAssets/25692_Signing_the_Root.pdf You can find the announcement here: http://www.nominet.org.uk/news/latest/?contentId=4549 With kind regards, Roy Arends Senior Researcher Nominet UK _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 14:44:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImZWL-0000PU-Ic; Mon, 29 Oct 2007 14:39:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImZWJ-0000Or-8U for ietf@ietf.org; Mon, 29 Oct 2007 14:39:27 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImZWI-0006HV-SW for ietf@ietf.org; Mon, 29 Oct 2007 14:39:27 -0400 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9TIch7r010277; Mon, 29 Oct 2007 11:38:43 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id KAA09708; Mon, 29 Oct 2007 10:38:43 -0800 (PST) Date: Mon, 29 Oct 2007 10:38:43 -0800 (PST) Message-Id: <200710291838.KAA09708@gra.isi.edu> To: fenner@gmail.com, sommerfeld@sun.com X-Sun-Charset: US-ASCII X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: ietf@ietf.org Subject: Re: Experimental makes sense for tls-authz X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org *> *> So who benefits most from the notice? The lawyers. Bob Braden _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 14:44:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImZQO-0003U4-KB; Mon, 29 Oct 2007 14:33:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImZQM-0003RU-UF for ietf@ietf.org; Mon, 29 Oct 2007 14:33:18 -0400 Received: from smtp105.rog.mail.re2.yahoo.com ([206.190.36.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ImZQ8-00076j-Qb for ietf@ietf.org; Mon, 29 Oct 2007 14:33:12 -0400 Received: (qmail 66172 invoked from network); 29 Oct 2007 18:32:41 -0000 Received: from unknown (HELO connotech.com) (t2i6@rogers.com@209.148.165.15 with plain) by smtp105.rog.mail.re2.yahoo.com with SMTP; 29 Oct 2007 18:32:41 -0000 X-YMail-OSG: rRrc1nkVM1nNQQY7JYqPnUZ_gzKov_0DdCJ3KCbAuJgRI_gv6FzQgOfDmfp4IPPMzA-- Message-ID: <47262846.2080402@connotech.com> Date: Mon, 29 Oct 2007 13:36:54 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Arends References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ietf@ietf.org Subject: Re: Nominet position paper about Signing the Root. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Dear Roy and IETF-ers: A quick reaction to this document: Good contribution: at last there is a documented proposition for the view that DNSSEC root signature is strictly a technical management issue. This document uses a two-tiered organization for root key management, respectively handling the KSK private keys and ZSK private keys for signature operations. Such a two-tiered organization is deemed to be present in the final solution. Maybe a difficulty lies in the selection of RZM as one of the two tiers. The document author(s) should check if a current project at IANA is indeed to integrate the RZM function in IANA operations. In view of the possible merger of IANA and the RZM function, the document author(s) should state what minimal conditions, in terms of institutional independence, they expect between the two tiers of control over the DNSSEC root keys. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 15:34:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImaCV-0005fk-GB; Mon, 29 Oct 2007 15:23:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImaCT-0005eB-M0 for ietf@ietf.org; Mon, 29 Oct 2007 15:23:01 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImaA1-0000wW-Uy for ietf@ietf.org; Mon, 29 Oct 2007 15:23:01 -0400 X-IronPort-AV: E=Sophos;i="4.21,343,1188792000"; d="scan'208";a="135817539" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 29 Oct 2007 15:20:25 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9TJKOo9030020 for ; Mon, 29 Oct 2007 15:20:24 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9TJKOBI003524 for ; Mon, 29 Oct 2007 19:20:24 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 15:20:19 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.17.26]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 15:20:18 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 29 Oct 2007 14:20:19 -0500 To: ietf@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 29 Oct 2007 19:20:18.0789 (UTC) FILETIME=[BE0EE950:01C81A60] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15508.000 X-TM-AS-Result: No--5.789400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2076; t=1193685624; x=1194549624; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Oppose=20draft-carpenter-ipr-patent-frswds-00 |Sender:=20 |To:=20ietf@ietf.org; bh=XW6c0vf6Vwmy4k1NCa/crSjMHniyoWsdx6MkSJs7AmI=; b=gvcx3DDL9Vt4v6NTxjKQqyzXCJCWG4Tbar12F7D28em6Nkt0tQdax6EFkPPBS1bNiV9+tID+ 3GPVh+hZyJFZosVBHnUoAKPxfqsS+rj1G2YkAACnykBIBmhCsop6aJ2W; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: Oppose draft-carpenter-ipr-patent-frswds-00 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org http://www.ietf.org/internet-drafts/draft-carpenter-ipr-patent-frswds-00.txt offers this text as a modification to RFC 2026: A specification from which at least two independent and interoperable implementations from different code bases have been developed, of which at least one is available as free software, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. I oppose this text in any IETF document because it is counter to vendor implementations (*any* vendor implementations) to achieve Draft Standard status of a document, and that's bad for the IETF. For example, take two vendors: Vendor-A and Vendor-B. One of the vendor's has legitimate IPR claims on a PS RFC, the other either has a license on that IPR from the inventing vendor, or has implemented it under the IPR claim's royalty-free IPR statement (just as some IPR has in its claim into the IETF). Some PS RFCs are either very little used or very complicated, meaning they aren't very popular (to the Open Source community) or cost to much (time/money) to develop. So unless someone decides to do the work anyway (which doesn't make sense to require) - the suggested text above prevents both Vendor-A's and Vendor-B's implementations from being considered for elevation of this PS RFC to DS RFC *because* they (for some crazy reason) want to charge money for the products where this implementation can be utilized. BTW - isn't charging money for products how vendor's stay in business? The IETF preventing vendors from making money in order for the IETF to consider progressing a PS RFC to DS RFC is completely counterintuitive and will reduce vendor participation in the IETF. As much as some might applaud that result, it will mean either the demise of the IETF (without sponsors and vendor participants attending meetings to pay the bills), or that everything is just fine as a PS - which makes the suggested text above completely useless. James _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 15:52:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImaQ0-0007db-Ll; Mon, 29 Oct 2007 15:37:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImaPy-0007ZE-S1 for ietf@ietf.org; Mon, 29 Oct 2007 15:36:58 -0400 Received: from mail26c.sbc-webhosting.com ([216.173.237.166]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ImaNm-0001Su-91 for ietf@ietf.org; Mon, 29 Oct 2007 15:36:58 -0400 Received: from mx74.stngva01.us.mxservers.net (204.202.242.145) by mail26c.sbc-webhosting.com (RS ver 1.0.95vs) with SMTP id 2-0663696462 for ; Mon, 29 Oct 2007 15:34:23 -0400 (EDT) Received: from mmm2630.sbc-webhosting.com [216.173.237.89] (EHLO mmm2630.sbc-webhosting.com) by mx74.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id 57436274.19813.376.mx74.stngva01.us.mxservers.net; Mon, 29 Oct 2007 15:28:53 -0400 (EDT) Received: (qmail 64292 invoked from network); 29 Oct 2007 19:34:20 -0000 Received: from unknown (HELO LROSENTOSHIBA) (lrosen@208.106.45.202) by with ESMTPA; 29 Oct 2007 19:34:20 -0000 From: "Lawrence Rosen" To: References: <18199.55877.791858.498365@swbmbp.local><03d501c811dc$031404a0$6401a8c0@LROSENTOSHIBA><877iljv6ed.fsf@mocca.josefsson.org><042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA><2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com><471A5668.8060505@gmail.com><048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA><20071022195723.4D9A22202DA@quill.bollow.ch><20071023105651.8D9AC2202DA@quill.bollow.ch><87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> <87fy00vn1l.fsf@mocca.josefsson.org> <471FB60B.3070304@gmail.com> <20071024214601.28e866ce@cs.columbia.edu> <00d801c81689$f64c5f30$6401a8c0@LROSENTOSHIBA> <4720FCFA.7080009@cs. utk.edu> Date: Mon, 29 Oct 2007 12:33:10 -0700 Organization: Rosenlaw & Einschlag Message-ID: <020d01c81a62$8a7d6510$6401a8c0@LROSENTOSHIBA> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4720FCFA.7080009@cs.utk.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgXRe3Omf+4YhEXTWO0UzB28UYBQgDG9zdA X-Spam: [F=0.0043103448; heur=0.500(-19500); stat=0.010; spamtraq-heur=0.300(2007101727)] X-MAIL-FROM: X-SOURCE-IP: [216.173.237.89] X-SF-Loop: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Subject: RE: When is using patented technology appropriate? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lrosen@rosenlaw.com List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Keith Moore wrote: > For several reasons, it is difficult to imagine an IETF-wide procedure > that allows the existence of a patent to trump other considerations of > protocol feasibility and deployability: Who suggested otherwise? It is not the existence of the patent that matters, but its unavailability under license terms that allow implementation in *any* software. The more feasible and deployable the protocol, the more important will be FOSS implementations. Who's trumping who? /Larry > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Thursday, October 25, 2007 1:31 PM > To: lrosen@rosenlaw.com > Cc: ietf@ietf.org > Subject: Re: When is using patented technology appropriate? > > Lawrence Rosen wrote: > > Steven Bellovin wrote: > > > >> Right. Any IPR policy has to acknowledge the fact that relevant > >> patents can be owned by non-troll non-participants. (Too many > >> negatives there -- what I'm saying is that IETFers don't know of all > >> patents in the space, and there are real patent owners who care about > >> their patents, even though they aren't trolls.) > >> > > > > I agree, but I suggest that our new IPR policy ought to set expectations > for > > how we deal procedurally with such outside encumbrances when discovered. > The > > defensive termination provision in most contributors' IETF patent grants > can > > also help to protect our specifications from trolls and some third-party > > patent owners, depending upon how those grants are worded. > > > For several reasons, it is difficult to imagine an IETF-wide procedure > that allows the existence of a patent to trump other considerations of > protocol feasibility and deployability: > > - Many patents are believed to be invalid or indefensible. IETF as an > organization cannot get in a position of deciding whether a patent is > valid or defensible, both because it doesn't really have the resources > or in-house expertise to do this, and because the only way to know for > sure is to go through a lengthy court process, perhaps in several > different countries. And yet, if there is a consensus among those who > are invested in the technology that a particular patent isn't going to > present an actual obstacle to deployment, it makes sense to let it go > forward. > > The alternative - letting a dubious patent block or significantly delay > approval of an IETF standard - gives dubious patents much more power > than they deserve. > > - A similar argument can be made for patents that are valid and > defensible, but for which the applicability to a given protocol is > dubious. > > - There have been cases in the past where apparently valid and > applicable patents, existed but would expire soon. Some of our > standards appear have a useful lifetime of many decades. From that > point of view, a patent that has been in force for a few years might be > a short-term concern. Whether this is the case depends on many factors, > including the remaining lifetime of the patent and the nature of the > protocol under discussion. An IETF-wide policy doesn't seem to make > sense here, especially if the effect of that policy were to delay work > on a protocol that probably wouldn't be ready for deployment until the > patent had expired, or nearly so, anyway. > > - There are cases for which a patent with an RAND license presents an > insignificant barrier to deployment, because a substantial monetary > investment would be required in any event to implement a protocol. For > instance, a protocol that inherently requires expensive hardware to > implement, but for which the license fee is a small portion of that > required to pay for the hardware. Again, this is something that needs > to be evaluated on a case-by-case basis. > > - Just because it appears at first that a protocol might be impaired by > the existence of a patent, doesn't mean that a workaround won't be found > as the protocol is developed. This has happened many times. Also, > patent holders have been known to make licenses available under more > attractive terms precisely because the technology was being considered > for an IETF standard. That kind of pressure/encouragement might well be > more effective at making useful technology available to the Internet > community than a blanket patent policy. > > Speaking as someone who has been involved in IETF for about 17 years > now, by far the best way to ensure that IETF protocols to be safe for > open source implementors is for open source implementors to participate > in IETF working groups. IETF's policy of rough consensus means that > every interested party has a strong voice when it comes to objecting to > things that will hamper implementation or deployment. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 15:56:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imacv-0005O7-75; Mon, 29 Oct 2007 15:50:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imacu-0005Nw-0F for ietf@ietf.org; Mon, 29 Oct 2007 15:50:20 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imact-000239-IS for ietf@ietf.org; Mon, 29 Oct 2007 15:50:19 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l9TJi2iO014988 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Oct 2007 15:44:02 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Mon, 29 Oct 2007 15:44:16 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ietf@ietf.org Subject: Re: Oppose draft-carpenter-ipr-patent-frswds-00 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I admit to finding the discussion about Draft standards a bit theoretical, given how few RFCs ever make it there. As a rough estimate, http://www.rfc-editor.org/rfcxx00.html#Draft shows a rate of 20 out of a 1000. On Oct 29, 2007, at 3:20 PM, James M. Polk wrote: > http://www.ietf.org/internet-drafts/draft-carpenter-ipr-patent- > frswds-00.txt > offers this text as a modification to RFC 2026: > > A specification from which at least two independent and > interoperable > implementations from different code bases have been developed, of > which at least one is available as free software, and for which > sufficient successful operational experience has been obtained, > may be elevated to the "Draft Standard" level. > > I oppose this text in any IETF document because it is counter to > vendor implementations (*any* vendor implementations) to achieve > Draft Standard status of a document, and that's bad for the IETF. > > For example, take two vendors: Vendor-A and Vendor-B. > > One of the vendor's has legitimate IPR claims on a PS RFC, the > other either has a license on that IPR from the inventing vendor, > or has implemented it under the IPR claim's royalty-free IPR > statement (just as some IPR has in its claim into the IETF). > > Some PS RFCs are either very little used or very complicated, > meaning they aren't very popular (to the Open Source community) or > cost to much (time/money) to develop. So unless someone decides to > do the work anyway (which doesn't make sense to require) - the > suggested text above prevents both Vendor-A's and Vendor-B's > implementations from being considered for elevation of this PS RFC > to DS RFC *because* they (for some crazy reason) want to charge > money for the products where this implementation can be utilized. > > BTW - isn't charging money for products how vendor's stay in business? > > The IETF preventing vendors from making money in order for the IETF > to consider progressing a PS RFC to DS RFC is completely > counterintuitive and will reduce vendor participation in the IETF. > As much as some might applaud that result, it will mean either the > demise of the IETF (without sponsors and vendor participants > attending meetings to pay the bills), or that everything is just > fine as a PS - which makes the suggested text above completely > useless. > > James > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 16:12:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imapu-0008Cl-N1; Mon, 29 Oct 2007 16:03:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imapt-0008BO-2d for ietf@ietf.org; Mon, 29 Oct 2007 16:03:45 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imaps-00033E-OL for ietf@ietf.org; Mon, 29 Oct 2007 16:03:44 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 49E0F1EE3B8; Mon, 29 Oct 2007 16:03:44 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raLqari5YVlF; Mon, 29 Oct 2007 16:03:41 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 2BB151EE3AC; Mon, 29 Oct 2007 16:03:36 -0400 (EDT) Message-ID: <47263C98.6080703@cs.utk.edu> Date: Mon, 29 Oct 2007 16:03:36 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: lrosen@rosenlaw.com References: <877iljv6ed.fsf@mocca.josefsson.org><042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA><2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com><471A5668.8060505@gmail.com><048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA><20071022195723.4D9A22202DA@quill.bollow.ch><20071023105651.8D9AC2202DA@quill.bollow.ch><87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> <87fy00vn1l.fsf@mocca.josefsson.org> <471FB60B.3070304@gmail.com> <20071024214601.28e866ce@cs.columbia.edu> <00d801c81689$f64c5f30$6401a8c0@LROSENTOSHIBA> <4720FCFA.7080009@cs. utk.edu> <020d01c81a62$8a7d6510$6401a8c0@LROSENTOSHIBA> In-Reply-To: <020d01c81a62$8a7d6510$6401a8c0@LROSENTOSHIBA> X-Enigmail-Version: 0.95.4 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ietf@ietf.org Subject: Re: When is using patented technology appropriate? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Lawrence Rosen wrote: > Keith Moore wrote: > >> For several reasons, it is difficult to imagine an IETF-wide procedure >> that allows the existence of a patent to trump other considerations of >> protocol feasibility and deployability: >> > > Who suggested otherwise? It is not the existence of the patent that matters, > but its unavailability under license terms that allow implementation in > *any* software. > _and_ its validity, _and_ its applicability, both of which can be subjective and difficult to determine conclusively without long delays and excessive expense. so we have to make judgments. and by "we" I mean individuals participating in IETF, not IETF itself. > The more feasible and deployable the protocol, the more important will be > FOSS implementations. > only relative to other protocols in the same space. granted that patents are the bane of any open standards-making organization, because patents do exactly the opposite of what open standards do. at the same time, we can't let FUD about patents become a denial of service attack to IETF efforts. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 16:12:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imasq-00016V-BD; Mon, 29 Oct 2007 16:06:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imasi-0000yY-Ap; Mon, 29 Oct 2007 16:06:40 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imash-0003D9-Kh; Mon, 29 Oct 2007 16:06:40 -0400 Received: from beethoven.local ([::ffff:209.183.196.229]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Mon, 29 Oct 2007 16:01:25 -0400 id 015880FB.47263C15.00005BB7 Message-ID: <47263CC1.8000104@thinkingcat.com> Date: Mon, 29 Oct 2007 16:04:17 -0400 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: ietf@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: pmol@ietf.org, IESG Subject: A question about [Fwd: WG Review: Performance Metrics at Other Layers (pmol)] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At the Application Performance Metrics BoF in Chicago, there was a lot of discussion about whether or how to best capture expertise in the area of performance metrics for application to IETF protocols. There seemed to be 2 separate questions on the table: 1/ how, and 2/ whether to generalize a performance metric framework for IETF protocols. The proposed PMOL WG addresses the first question -- how to do it. On the second point -- the question is really about whether the IETF community as a whole supports/values performance metrics and will invest the effort in using any general framework for existing/new protocols. I believe the folks that joined the PMOL mailing list after the APM BoF are assuming that support is there. I suggest that now is an excellent time for folks _not_ involved in the PMOL effort, but who are working on protocols that could/should make use of its output, to voice some opinions on whether or not this approach is helpful/will be useful to them in future protocols. Leslie. -------- Original Message -------- Subject: WG Review: Performance Metrics at Other Layers (pmol) Date: Mon, 22 Oct 2007 14:15:02 -0400 From: IESG Secretary Reply-To: iesg@ietf.org To: ietf-announce@ietf.org A new IETF working group has been proposed in the Operations and Management Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by October 29. +++ Performance Metrics at Other Layers (pmol) ============================================== Current Status: Proposed Working Group WG Chairs: TBD Operations and Management Area: Dan Romascanu Ronald Bonica Description: The successful implementation and operation of IP based applications often depends on some underlying performance measurement infrastructure that helps service operators or network managers to recognize when performance is unsatisfactory and identify problems affecting service quality. Standardized performance metrics add the desirable features of consistent implementation, interpretation, no comparison. The IETF has two Working Groups dedicated to the development of performance metrics however each has strict limitations in their charters: - The Benchmarking Methodology WG has addressed a range of networking technologies and protocols in their long history (such as IEEE 802.3, ATM, Frame Relay, and Routing Protocols), but the charter strictly limits their Performance characterizations to the laboratory environment. - The IP Performance Metrics WG has the mandate to develop metrics applicable to the performance of Internet data delivery, but it is specifically prohibited from developing metrics that characterize traffic (such as a VoIP stream). The IETF also has current and completed activities related to the reporting of application performance metrics (e.g. RAQMON and RTCP XR) and is also actively involved in the development of reliable transport protocols which would affect the relationship between IP performance and application performance. Thus there is a gap in the currently chartered coverage of IETF WGs: development of performance metrics for IP-based protocols and applications that operate over UDP, TCP, SCTP, DCCP, Forward Error Correction (FEC) and other robust transport protocols, and that can be used to characterize traffic on live networks. The working group will focus on the completion of two RFCs: 1. A PMOL framework and guidelines memo that will describe the necessary elements of performance metrics of protocols and applications transported over IETF-specified protocols (such as the formal definition, purpose, and units of measure) and the various types of metrics that characterize traffic on live networks (such as metrics derived from other metrics, possibly on lower layers). The framework will also address the need to specify the intended audience and the motivation for the performance metrics. There will also be guidelines for a performance metric development process that includes entry criteria for new proposals (how a proposal might be evaluated for possible endorsement by a protocol development working group), and how an successful proposal will be developed by PMOL WG in cooperation with a protocol development WG. 2. A proof-of-concept RFC defining performance metrics for SIP, based on draft-malas-performance-metrics. This memo would serve as an example of the framework and the PMOL development process in the IETF. Discussion of new work proposals is strongly discouraged under the initial charter of the PMOL WG, except to advise a protocol development WG when they are evaluating a new work proposal for related performance metrics. The PMOL WG will also be guided by a document describing how memos defining performance metrics are intended to advance along the IETF Standards track (draft-bradner-metricstest). PMOL WG will take advantage of expertise and seek to avoid overlap with other standards development organizations, such as ETSI STQ, ITU-T SG 12, ATIS IIF, ATIS PRQC, and others. Milestones June 08 SIP Performance Metrics Draft to IESG Review for consideration as Proposed Standard Sept 08 PMOL Framework and Guidelines Draft to IESG Review for consideration as BCP _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 16:33:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imb9c-0004HI-3g; Mon, 29 Oct 2007 16:24:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imb9Z-0004GW-P0; Mon, 29 Oct 2007 16:24:05 -0400 Received: from dhcp-18-188-10-61.dyn.mit.edu ([18.188.10.61] helo=carter-zimmerman.suchdamage.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imb9X-0004nA-1T; Mon, 29 Oct 2007 16:24:03 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0674B4A45; Mon, 29 Oct 2007 16:24:02 -0400 (EDT) From: Sam Hartman To: Leslie Daigle References: <47263CC1.8000104@thinkingcat.com> Date: Mon, 29 Oct 2007 16:24:02 -0400 In-Reply-To: <47263CC1.8000104@thinkingcat.com> (Leslie Daigle's message of "Mon, 29 Oct 2007 16:04:17 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: IESG , ietf@ietf.org, pmol@ietf.org Subject: Re: A question about [Fwd: WG Review: Performance Metrics at Other Layers (pmol)] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>>>> "Leslie" == Leslie Daigle writes: I doubt I'll use the output in security protocols. Leslie> Leslie. Leslie> -------- Original Message -------- Subject: WG Review: Leslie> Performance Metrics at Other Layers (pmol) Date: Mon, 22 Leslie> Oct 2007 14:15:02 -0400 From: IESG Secretary Leslie> Reply-To: iesg@ietf.org To: Leslie> ietf-announce@ietf.org Leslie> A new IETF working group has been proposed in the Leslie> Operations and Management Area. The IESG has not made any Leslie> determination as yet. The following draft charter was Leslie> submitted, and is provided for informational purposes Leslie> only. Please send your comments to the IESG mailing list Leslie> (iesg@ietf.org) by October 29. Leslie> +++ Leslie> Performance Metrics at Other Layers (pmol) Leslie> ============================================== Leslie> Current Status: Proposed Working Group Leslie> WG Chairs: TBD Leslie> Operations and Management Area: Dan Romascanu Leslie> Ronald Bonica Leslie> Description: Leslie> The successful implementation and operation of IP based Leslie> applications often depends on some underlying performance Leslie> measurement infrastructure that helps service operators or Leslie> network managers to recognize when performance is Leslie> unsatisfactory and identify problems affecting service Leslie> quality. Standardized performance metrics add the Leslie> desirable features of consistent implementation, Leslie> interpretation, no comparison. Leslie> The IETF has two Working Groups dedicated to the Leslie> development of performance metrics however each has strict Leslie> limitations in their charters: Leslie> - The Benchmarking Methodology WG has addressed a range of Leslie> networking technologies and protocols in their long Leslie> history (such as IEEE 802.3, ATM, Frame Relay, and Routing Leslie> Protocols), but the charter strictly limits their Leslie> Performance characterizations to the laboratory Leslie> environment. Leslie> - The IP Performance Metrics WG has the mandate to develop Leslie> metrics applicable to the performance of Internet data Leslie> delivery, but it is specifically prohibited from Leslie> developing metrics that characterize traffic (such as a Leslie> VoIP stream). Leslie> The IETF also has current and completed activities related Leslie> to the reporting of application performance metrics Leslie> (e.g. RAQMON and RTCP XR) and is also actively involved in Leslie> the development of reliable transport protocols which Leslie> would affect the relationship between IP performance and Leslie> application performance. Leslie> Thus there is a gap in the currently chartered coverage of Leslie> IETF WGs: development of performance metrics for IP-based Leslie> protocols and applications that operate over UDP, TCP, Leslie> SCTP, DCCP, Forward Error Correction (FEC) and other Leslie> robust transport protocols, and that can be used to Leslie> characterize traffic on live networks. Leslie> The working group will focus on the completion of two Leslie> RFCs: Leslie> 1. A PMOL framework and guidelines memo that will describe Leslie> the necessary elements of performance metrics of protocols Leslie> and applications transported over IETF-specified protocols Leslie> (such as the formal definition, purpose, and units of Leslie> measure) and the various types of metrics that Leslie> characterize traffic on live networks (such as metrics Leslie> derived from other metrics, possibly on lower layers). The Leslie> framework will also address the need to specify the Leslie> intended audience and the motivation for the performance Leslie> metrics. There will also be guidelines for a performance Leslie> metric development process that includes entry criteria Leslie> for new proposals (how a proposal might be evaluated for Leslie> possible endorsement by a protocol development working Leslie> group), and how an successful proposal will be developed Leslie> by PMOL WG in cooperation with a protocol development WG. Leslie> 2. A proof-of-concept RFC defining performance metrics for Leslie> SIP, based on draft-malas-performance-metrics. This memo Leslie> would serve as an example of the framework and the PMOL Leslie> development process in the IETF. Leslie> Discussion of new work proposals is strongly discouraged Leslie> under the initial charter of the PMOL WG, except to advise Leslie> a protocol development WG when they are evaluating a new Leslie> work proposal for related performance metrics. Leslie> The PMOL WG will also be guided by a document describing Leslie> how memos defining performance metrics are intended to Leslie> advance along the IETF Standards track Leslie> (draft-bradner-metricstest). Leslie> PMOL WG will take advantage of expertise and seek to avoid Leslie> overlap with other standards development organizations, Leslie> such as ETSI STQ, ITU-T SG 12, ATIS IIF, ATIS PRQC, and Leslie> others. Leslie> Milestones Leslie> June 08 SIP Performance Metrics Draft to IESG Review for Leslie> consideration as Proposed Standard Leslie> Sept 08 PMOL Framework and Guidelines Draft to IESG Review Leslie> for consideration as BCP Leslie> _______________________________________________ Leslie> IETF-Announce mailing list IETF-Announce@ietf.org Leslie> https://www1.ietf.org/mailman/listinfo/ietf-announce Leslie> -- Leslie> ------------------------------------------------------------------- Leslie> "Reality: Yours to discover." -- ThinkingCat Leslie Leslie> Daigle leslie@thinkingcat.com Leslie> ------------------------------------------------------------------- _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 16:33:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImbCg-0004rF-3D; Mon, 29 Oct 2007 16:27:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImbCe-0004pB-0v for ietf@ietf.org; Mon, 29 Oct 2007 16:27:16 -0400 Received: from rv-out-0910.google.com ([209.85.198.189]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImbCd-0004yr-Ck for ietf@ietf.org; Mon, 29 Oct 2007 16:27:15 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1504134rvb for ; Mon, 29 Oct 2007 13:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=sF57QGDbbOgiw2tGvV1lhuu4UyFWeUbwKdNKi6p8niM=; b=at0xpHwjSDRolB60M2JSCA3AwZVLifoHvzU387tFZ/y4eIYqEXt88Pg7ljG0LS7IbLC8YrJeC0t/6Mg6KJgdGGQyGCCJKlUmnYKbrCgcd/ltbdHiu9t+fEpqwv1fxaeu1xXD5nn56lbSJLBgXvOFmuwUG8rO+fy4mwslo/hxQ6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ortrGwwNbGlkDlq8masBBvNdtOuiASj2cVnZMkGBL8JU8kRvhRDeQ5OZyCSaeceQVawCFKxK00LLRGUlYat0MFgG2hbUC9bQaSSDCyNzOZ1ZcDHbsd2HQgTFh9TfFpPFy085QKYY+qcRRiZbFzJ94tFhTdtyUwGiVCnrLzRJbE8= Received: by 10.140.147.5 with SMTP id u5mr2995911rvd.1193689632697; Mon, 29 Oct 2007 13:27:12 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id b24sm13297318rvf.2007.10.29.13.27.10 (version=SSLv3 cipher=RC4-MD5); Mon, 29 Oct 2007 13:27:11 -0700 (PDT) Message-ID: <4726421D.80908@gmail.com> Date: Tue, 30 Oct 2007 09:27:09 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Henning Schulzrinne References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ietf@ietf.org Subject: Re: Oppose draft-carpenter-ipr-patent-frswds-00 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Could we discuss this over on the IPR WG list, since the draft responds to a specific request from the WG Chair? Brian On 2007-10-30 08:44, Henning Schulzrinne wrote: > I admit to finding the discussion about Draft standards a bit > theoretical, given how few RFCs ever make it there. As a rough estimate, > > http://www.rfc-editor.org/rfcxx00.html#Draft > > shows a rate of 20 out of a 1000. > > On Oct 29, 2007, at 3:20 PM, James M. Polk wrote: > >> http://www.ietf.org/internet-drafts/draft-carpenter-ipr-patent-frswds-00.txt >> >> offers this text as a modification to RFC 2026: >> >> A specification from which at least two independent and interoperable >> implementations from different code bases have been developed, of >> which at least one is available as free software, and for which >> sufficient successful operational experience has been obtained, >> may be elevated to the "Draft Standard" level. >> >> I oppose this text in any IETF document because it is counter to >> vendor implementations (*any* vendor implementations) to achieve Draft >> Standard status of a document, and that's bad for the IETF. >> >> For example, take two vendors: Vendor-A and Vendor-B. >> >> One of the vendor's has legitimate IPR claims on a PS RFC, the other >> either has a license on that IPR from the inventing vendor, or has >> implemented it under the IPR claim's royalty-free IPR statement (just >> as some IPR has in its claim into the IETF). >> >> Some PS RFCs are either very little used or very complicated, meaning >> they aren't very popular (to the Open Source community) or cost to >> much (time/money) to develop. So unless someone decides to do the >> work anyway (which doesn't make sense to require) - the suggested text >> above prevents both Vendor-A's and Vendor-B's implementations from >> being considered for elevation of this PS RFC to DS RFC *because* they >> (for some crazy reason) want to charge money for the products where >> this implementation can be utilized. >> >> BTW - isn't charging money for products how vendor's stay in business? >> >> The IETF preventing vendors from making money in order for the IETF to >> consider progressing a PS RFC to DS RFC is completely counterintuitive >> and will reduce vendor participation in the IETF. As much as some >> might applaud that result, it will mean either the demise of the IETF >> (without sponsors and vendor participants attending meetings to pay >> the bills), or that everything is just fine as a PS - which makes the >> suggested text above completely useless. >> >> James >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www1.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 16:33:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imb9c-0004HI-3g; Mon, 29 Oct 2007 16:24:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imb9Z-0004GW-P0; Mon, 29 Oct 2007 16:24:05 -0400 Received: from dhcp-18-188-10-61.dyn.mit.edu ([18.188.10.61] helo=carter-zimmerman.suchdamage.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imb9X-0004nA-1T; Mon, 29 Oct 2007 16:24:03 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0674B4A45; Mon, 29 Oct 2007 16:24:02 -0400 (EDT) From: Sam Hartman To: Leslie Daigle References: <47263CC1.8000104@thinkingcat.com> Date: Mon, 29 Oct 2007 16:24:02 -0400 In-Reply-To: <47263CC1.8000104@thinkingcat.com> (Leslie Daigle's message of "Mon, 29 Oct 2007 16:04:17 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: IESG , ietf@ietf.org, pmol@ietf.org Subject: Re: A question about [Fwd: WG Review: Performance Metrics at Other Layers (pmol)] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>>>> "Leslie" == Leslie Daigle writes: I doubt I'll use the output in security protocols. Leslie> Leslie. Leslie> -------- Original Message -------- Subject: WG Review: Leslie> Performance Metrics at Other Layers (pmol) Date: Mon, 22 Leslie> Oct 2007 14:15:02 -0400 From: IESG Secretary Leslie> Reply-To: iesg@ietf.org To: Leslie> ietf-announce@ietf.org Leslie> A new IETF working group has been proposed in the Leslie> Operations and Management Area. The IESG has not made any Leslie> determination as yet. The following draft charter was Leslie> submitted, and is provided for informational purposes Leslie> only. Please send your comments to the IESG mailing list Leslie> (iesg@ietf.org) by October 29. Leslie> +++ Leslie> Performance Metrics at Other Layers (pmol) Leslie> ============================================== Leslie> Current Status: Proposed Working Group Leslie> WG Chairs: TBD Leslie> Operations and Management Area: Dan Romascanu Leslie> Ronald Bonica Leslie> Description: Leslie> The successful implementation and operation of IP based Leslie> applications often depends on some underlying performance Leslie> measurement infrastructure that helps service operators or Leslie> network managers to recognize when performance is Leslie> unsatisfactory and identify problems affecting service Leslie> quality. Standardized performance metrics add the Leslie> desirable features of consistent implementation, Leslie> interpretation, no comparison. Leslie> The IETF has two Working Groups dedicated to the Leslie> development of performance metrics however each has strict Leslie> limitations in their charters: Leslie> - The Benchmarking Methodology WG has addressed a range of Leslie> networking technologies and protocols in their long Leslie> history (such as IEEE 802.3, ATM, Frame Relay, and Routing Leslie> Protocols), but the charter strictly limits their Leslie> Performance characterizations to the laboratory Leslie> environment. Leslie> - The IP Performance Metrics WG has the mandate to develop Leslie> metrics applicable to the performance of Internet data Leslie> delivery, but it is specifically prohibited from Leslie> developing metrics that characterize traffic (such as a Leslie> VoIP stream). Leslie> The IETF also has current and completed activities related Leslie> to the reporting of application performance metrics Leslie> (e.g. RAQMON and RTCP XR) and is also actively involved in Leslie> the development of reliable transport protocols which Leslie> would affect the relationship between IP performance and Leslie> application performance. Leslie> Thus there is a gap in the currently chartered coverage of Leslie> IETF WGs: development of performance metrics for IP-based Leslie> protocols and applications that operate over UDP, TCP, Leslie> SCTP, DCCP, Forward Error Correction (FEC) and other Leslie> robust transport protocols, and that can be used to Leslie> characterize traffic on live networks. Leslie> The working group will focus on the completion of two Leslie> RFCs: Leslie> 1. A PMOL framework and guidelines memo that will describe Leslie> the necessary elements of performance metrics of protocols Leslie> and applications transported over IETF-specified protocols Leslie> (such as the formal definition, purpose, and units of Leslie> measure) and the various types of metrics that Leslie> characterize traffic on live networks (such as metrics Leslie> derived from other metrics, possibly on lower layers). The Leslie> framework will also address the need to specify the Leslie> intended audience and the motivation for the performance Leslie> metrics. There will also be guidelines for a performance Leslie> metric development process that includes entry criteria Leslie> for new proposals (how a proposal might be evaluated for Leslie> possible endorsement by a protocol development working Leslie> group), and how an successful proposal will be developed Leslie> by PMOL WG in cooperation with a protocol development WG. Leslie> 2. A proof-of-concept RFC defining performance metrics for Leslie> SIP, based on draft-malas-performance-metrics. This memo Leslie> would serve as an example of the framework and the PMOL Leslie> development process in the IETF. Leslie> Discussion of new work proposals is strongly discouraged Leslie> under the initial charter of the PMOL WG, except to advise Leslie> a protocol development WG when they are evaluating a new Leslie> work proposal for related performance metrics. Leslie> The PMOL WG will also be guided by a document describing Leslie> how memos defining performance metrics are intended to Leslie> advance along the IETF Standards track Leslie> (draft-bradner-metricstest). Leslie> PMOL WG will take advantage of expertise and seek to avoid Leslie> overlap with other standards development organizations, Leslie> such as ETSI STQ, ITU-T SG 12, ATIS IIF, ATIS PRQC, and Leslie> others. Leslie> Milestones Leslie> June 08 SIP Performance Metrics Draft to IESG Review for Leslie> consideration as Proposed Standard Leslie> Sept 08 PMOL Framework and Guidelines Draft to IESG Review Leslie> for consideration as BCP Leslie> _______________________________________________ Leslie> IETF-Announce mailing list IETF-Announce@ietf.org Leslie> https://www1.ietf.org/mailman/listinfo/ietf-announce Leslie> -- Leslie> ------------------------------------------------------------------- Leslie> "Reality: Yours to discover." -- ThinkingCat Leslie Leslie> Daigle leslie@thinkingcat.com Leslie> ------------------------------------------------------------------- _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 16:33:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImbCg-0004rF-3D; Mon, 29 Oct 2007 16:27:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImbCe-0004pB-0v for ietf@ietf.org; Mon, 29 Oct 2007 16:27:16 -0400 Received: from rv-out-0910.google.com ([209.85.198.189]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImbCd-0004yr-Ck for ietf@ietf.org; Mon, 29 Oct 2007 16:27:15 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1504134rvb for ; Mon, 29 Oct 2007 13:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=sF57QGDbbOgiw2tGvV1lhuu4UyFWeUbwKdNKi6p8niM=; b=at0xpHwjSDRolB60M2JSCA3AwZVLifoHvzU387tFZ/y4eIYqEXt88Pg7ljG0LS7IbLC8YrJeC0t/6Mg6KJgdGGQyGCCJKlUmnYKbrCgcd/ltbdHiu9t+fEpqwv1fxaeu1xXD5nn56lbSJLBgXvOFmuwUG8rO+fy4mwslo/hxQ6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ortrGwwNbGlkDlq8masBBvNdtOuiASj2cVnZMkGBL8JU8kRvhRDeQ5OZyCSaeceQVawCFKxK00LLRGUlYat0MFgG2hbUC9bQaSSDCyNzOZ1ZcDHbsd2HQgTFh9TfFpPFy085QKYY+qcRRiZbFzJ94tFhTdtyUwGiVCnrLzRJbE8= Received: by 10.140.147.5 with SMTP id u5mr2995911rvd.1193689632697; Mon, 29 Oct 2007 13:27:12 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id b24sm13297318rvf.2007.10.29.13.27.10 (version=SSLv3 cipher=RC4-MD5); Mon, 29 Oct 2007 13:27:11 -0700 (PDT) Message-ID: <4726421D.80908@gmail.com> Date: Tue, 30 Oct 2007 09:27:09 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Henning Schulzrinne References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ietf@ietf.org Subject: Re: Oppose draft-carpenter-ipr-patent-frswds-00 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Could we discuss this over on the IPR WG list, since the draft responds to a specific request from the WG Chair? Brian On 2007-10-30 08:44, Henning Schulzrinne wrote: > I admit to finding the discussion about Draft standards a bit > theoretical, given how few RFCs ever make it there. As a rough estimate, > > http://www.rfc-editor.org/rfcxx00.html#Draft > > shows a rate of 20 out of a 1000. > > On Oct 29, 2007, at 3:20 PM, James M. Polk wrote: > >> http://www.ietf.org/internet-drafts/draft-carpenter-ipr-patent-frswds-00.txt >> >> offers this text as a modification to RFC 2026: >> >> A specification from which at least two independent and interoperable >> implementations from different code bases have been developed, of >> which at least one is available as free software, and for which >> sufficient successful operational experience has been obtained, >> may be elevated to the "Draft Standard" level. >> >> I oppose this text in any IETF document because it is counter to >> vendor implementations (*any* vendor implementations) to achieve Draft >> Standard status of a document, and that's bad for the IETF. >> >> For example, take two vendors: Vendor-A and Vendor-B. >> >> One of the vendor's has legitimate IPR claims on a PS RFC, the other >> either has a license on that IPR from the inventing vendor, or has >> implemented it under the IPR claim's royalty-free IPR statement (just >> as some IPR has in its claim into the IETF). >> >> Some PS RFCs are either very little used or very complicated, meaning >> they aren't very popular (to the Open Source community) or cost to >> much (time/money) to develop. So unless someone decides to do the >> work anyway (which doesn't make sense to require) - the suggested text >> above prevents both Vendor-A's and Vendor-B's implementations from >> being considered for elevation of this PS RFC to DS RFC *because* they >> (for some crazy reason) want to charge money for the products where >> this implementation can be utilized. >> >> BTW - isn't charging money for products how vendor's stay in business? >> >> The IETF preventing vendors from making money in order for the IETF to >> consider progressing a PS RFC to DS RFC is completely counterintuitive >> and will reduce vendor participation in the IETF. As much as some >> might applaud that result, it will mean either the demise of the IETF >> (without sponsors and vendor participants attending meetings to pay >> the bills), or that everything is just fine as a PS - which makes the >> suggested text above completely useless. >> >> James >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www1.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 17:35:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imc5h-0003jW-RZ; Mon, 29 Oct 2007 17:24:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imc5f-0003hr-QX for ietf@ietf.org; Mon, 29 Oct 2007 17:24:08 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imc5f-0000P0-48 for ietf@ietf.org; Mon, 29 Oct 2007 17:24:07 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9TLNesb010942; Mon, 29 Oct 2007 14:23:40 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9TLNceO014264; Mon, 29 Oct 2007 14:23:39 -0700 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 Content-Transfer-Encoding: 7bit Date: Mon, 29 Oct 2007 14:23:28 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Oppose draft-carpenter-ipr-patent-frswds-00 Thread-Index: AcgaYZ15YdBEz9EGT9OMmgW0c6+omAAD39Tg References: From: "Eric Burger" To: "James M. Polk" x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ietf@ietf.org Subject: RE: Oppose draft-carpenter-ipr-patent-frswds-00 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Although this may not be a popular opinion, I have to agree with James here. Our goal is to have the widest acceptance of a given protocol output from the IETF. One way is to have lots of open source implementations. One interesting side effect of the existence of an open source implementation of a protocol is monoculture. We ran into a problem in ifax year ago when it turned out that all eight "independent" implementations all relied on the same library, thus rendering the "independent" implementations label difficult, to say the least. Why were there no independent implementations? Because in this case, the open source implementation was pretty good, and it was not worth investing in a proprietary implementation. The result here has a really bad side effect for the IETF: if there is a good open source, free implementation, there will be no second implementation, resulting in it being impossible for the standard to progress. We are the IETF and not the Open Source Consortium. I would offer we focus on producing the best and most spreadable protocols. That hints at, but does not require, open source. If one wants open source, participate in one or more of the most excellent open source communities and forums. -- Eric Burger Member of the Board of the SIP Forum, which has a charter to support Open Source, as well as commercial, implementations -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Monday, October 29, 2007 3:20 PM To: ietf@ietf.org Subject: Oppose draft-carpenter-ipr-patent-frswds-00 http://www.ietf.org/internet-drafts/draft-carpenter-ipr-patent-frswds-00 .txt offers this text as a modification to RFC 2026: A specification from which at least two independent and interoperable implementations from different code bases have been developed, of which at least one is available as free software, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. I oppose this text in any IETF document because it is counter to vendor implementations (*any* vendor implementations) to achieve Draft Standard status of a document, and that's bad for the IETF. For example, take two vendors: Vendor-A and Vendor-B. One of the vendor's has legitimate IPR claims on a PS RFC, the other either has a license on that IPR from the inventing vendor, or has implemented it under the IPR claim's royalty-free IPR statement (just as some IPR has in its claim into the IETF). Some PS RFCs are either very little used or very complicated, meaning they aren't very popular (to the Open Source community) or cost to much (time/money) to develop. So unless someone decides to do the work anyway (which doesn't make sense to require) - the suggested text above prevents both Vendor-A's and Vendor-B's implementations from being considered for elevation of this PS RFC to DS RFC *because* they (for some crazy reason) want to charge money for the products where this implementation can be utilized. BTW - isn't charging money for products how vendor's stay in business? The IETF preventing vendors from making money in order for the IETF to consider progressing a PS RFC to DS RFC is completely counterintuitive and will reduce vendor participation in the IETF. As much as some might applaud that result, it will mean either the demise of the IETF (without sponsors and vendor participants attending meetings to pay the bills), or that everything is just fine as a PS - which makes the suggested text above completely useless. James _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 17:35:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imbyf-0003Rz-CR; Mon, 29 Oct 2007 17:16:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imbyd-0002yZ-4O for ietf@ietf.org; Mon, 29 Oct 2007 17:16:51 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imbyc-0008UE-GS for ietf@ietf.org; Mon, 29 Oct 2007 17:16:51 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9TLGYjZ029547; Mon, 29 Oct 2007 14:16:34 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9TLGXfI003330; Mon, 29 Oct 2007 14:16:33 -0700 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 Content-Transfer-Encoding: 7bit Date: Mon, 29 Oct 2007 14:16:24 -0700 Message-ID: In-Reply-To: <47263C98.6080703@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Patents can be for good, not only evil Thread-Index: AcgaZ5Kx19fcSEWLSJa0rKtQKea0vQAB5DNg References: <877iljv6ed.fsf@mocca.josefsson.org><042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA><2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com><471A5668.8060505@gmail.com><048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA><20071022195723.4D9A22202DA@quill.bollow.ch><20071023105651.8D9AC2202DA@quill.bollow.ch><87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> <87fy00vn1l.fsf@mocca.josefsson.org> <471FB60B.3070304@gmail.com> <20071024214601.28e866ce@cs.columbia.edu> <00d801c81689$f64c5f30$6401a8c0@LROSENTOSHIBA> <4720FCFA.7080009@cs.utk.edu> <020d01c81a62$8a7d6510$6401a8c0@LROSENTOSHIBA> <47263C98! .6080703@ cs.utk.edu> From: "Eric Burger" To: "Keith Moore" , x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ietf@ietf.org Subject: Patents can be for good, not only evil X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I would offer that patents are NOT categorically evil. Phil Zimmerman has applied for patents in ZRTP, specifically to ensure that all implementations fully conform with the specification. Cost to license for a conformant specification? $0. Cost to not really provide privacy but claim to be implementing ZRTP? Costly! I specifically applied for patents underlying the technology behind RFC 4722/RFC 5022 and RFC 4730 specifically to prevent third parties, who are not part of the IETF process, from extracting royalties from someone who implements MSCML or KPML. Cost to license? $0. Cost to sue someone who infringes said third-party's IPR? That depends, but at least we raised the cost of shutting down an IETF standard. Remember, just because *you* do not have IPR in an IETF standard does not mean someone *else* has IPR in the standard. If that someone else does not participate in the IETF or, for that matter, happen to not participate in the work group or, in reality, are not editors of a document, they can fully apply their IPR against the standard once it issues. I like to have a little inoculation against that situation in the stuff I submit. -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Monday, October 29, 2007 4:04 PM To: lrosen@rosenlaw.com Cc: ietf@ietf.org Subject: Re: When is using patented technology appropriate? Lawrence Rosen wrote: > Keith Moore wrote: > >> For several reasons, it is difficult to imagine an IETF-wide >> procedure that allows the existence of a patent to trump other >> considerations of protocol feasibility and deployability: >> > > Who suggested otherwise? It is not the existence of the patent that > matters, but its unavailability under license terms that allow > implementation in > *any* software. > _and_ its validity, _and_ its applicability, both of which can be subjective and difficult to determine conclusively without long delays and excessive expense. so we have to make judgments. and by "we" I mean individuals participating in IETF, not IETF itself. > The more feasible and deployable the protocol, the more important will > be FOSS implementations. > only relative to other protocols in the same space. granted that patents are the bane of any open standards-making organization, because patents do exactly the opposite of what open standards do. at the same time, we can't let FUD about patents become a denial of service attack to IETF efforts. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 18:03:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImcUU-0006jd-0U; Mon, 29 Oct 2007 17:49:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImcUS-0006Xr-7s for ietf@ietf.org; Mon, 29 Oct 2007 17:49:44 -0400 Received: from yxa.extundo.com ([83.241.177.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImcUJ-0001z4-OY for ietf@ietf.org; Mon, 29 Oct 2007 17:49:36 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l9TLmuXk012102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Oct 2007 22:49:01 +0100 From: Simon Josefsson To: "Eric Burger" References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071029:eburger@bea.com::R90guiMB5eocMTpN:gdx X-Hashcash: 1:22:071029:ietf@ietf.org::TmFKwsYTcsvTUIHG:0U3B X-Hashcash: 1:22:071029:jmpolk@cisco.com::0PL/Ar6bNHyTg7xN:7wes Date: Mon, 29 Oct 2007 22:48:56 +0100 In-Reply-To: (Eric Burger's message of "Mon, 29 Oct 2007 14:23:28 -0700") Message-ID: <871wbdvbg7.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ietf@ietf.org Subject: Re: Oppose draft-carpenter-ipr-patent-frswds-00 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org "Eric Burger" writes: > One interesting side effect of the existence of an open source > implementation of a protocol is monoculture. We ran into a problem in > ifax year ago when it turned out that all eight "independent" > implementations all relied on the same library, thus rendering the > "independent" implementations label difficult, to say the least. Why > were there no independent implementations? Because in this case, the > open source implementation was pretty good, and it was not worth > investing in a proprietary implementation. The result here has a really > bad side effect for the IETF: if there is a good open source, free > implementation, there will be no second implementation, resulting in it > being impossible for the standard to progress. But that is how it is supposed to work! If there is only one implementation, a standard is not mature enough to move to DS. You need to have at least two, preferably several more, completely independent implementations in order to quality-test a standard. /Simon _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 19:22:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imddr-0008HR-Sg; Mon, 29 Oct 2007 19:03:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imddn-0008Gj-AY for ietf@ietf.org; Mon, 29 Oct 2007 19:03:27 -0400 Received: from mail26a.sbc-webhosting.com ([216.173.237.164]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Imddk-0006PB-H0 for ietf@ietf.org; Mon, 29 Oct 2007 19:03:25 -0400 Received: from mx51.stngva01.us.mxservers.net (204.202.242.110) by mail26a.sbc-webhosting.com (RS ver 1.0.95vs) with SMTP id 3-0557959003 for ; Mon, 29 Oct 2007 19:03:24 -0400 (EDT) Received: from mmm2630.sbc-webhosting.com [216.173.237.89] (EHLO mmm2630.sbc-webhosting.com) by mx51.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id 18566274.5079.018.mx51.stngva01.us.mxservers.net; Mon, 29 Oct 2007 18:58:09 -0400 (EDT) Received: (qmail 24712 invoked from network); 29 Oct 2007 23:03:21 -0000 Received: from unknown (HELO LROSENTOSHIBA) (lrosen@208.106.45.202) by with ESMTPA; 29 Oct 2007 23:03:21 -0000 From: "Lawrence Rosen" To: References: <877iljv6ed.fsf@mocca.josefsson.org><042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA><2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com><471A5668.8060505@gmail.com><048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA><20071022195723.4D9A22202DA@quill.bollow.ch><20071023105651.8D9AC2202DA@quill.bollow.ch><87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> <87fy00vn1l.fsf@mocca.josefsson.org> <471FB60B.3070304@gmail.com> <20071024214601.28e866ce@cs.columbia.edu> <00d801c81689$f64c5f30$6401a8c0@LROSENTOSHIBA> <4720FCFA.7080009@cs.utk.edu> <020d01c81a62$8a7d6510$6401a8c0@LROSENTOSHIBA> <47263C98! .6080703@cs.utk.edu > Date: Mon, 29 Oct 2007 16:02:10 -0700 Organization: Rosenlaw & Einschlag Message-ID: <022d01c81a7f$bd063ad0$6401a8c0@LROSENTOSHIBA> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgaZ5Kx19fcSEWLSJa0rKtQKea0vQAB5DNgAAPBL5A= X-Spam: [F=0.0043103448; heur=0.500(-19500); stat=0.010; spamtraq-heur=0.300(2007101727)] X-MAIL-FROM: X-SOURCE-IP: [216.173.237.89] X-SF-Loop: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Subject: RE: Patents can be for good, not only evil X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lrosen@rosenlaw.com List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Eric Burger wrote: > I specifically applied for patents underlying the technology behind RFC > 4722/RFC 5022 and RFC 4730 specifically to prevent third parties, who > are not part of the IETF process, from extracting royalties from someone > who implements MSCML or KPML. That was a waste of your time and money. Publication of those inventions by you, at zero cost to you and others, would have been sufficient to prevent someone else from trying to patent them. Next time, get good advice from a patent lawyer on how to achieve your goals without paying for a patent. > Remember, just because *you* do not have IPR in an IETF standard does > not mean someone *else* has IPR in the standard. If that someone else > does not participate in the IETF or, for that matter, happen to not > participate in the work group or, in reality, are not editors of a > document, they can fully apply their IPR against the standard once it > issues. Right! And that's why every one of the FOSS-compatible patent grants to IETF, W3C or OASIS includes defensive termination provisions. We also want to protect standards against patent threats by third parties, and defensive provisions are consistent with FOSS licenses. For those here who keep asking for protection against patents in standards, there is no more effective technique than through a revised IPR policy that prohibits patent-encumbered standards from gaining the IETF brand in the first place. /Larry > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com] > Sent: Monday, October 29, 2007 2:16 PM > To: Keith Moore; lrosen@rosenlaw.com > Cc: ietf@ietf.org > Subject: Patents can be for good, not only evil > > I would offer that patents are NOT categorically evil. > > Phil Zimmerman has applied for patents in ZRTP, specifically to ensure > that all implementations fully conform with the specification. Cost to > license for a conformant specification? $0. Cost to not really provide > privacy but claim to be implementing ZRTP? Costly! > > I specifically applied for patents underlying the technology behind RFC > 4722/RFC 5022 and RFC 4730 specifically to prevent third parties, who > are not part of the IETF process, from extracting royalties from someone > who implements MSCML or KPML. Cost to license? $0. Cost to sue > someone who infringes said third-party's IPR? That depends, but at > least we raised the cost of shutting down an IETF standard. > > Remember, just because *you* do not have IPR in an IETF standard does > not mean someone *else* has IPR in the standard. If that someone else > does not participate in the IETF or, for that matter, happen to not > participate in the work group or, in reality, are not editors of a > document, they can fully apply their IPR against the standard once it > issues. > > I like to have a little inoculation against that situation in the stuff > I submit. > > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Monday, October 29, 2007 4:04 PM > To: lrosen@rosenlaw.com > Cc: ietf@ietf.org > Subject: Re: When is using patented technology appropriate? > > Lawrence Rosen wrote: > > Keith Moore wrote: > > > >> For several reasons, it is difficult to imagine an IETF-wide > >> procedure that allows the existence of a patent to trump other > >> considerations of protocol feasibility and deployability: > >> > > > > Who suggested otherwise? It is not the existence of the patent that > > matters, but its unavailability under license terms that allow > > implementation in > > *any* software. > > > _and_ its validity, _and_ its applicability, both of which can be > subjective and difficult to determine conclusively without long delays > and excessive expense. so we have to make judgments. and by "we" I > mean individuals participating in IETF, not IETF itself. > > The more feasible and deployable the protocol, the more important will > > > be FOSS implementations. > > > only relative to other protocols in the same space. > > granted that patents are the bane of any open standards-making > organization, because patents do exactly the opposite of what open > standards do. at the same time, we can't let FUD about patents become a > denial of service attack to IETF efforts. > > Keith > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual > or entity named in this message. If you are not the intended recipient, > and have received this message in error, please immediately return this by > email and then delete it. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 19:22:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imdds-0008Hb-GC; Mon, 29 Oct 2007 19:03:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imddp-0008H9-CI for ietf@ietf.org; Mon, 29 Oct 2007 19:03:30 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imddo-0006Pf-V7 for ietf@ietf.org; Mon, 29 Oct 2007 19:03:29 -0400 X-IronPort-AV: E=Sophos;i="4.21,344,1188802800"; d="scan'208";a="28246691" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 29 Oct 2007 16:03:28 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9TN3S3J020087; Mon, 29 Oct 2007 16:03:28 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l9TN3QTg020619; Mon, 29 Oct 2007 23:03:26 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 16:03:25 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.17.26]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 16:03:25 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 29 Oct 2007 18:03:22 -0500 To: Simon Josefsson , "Eric Burger" From: "James M. Polk" In-Reply-To: <871wbdvbg7.fsf@mocca.josefsson.org> References: <871wbdvbg7.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 29 Oct 2007 23:03:25.0560 (UTC) FILETIME=[E9320F80:01C81A7F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1516; t=1193699008; x=1194563008; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20Oppose=20draft-carpenter-ipr-patent-frswds-00 |Sender:=20; bh=v6GlBtJV16DlLLtUNJtVyIqH1dDUabKfAZiT9wdLGQY=; b=HZ8HqURtNM7bR+umNzBOvhw5kPhaRbq36lgZvByX7xYc0dyhvWVxaeDeQAxZ5Ac4urh5uZfT 5sLD8Ffb1fN90FXnokyWP77+bA8QO66apcBN9HQSN7abSc8pFCwFTifmp/xTMFbswway/N3NN0 Qeny7d13+WeW15c3CneyHVgK4=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ietf@ietf.org Subject: Re: Oppose draft-carpenter-ipr-patent-frswds-00 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 04:48 PM 10/29/2007, Simon Josefsson wrote: >"Eric Burger" writes: > > > One interesting side effect of the existence of an open source > > implementation of a protocol is monoculture. We ran into a problem in > > ifax year ago when it turned out that all eight "independent" > > implementations all relied on the same library, thus rendering the > > "independent" implementations label difficult, to say the least. Why > > were there no independent implementations? Because in this case, the > > open source implementation was pretty good, and it was not worth > > investing in a proprietary implementation. The result here has a really > > bad side effect for the IETF: if there is a good open source, free > > implementation, there will be no second implementation, resulting in it > > being impossible for the standard to progress. > >But that is how it is supposed to work! If there is only one >implementation, a standard is not mature enough to move to DS. You need >to have at least two, preferably several more, completely independent >implementations in order to quality-test a standard. but why does one or both have to be open source? Why can't both be commercial? So few PSs become DSs, I believe this will almost certainly make progression from PS to DS slower. Is that what we want? I admit now all PSs have IPR attached, but this is almost certainly intended to kill any IPR from achieving DS. Is that what is intended here? >/Simon _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 20:05:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImeNB-0006zX-9t; Mon, 29 Oct 2007 19:50:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImeNA-0006zH-4Y for ietf@ietf.org; Mon, 29 Oct 2007 19:50:20 -0400 Received: from machshav.com ([198.180.150.44]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImeN9-0000m3-NN for ietf@ietf.org; Mon, 29 Oct 2007 19:50:20 -0400 Received: by machshav.com (Postfix, from userid 512) id BCDB44D2; Mon, 29 Oct 2007 23:49:13 +0000 (GMT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 64A1D179; Mon, 29 Oct 2007 23:49:13 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 3128F765F36; Mon, 29 Oct 2007 19:49:12 -0400 (EDT) Date: Mon, 29 Oct 2007 23:49:11 +0000 From: "Steven M. Bellovin" To: lrosen@rosenlaw.com Message-ID: <20071029234911.0f1e8d80@cs.columbia.edu> In-Reply-To: <022d01c81a7f$bd063ad0$6401a8c0@LROSENTOSHIBA> References: <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> <87fy00vn1l.fsf@mocca.josefsson.org> <471FB60B.3070304@gmail.com> <20071024214601.28e866ce@cs.columbia.edu> <00d801c81689$f64c5f30$6401a8c0@LROSENTOSHIBA> <4720FCFA.7080009@cs.utk.edu> <020d01c81a62$8a7d6510$6401a8c0@LROSENTOSHIBA> <47263C98! .6080703@cs.utk.edu> <022d01c81a7f$bd063ad0$6401a8c0@LROSENTOSHIBA> Organization: Columbia University X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.0; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ietf@ietf.org Subject: Re: Patents can be for good, not only evil X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Mon, 29 Oct 2007 16:02:10 -0700 "Lawrence Rosen" wrote: > Eric Burger wrote: > > I specifically applied for patents underlying the technology behind > > RFC 4722/RFC 5022 and RFC 4730 specifically to prevent third > > parties, who are not part of the IETF process, from extracting > > royalties from someone who implements MSCML or KPML. > > That was a waste of your time and money. Publication of those > inventions by you, at zero cost to you and others, would have been > sufficient to prevent someone else from trying to patent them. Next > time, get good advice from a patent lawyer on how to achieve your > goals without paying for a patent. > You're obviously right in theory on this point. I wonder whether you're right in practice. We've all seen far too many really bad patents issued, ones where prior art is legion. The (U.S.) patent office seems to do a far better job of searching its own databases than it does the technical literature. I know there are many philosophical reasons why many people oppose software patents. But for others, there are very practical reasons: there are too many bad patents issued. I think we can all agree that stopping bad patents is a worthwhile goal, even if for some it's just an intermediate goal. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 20:54:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imf8i-0005BT-SQ; Mon, 29 Oct 2007 20:39:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imf8h-0005BE-Hc for ietf@ietf.org; Mon, 29 Oct 2007 20:39:27 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Imf8g-0003cR-UJ for ietf@ietf.org; Mon, 29 Oct 2007 20:39:27 -0400 Received: (qmail invoked by alias); 30 Oct 2007 00:39:26 -0000 Received: from p3EE3C733.dip.t-dialin.net (EHLO peter-dambier.de) [62.227.199.51] by mail.gmx.net (mp034) with SMTP; 30 Oct 2007 01:39:26 +0100 X-Authenticated: #8956597 X-Provags-ID: V01U2FsdGVkX1964AwYtTx6YPVnqs2MCEAb38SQBncmBDII/HNErC ArY57s00pxWuLW Message-ID: <47267D38.8060302@peter-dambier.de> Date: Tue, 30 Oct 2007 01:39:20 +0100 From: Peter Dambier Organization: Peter and Karin Dambier User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040921 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf@ietf.org References: <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> <87fy00vn1l.fsf@mocca.josefsson.org> <471FB60B.3070304@gmail.com> <20071024214601.28e866ce@cs.columbia.edu> <00d801c81689$f64c5f30$6401a8c0@LROSENTOSHIBA> <4720FCFA.7080009@cs.utk.edu> <020d01c81a62$8a7d6510$6401a8c0@LROSENTOSHIBA> <47263C98! .6080703@cs.utk.edu> <022d01c81a7f$bd063ad0$6401a8c0@LROSENTOSHIBA> <20071029234911.0f1e8d80@cs.columbia.edu> In-Reply-To: <20071029234911.0f1e8d80@cs.columbia.edu> X-Enigmail-Version: 0.76.8.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: Re: Patents can be for good, not only evil X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: peter@peter-dambier.de List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org There are 2 people who own every right on computers http://en.wikipedia.org/wiki/Charles_Babbage and programming http://www.agnesscott.edu/Lriddle/women/love.htm All patents therafter are infringements of the work of these two people. Well even those two people built on the work of other people. Kind regards Peter and Karin Dambier Steven M. Bellovin wrote: > On Mon, 29 Oct 2007 16:02:10 -0700 > "Lawrence Rosen" wrote: > > >>Eric Burger wrote: >> >>>I specifically applied for patents underlying the technology behind >>>RFC 4722/RFC 5022 and RFC 4730 specifically to prevent third >>>parties, who are not part of the IETF process, from extracting >>>royalties from someone who implements MSCML or KPML. >> >>That was a waste of your time and money. Publication of those >>inventions by you, at zero cost to you and others, would have been >>sufficient to prevent someone else from trying to patent them. Next >>time, get good advice from a patent lawyer on how to achieve your >>goals without paying for a patent. >> > > > You're obviously right in theory on this point. I wonder whether > you're right in practice. We've all seen far too many really bad > patents issued, ones where prior art is legion. The (U.S.) patent > office seems to do a far better job of searching its own databases than > it does the technical literature. > > I know there are many philosophical reasons why many people oppose > software patents. But for others, there are very practical reasons: > there are too many bad patents issued. I think we can all agree that > stopping bad patents is a worthwhile goal, even if for some it's just > an intermediate goal. > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter@peter-dambier.de mail: peter@echnaton.arl.pirates http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ http://www.cesidianroot.com/ _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 21:03:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImfNh-0001Q6-2u; Mon, 29 Oct 2007 20:54:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImfNg-0001Oi-5Y for ietf@ietf.org; Mon, 29 Oct 2007 20:54:56 -0400 Received: from mail26a.sbc-webhosting.com ([216.173.237.164]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ImfNc-0004B7-Ik for ietf@ietf.org; Mon, 29 Oct 2007 20:54:53 -0400 Received: from mx06.stngva01.us.mxservers.net (204.202.242.35) by mail26a.sbc-webhosting.com (RS ver 1.0.95vs) with SMTP id 1-0232675691 for ; Mon, 29 Oct 2007 20:54:51 -0400 (EDT) Received: from mmm2630.sbc-webhosting.com [216.173.237.89] (EHLO mmm2630.sbc-webhosting.com) by mx06.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id ad086274.9745.401.mx06.stngva01.us.mxservers.net; Mon, 29 Oct 2007 20:54:50 -0400 (EDT) Received: (qmail 45190 invoked from network); 30 Oct 2007 00:54:48 -0000 Received: from unknown (HELO LROSENTOSHIBA) (lrosen@208.106.45.202) by with ESMTPA; 30 Oct 2007 00:54:48 -0000 From: "Lawrence Rosen" To: References: <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com><471A5668.8060505@gmail.com><048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA><20071022195723.4D9A22202DA@quill.bollow.ch><20071023105651.8D9AC2202DA@quill.bollow.ch><87abqa2i1z.fsf@mocca.josefsson.org><871wbm2cze.fsf@mocca.josefsson.org><87fy00vn1l.fsf@mocca.josefsson.org><471FB60B.3070304@gmail.com><20071024214601.28e866ce@cs.columbia.edu><00d801c81689$f64c5f30$6401a8c0@LROSENTOSHIBA><4720FCFA.7080009@cs.utk.edu><020d01c81a62$8a7d6510$6401a8c0@LROSENTOSHIBA><47263C98! .6080703@cs.utk.edu><022d01c81a7f$bd063ad0$6401a8c0@LROSENTOSHIBA> <20071029234911.0f1e8d80@cs.columbia.edu> Date: Mon, 29 Oct 2007 17:53:35 -0700 Organization: Rosenlaw & Einschlag Message-ID: <023701c81a8f$4f180980$6401a8c0@LROSENTOSHIBA> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20071029234911.0f1e8d80@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acgahk9kWogS75/USum8MY/7v7SLiAABDmPA X-Spam: [F=0.0856664991; heur=0.500(-19500); stat=0.085; spamtraq-heur=0.500(2007101727)] X-MAIL-FROM: X-SOURCE-IP: [216.173.237.89] X-SF-Loop: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Subject: RE: Patents can be for good, not only evil X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lrosen@rosenlaw.com List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Steven Bellovin wrote: > We've all seen far too many really bad > patents issued, ones where prior art is legion. The (U.S.) patent > office seems to do a far better job of searching its own databases than > it does the technical literature. > > I know there are many philosophical reasons why many people oppose > software patents. But for others, there are very practical reasons: > there are too many bad patents issued. I think we can all agree that > stopping bad patents is a worthwhile goal, even if for some it's just > an intermediate goal. The times they are a-changin'. [1] Please take a look at what's happening at http://dotank.nyls.edu/communitypatent/. This is a GREAT place for the technical experts in IETF to become involved in busting bad patents before they are issued. After patents are issued, busting them nowadays is also easier than it used to be if we can present prior art to support reexamination by the PTO. Take a look at what's happening at http://www.pubpat.org/. The notion that each IETF working group has to approach patent issues on its own, without help, is silly. Set an enforceable IETF patent policy for free and open standards, and bring the technical community together through these groups (and others!) to bust the bad patents we encounter, and I think our problems with patents will ease substantially. /Larry BCC: Beth Noveck and Dan Ravicher [1] By Bob Dylan: Come gather 'round people Wherever you roam And admit that the waters Around you have grown And accept it that soon You'll be drenched to the bone. If your time to you Is worth savin' Then you better start swimmin' Or you'll sink like a stone For the times they are a-changin'. Come writers and critics Who prophesize with your pen And keep your eyes wide The chance won't come again And don't speak too soon For the wheel's still in spin And there's no tellin' who That it's namin'. For the loser now Will be later to win For the times they are a-changin'. Come senators, congressmen Please heed the call Don't stand in the doorway Don't block up the hall For he that gets hurt Will be he who has stalled There's a battle outside And it is ragin'. It'll soon shake your windows And rattle your walls For the times they are a-changin'. Come mothers and fathers Throughout the land And don't criticize What you can't understand Your sons and your daughters Are beyond your command Your old road is Rapidly agin'. Please get out of the new one If you can't lend your hand For the times they are a-changin'. The line it is drawn The curse it is cast The slow one now Will later be fast As the present now Will later be past The order is Rapidly fadin'. And the first one now Will later be last For the times they are a-changin'. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 21:46:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imftd-0001sI-AQ; Mon, 29 Oct 2007 21:27:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imft1-00016C-50 for ietf@ietf.org; Mon, 29 Oct 2007 21:27:19 -0400 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imft0-0005Si-Mu for ietf@ietf.org; Mon, 29 Oct 2007 21:27:19 -0400 Received: from [192.168.0.3] (adsl-68-122-116-197.dsl.pltn13.pacbell.net [68.122.116.197]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l9U1QHBr019753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Oct 2007 17:26:17 -0800 Message-ID: <4726884C.3050004@dcrocker.net> Date: Mon, 29 Oct 2007 18:26:36 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Steven M. Bellovin" References: <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> <87fy00vn1l.fsf@mocca.josefsson.org> <471FB60B.3070304@gmail.com> <20071024214601.28e866ce@cs.columbia.edu> <00d801c81689$f64c5f30$6401a8c0@LROSENTOSHIBA> <4720FCFA.7080009@cs.utk.edu> <020d01c81a62$8a7d6510$6401a8c0@LROSENTOSHIBA> <47263C98! .6080703@cs.utk.edu> <022d01c81a7f$bd063ad0$6401a8c0@LROSENTOSHIBA> <20071029234911.0f1e8d80@cs.columbia.edu> In-Reply-To: <20071029234911.0f1e8d80@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ietf@ietf.org Subject: Re: Patents can be for good, not only evil X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Steven M. Bellovin wrote: > You're obviously right in theory on this point. I wonder whether > you're right in practice. We've all seen far too many really bad > patents issued, ones where prior art is legion. ... > I think we can all agree that > stopping bad patents is a worthwhile goal, even if for some it's just > an intermediate goal. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 23:35:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImhXp-0006Dc-IV; Mon, 29 Oct 2007 23:13:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImhXo-0006DU-Ko for ietf@ietf.org; Mon, 29 Oct 2007 23:13:32 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImhXn-0000p8-1n for ietf@ietf.org; Mon, 29 Oct 2007 23:13:32 -0400 Received: (snipe 19899 invoked by uid 0); 30 Oct 2007 12:06:56 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 1.074600 secs); Received: from unknown (HELO ?210.107.250.146?) (Z???own@210.107.250.146) by unknown with SMTP; 30 Oct 2007 12:06:55 +0900 X-SNIPER-SENDERIP: 210.107.250.146 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: leslie@thinkingcat.com, ietf@ietf.org, pmol@ietf.org, iesg@ietf.org, yangwooko@gmail.com Message-ID: <47269FC5.5030802@icu.ac.kr> Date: Tue, 30 Oct 2007 12:06:45 +0900 From: Yangwoo Ko User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Leslie Daigle References: <47263CC1.8000104@thinkingcat.com> In-Reply-To: <47263CC1.8000104@thinkingcat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: IESG , ietf@ietf.org, pmol@ietf.org Subject: Re: A question about [Fwd: WG Review: Performance Metrics at Other Layers (pmol)] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Since application developers have developed many tricks to smooth out some peculiarities of network-based protocols (e.g. jitter, delay, drops and so on), it is very often hard to related the performance measured/perceived at application layer with those of underlying layers. If this WG provides guidelines (or at least hints) to get over this vagueness, I will be very happy. Regards Leslie Daigle wrote: > > > At the Application Performance Metrics BoF in > Chicago, there was a lot of discussion about whether > or how to best capture expertise in the area of performance > metrics for application to IETF protocols. > > There seemed to be 2 separate questions on the table: > > 1/ how, and > 2/ whether > > to generalize a performance metric framework for IETF > protocols. > > > The proposed PMOL WG addresses the first question -- how > to do it. > > On the second point -- the question is really about whether > the IETF community as a whole supports/values performance > metrics and will invest the effort in using any general > framework for existing/new protocols. > > I believe the folks that joined the PMOL mailing list after > the APM BoF are assuming that support is there. > > I suggest that now is an excellent time for folks _not_ > involved in the PMOL effort, but who are working on > protocols that could/should make use of its output, to > voice some opinions on whether or not this approach > is helpful/will be useful to them in future protocols. > > > Leslie. > > > -------- Original Message -------- > Subject: WG Review: Performance Metrics at Other Layers (pmol) > Date: Mon, 22 Oct 2007 14:15:02 -0400 > From: IESG Secretary > Reply-To: iesg@ietf.org > To: ietf-announce@ietf.org > > A new IETF working group has been proposed in the Operations and > Management Area. The IESG has not made any determination as yet. > The following draft charter was submitted, and is provided for > informational purposes only. Please send your comments to the IESG > mailing list (iesg@ietf.org) by October 29. > > +++ > > Performance Metrics at Other Layers (pmol) > ============================================== > > Current Status: Proposed Working Group > > WG Chairs: > TBD > > Operations and Management Area: > Dan Romascanu > Ronald Bonica > > Description: > > The successful implementation and operation of IP based applications > often depends on some underlying performance measurement infrastructure > that helps service operators or network managers to recognize when > performance is unsatisfactory and identify problems affecting service > quality. Standardized performance metrics add the desirable features of > consistent implementation, interpretation, no comparison. > > The IETF has two Working Groups dedicated to the development of > performance metrics however each has strict limitations in their > charters: > > - The Benchmarking Methodology WG has addressed a range of networking > technologies and protocols in their long history (such as IEEE 802.3, > ATM, Frame Relay, and Routing Protocols), but the charter strictly > limits their Performance characterizations to the laboratory > environment. > > - The IP Performance Metrics WG has the mandate to develop metrics > applicable to the performance of Internet data delivery, but it is > specifically prohibited from developing metrics that characterize > traffic (such as a VoIP stream). > > The IETF also has current and completed activities related to the > reporting of application performance metrics (e.g. RAQMON and RTCP XR) > and is also actively involved in the development of reliable transport > protocols which would affect the relationship between IP performance and > application performance. > > Thus there is a gap in the currently chartered coverage of IETF WGs: > development of performance metrics for IP-based protocols and > applications that operate over UDP, TCP, SCTP, DCCP, Forward Error > Correction (FEC) and other robust transport protocols, and that can be > used to characterize traffic on live networks. > > The working group will focus on the completion of two RFCs: > > 1. A PMOL framework and guidelines memo that will describe the necessary > elements of performance metrics of protocols and applications > transported over IETF-specified protocols (such as the formal > definition, purpose, and units of measure) and the various types of > metrics that characterize traffic on live networks (such as metrics > derived from other metrics, possibly on lower layers). The framework > will also address the need to specify the intended audience and the > motivation for the performance metrics. There will also be guidelines > for a performance metric development process that includes entry > criteria for new proposals (how a proposal might be evaluated for > possible endorsement by a protocol development working group), and how > an successful proposal will be developed by PMOL WG in cooperation with > a protocol development WG. > > 2. A proof-of-concept RFC defining performance metrics for SIP, based on > draft-malas-performance-metrics. This memo would serve as an example of > the framework and the PMOL development process in the IETF. > > Discussion of new work proposals is strongly discouraged under the > initial charter of the PMOL WG, except to advise a protocol development > WG when they are evaluating a new work proposal for related performance > metrics. > > The PMOL WG will also be guided by a document describing how memos > defining performance metrics are intended to advance along the IETF > Standards track (draft-bradner-metricstest). > > PMOL WG will take advantage of expertise and seek to avoid overlap with > other standards development organizations, such as ETSI STQ, ITU-T SG > 12, ATIS IIF, ATIS PRQC, and others. > > Milestones > > June 08 SIP Performance Metrics Draft to IESG Review for consideration > as Proposed Standard > > Sept 08 PMOL Framework and Guidelines Draft to IESG Review for > consideration as BCP > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Oct 29 23:59:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imi9D-0007Ee-EM; Mon, 29 Oct 2007 23:52:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imi9B-00078E-Q6 for ietf@ietf.org; Mon, 29 Oct 2007 23:52:09 -0400 Received: from izb.knu.ac.kr ([155.230.157.93]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imi99-0001nE-3r for ietf@ietf.org; Mon, 29 Oct 2007 23:52:07 -0400 Received: by draba.izb.knu.ac.kr (Postfix, from userid 59) id 6FC983EA6; Tue, 30 Oct 2007 12:50:48 +0900 (KST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on draba.izb.knu.ac.kr X-Spam-Level: X-Spam-Status: No, score=-16.5 required=15.1 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VERIFIED autolearn=disabled version=3.2.3 X-Spam-Comment: DKIM? See http://www.google.com/search?btnI&q=RFC+4871 Received: from izb.knu.ac.kr (localhost.izb.knu.ac.kr [127.0.0.1]) by draba.izb.knu.ac.kr (Postfix) with ESMTP id 14B453EA4; Tue, 30 Oct 2007 12:50:47 +0900 (KST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=izb.knu.ac.kr; h=subject: from:reply-to:to:in-reply-to:references:content-type: content-transfer-encoding:date:message-id:mime-version; q= dns/txt; s=s1024; bh=MqZlEDFssKx5aVwRP2NkBHghhEk=; b=hRTnXtIcLha 1zILkD+saLjXospDEUyNLCtOjSx2lbuh1T/aoiROrdMsWw0NtXEj5Mgn2eeQ6dss RuOb4Eb5lWXQWXSq6OZ1CZ2feGL2lBY0IeGIySOEBTDyEKgDMcyzL68v0pmcanTH egb0+M4prhyi0qNVlTodLlMphxjHgfBo= Received: from viola.izb.knu.ac.kr (viola.izb.knu.ac.kr [IPv6:2002:9be6:9d5d:3::3]) by draba.izb.knu.ac.kr (Postfix) with ESMTP id EAAD63E94; Tue, 30 Oct 2007 12:50:46 +0900 (KST) Received: by viola.izb.knu.ac.kr (Postfix, from userid 1001) id 72D7C5E10; Tue, 30 Oct 2007 12:50:47 +0900 (KST) From: Byung-Hee HWANG To: ietf@ietf.org In-Reply-To: <4726884C.3050004@dcrocker.net> References: <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> <87fy00vn1l.fsf@mocca.josefsson.org> <471FB60B.3070304@gmail.com> <20071024214601.28e866ce@cs.columbia.edu> <00d801c81689$f64c5f30$6401a8c0@LROSENTOSHIBA> <4720FCFA.7080009@cs.utk.edu> <020d01c81a62$8a7d6510$6401a8c0@LROSENTOSHIBA> <47263C98! .6080703@cs.utk.edu> <022d01c81a7f$bd063ad0$6401a8c0@LROSENTOSHIBA> <20071029234911.0f1e8d80@cs.columbia.edu> <4726884C.3050004@dcrocker.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: InZealBomb Date: Tue, 30 Oct 2007 12:50:46 +0900 Message-Id: <1193716247.2282.3.camel@viola.izb.knu.ac.kr> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: Re: Patents can be for good, not only evil X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bh@izb.knu.ac.kr List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Mon, 2007-10-29 at 18:26 -0700, Dave Crocker wrote: > > Steven M. Bellovin wrote: > > You're obviously right in theory on this point. I wonder whether > > you're right in practice. We've all seen far too many really bad > > patents issued, ones where prior art is legion. > ... > > I think we can all agree that > > stopping bad patents is a worthwhile goal, even if for some it's just > > an intermediate goal. > > > +1 me too, +2 ;; -- "You can start by acting like a man." "LIKE A MAN!" -- Vito Corleone, "Chapter 1", page 36 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 30 00:01:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImiFS-0002sJ-U4; Mon, 29 Oct 2007 23:58:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImiFR-0002rx-Lg for ietf@ietf.org; Mon, 29 Oct 2007 23:58:37 -0400 Received: from machshav.com ([198.180.150.44]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImiFR-0001yV-80 for ietf@ietf.org; Mon, 29 Oct 2007 23:58:37 -0400 Received: by machshav.com (Postfix, from userid 512) id E687B5B4; Tue, 30 Oct 2007 03:58:36 +0000 (GMT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6B6824D4; Tue, 30 Oct 2007 03:58:36 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 30F59765F36; Mon, 29 Oct 2007 23:58:35 -0400 (EDT) Date: Tue, 30 Oct 2007 03:58:34 +0000 From: "Steven M. Bellovin" To: lrosen@rosenlaw.com Message-ID: <20071030035834.2d40fe5b@cs.columbia.edu> In-Reply-To: <023701c81a8f$4f180980$6401a8c0@LROSENTOSHIBA> References: <471A5668.8060505@gmail.com> <048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> <87fy00vn1l.fsf@mocca.josefsson.org> <471FB60B.3070304@gmail.com> <20071024214601.28e866ce@cs.columbia.edu> <00d801c81689$f64c5f30$6401a8c0@LROSENTOSHIBA> <4720FCFA.7080009@cs.utk.edu> <020d01c81a62$8a7d6510$6401a8c0@LROSENTOSHIBA> <47263C98! .6080703@cs.utk.edu> <022d01c81a7f$bd063ad0$6401a8c0@LROSENTOSHIBA> <20071029234911.0f1e8d80@cs.columbia.edu> <023701c81a8f$4f180980$6401a8c0@LROSENTOSHIBA> Organization: Columbia University X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.0; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ietf@ietf.org Subject: Re: Patents can be for good, not only evil X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Mon, 29 Oct 2007 17:53:35 -0700 "Lawrence Rosen" wrote: > Steven Bellovin wrote: > > We've all seen far too many really bad > > patents issued, ones where prior art is legion. The (U.S.) patent > > office seems to do a far better job of searching its own databases > > than it does the technical literature. > > > > I know there are many philosophical reasons why many people oppose > > software patents. But for others, there are very practical reasons: > > there are too many bad patents issued. I think we can all agree > > that stopping bad patents is a worthwhile goal, even if for some > > it's just an intermediate goal. > > The times they are a-changin'. [1] Yup, I remember it from when it was new.... > > Please take a look at what's happening at > http://dotank.nyls.edu/communitypatent/. This is a GREAT place for the > technical experts in IETF to become involved in busting bad patents > before they are issued. You raise an interesting point. Some years ago, the conventional wisdom was that it was a bad idea to oppose patents at that point, since any prior art introduced at that point were considered known by the patent office, and hence not usable to challenge the patent later. Objections based on such papers are reflected in the file wrapper, but not always in the language of the specification or the claims. In my experience, concessions by the applicant reflected there are not always understood by judges and/or juries. > > After patents are issued, busting them nowadays is also easier than > it used to be if we can present prior art to support reexamination by > the PTO. Take a look at what's happening at http://www.pubpat.org/. > Does it actually work in practice, when someone has filed a (preposterous) infringement suit and each side is hiring expensive experts? (Re-examination didn't seem to work for RIM.) --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 30 01:56:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImjiM-0003PV-3n; Tue, 30 Oct 2007 01:32:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImjiE-0003Oz-KL for ietf@ietf.org; Tue, 30 Oct 2007 01:32:26 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImjiE-0004Xs-6E for ietf@ietf.org; Tue, 30 Oct 2007 01:32:26 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9U5WOfO029743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 29 Oct 2007 22:32:25 -0700 Received: from [98.207.5.180] (vpn-10-50-0-1.qualcomm.com [10.50.0.1]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9U5WMYq029166; Mon, 29 Oct 2007 22:32:23 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <023701c81a8f$4f180980$6401a8c0@LROSENTOSHIBA> References: <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com><4 71A5668.8060505@gmail.com><048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA><20071022195723.4D9A22202DA@quill.bollo w.ch><20071023105651.8D9AC2202DA@quil l.bollow.ch><87abqa2i1z.fsf@mocca.josefsson.org><871wbm2cze.fsf@mocca.josefsson.org><87fy00v n1l.fsf@mocca.josefsson.org><471FB60B.3070304@gma il.com><20071024214601.28e866ce@cs.columbia.edu><00d801c81689$f64c5f30$640 1a8c0@LROSENTOSHIBA><4720FCFA.7080009@cs.utk.edu><020d01c81a62$8a7d6510$64 01a8c0@LROSENTOSHIBA><47263C98! .6080703@cs.utk.edu><022d01c81a7f$bd063ad0$6401a8c0@LROSENTOSHIBA> <20071029234911.0f1e8d80@cs.columbia.edu> <023701c81a8f$4f180980$6401a8c0@LROSENTOSHIBA> Date: Mon, 29 Oct 2007 22:32:32 -0700 To: lrosen@rosenlaw.com, From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ipr@ietf.org Subject: RE: Patents can be for good, not only evil X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 5:53 PM -0700 10/29/07, Lawrence Rosen wrote: >\The notion that each IETF working group has to approach patent issues on its >own, without help, is silly. Set an enforceable IETF patent policy for free >and open standards, and bring the technical community together through these >groups (and others!) to bust the bad patents we encounter, and I think our >problems with patents will ease substantially. This is a strawman. The IETF's patent policy is known: we require participants to NOTE it WELL all the time. Working groups do and should evaluate the known IPR landscape around their work, but presuming, as you do above, that all patents are bad patents which participants should spend their efforts busting is just wrong. There are patents that advance the art, and the IETF has clearly shown in the past its willingness to adapt to them when it needs to. I'd also say that IETF participants who spent their timing trying to bust patents on the lines of those Eric mentioned at the start of this thread are wasting their time. If the license doesn't stop implementation, the effort seems to me, personally, as better spent elsewhere. I've cc'ed the IPR working group, and I suggest follow-ups go there, as Brian has suggested. Travel will make me a bit late in reading replies, by the way; no offense intended. regards, Ted Hardie _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 30 05:43:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImnLw-0006uI-Jt; Tue, 30 Oct 2007 05:25:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImnLu-0006sQ-W2 for ietf@ietf.org; Tue, 30 Oct 2007 05:25:38 -0400 Received: from yxa.extundo.com ([83.241.177.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImnLj-0000Vw-Uz for ietf@ietf.org; Tue, 30 Oct 2007 05:25:33 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l9U9OiKe019533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Oct 2007 10:24:50 +0100 From: Simon Josefsson To: "James M. Polk" References: <871wbdvbg7.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071030:ietf@ietf.org::ml1YhIweQ3OKT6g0:196u X-Hashcash: 1:22:071030:eburger@bea.com::K9/hZnD9d2QKEd3m:MilX X-Hashcash: 1:22:071030:jmpolk@cisco.com::mlZ70kbOfGPeexum:YJUB Date: Tue, 30 Oct 2007 10:24:44 +0100 In-Reply-To: (James M. Polk's message of "Mon, 29 Oct 2007 18:03:22 -0500") Message-ID: <87640pneeb.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ietf@ietf.org Subject: Re: Oppose draft-carpenter-ipr-patent-frswds-00 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org "James M. Polk" writes: > At 04:48 PM 10/29/2007, Simon Josefsson wrote: >>"Eric Burger" writes: >> >> > One interesting side effect of the existence of an open source >> > implementation of a protocol is monoculture. We ran into a problem in >> > ifax year ago when it turned out that all eight "independent" >> > implementations all relied on the same library, thus rendering the >> > "independent" implementations label difficult, to say the least. Why >> > were there no independent implementations? Because in this case, the >> > open source implementation was pretty good, and it was not worth >> > investing in a proprietary implementation. The result here has a really >> > bad side effect for the IETF: if there is a good open source, free >> > implementation, there will be no second implementation, resulting in it >> > being impossible for the standard to progress. >> >>But that is how it is supposed to work! If there is only one >>implementation, a standard is not mature enough to move to DS. You need >>to have at least two, preferably several more, completely independent >>implementations in order to quality-test a standard. > > but why does one or both have to be open source? > > Why can't both be commercial? DS designates a mature standard. If you read the requirements in RFC 2026 for a mature standard it is clear that few of the modern IETF protocols live up to that standard -- you need to demonstrate interoperability between two completely independent implementations of _all_ features in the protocol standard. Another (existing) requirement is that any patent licenses needs to be obtained through separate processes. I believe that a good way to demonstrate that the patent license process works is to require that a free software implementation exists. I strongly believe it should be possible to participate on the Internet without paying a software patent tax to some organizations. > So few PSs become DSs, I believe this will almost certainly make > progression from PS to DS slower. Is that what we want? I believe it will lead to better quality DS standards. The reason few PSs become DSs is, in my experience, not because a lack of free implementations, but rather that nobody cares enough to go through the pain of interop testing. The requirements for DS are pretty high already, which can be discussed as a separate issue, but this draft is only a marginal change. My impression is that your problem really is that few documents move to DS, not that a free implementation should be required. > I admit now all PSs have IPR attached, but this is almost certainly > intended to kill any IPR from achieving DS. Is that what is intended > here? I don't believe that was the intention, but that's a question for Brian. I disagree that all PSs are patented (if that is what you meant). I've implemented several such standards without worrying about patents. I believe the majority of PSs are actually published without known patents. A search in the IETF IPR tracker should answer that. /Simon _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 30 06:10:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImnkX-0008Ra-86; Tue, 30 Oct 2007 05:51:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImnkV-0008Qi-Bw for ietf@ietf.org; Tue, 30 Oct 2007 05:51:03 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImnkL-0001jz-1j for ietf@ietf.org; Tue, 30 Oct 2007 05:50:59 -0400 Received: from E03MVC4-UKBR.domain1.systemhost.net ([193.113.197.116]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 09:50:28 +0000 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" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Oct 2007 09:51:48 -0000 Message-ID: In-Reply-To: <022d01c81a7f$bd063ad0$6401a8c0@LROSENTOSHIBA> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Patents can be for good, not only evil Thread-Index: AcgaZ5Kx19fcSEWLSJa0rKtQKea0vQAB5DNgAAPBL5AAFvrTMA== References: <877iljv6ed.fsf@mocca.josefsson.org><042201c8128a$63a1e400$6401a8c0@LROSENTOSHIBA><2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com><471A5668.8060505@gmail.com><048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA><20071022195723.4D9A22202DA@quill.bollow.ch><20071023105651.8D9AC2202DA@quill.bollow.ch><87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> <87fy00vn1l.fsf@mocca.josefsson.org> <471FB60B.3070304@gmail.com> <20071024214601.28e866ce@cs.columbia.edu> <00d801c81689$f64c5f30$6401a8c0@LROSENTOSHIBA> <4720FCFA.7080009@cs.utk.edu><020d01c81a62$8a7d6510$6401a8c0@LROSENTOSHIBA> <47263C98!.6080703@ cs.utk.edu> <022d01c81a7f$bd063ad0$6401a8c0@LROSENTOSHIBA> From: To: X-OriginalArrivalTime: 30 Oct 2007 09:50:28.0078 (UTC) FILETIME=[4D3830E0:01C81ADA] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: RE: Patents can be for good, not only evil X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > That was a waste of your time and money. Publication of those=20 > inventions by you, at zero cost to you and others, would have=20 > been sufficient to prevent someone else from trying to patent=20 > them. Next time, get good advice from a patent lawyer on how=20 > to achieve your goals without paying for a patent. Perhaps he did consult a lawyer and learned that by patenting them he now has the ability to sue any non-licenced implementors in court, and can take away a share of any earnings that they=20 made with their non-licenced implementation. That is not possible merely by publishing first. Law is every bit as complex as network protocols or application programming. It is better to consult with an expert in the field before making assumptions. I am not a lawyer. --Michael Dillon _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 30 06:26:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImoAl-00053y-A4; Tue, 30 Oct 2007 06:18:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImoAZ-0004wO-4G for ietf@ietf.org; Tue, 30 Oct 2007 06:17:59 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImoAX-0002xk-P1 for ietf@ietf.org; Tue, 30 Oct 2007 06:17:59 -0400 X-IronPort-AV: E=Sophos;i="4.21,346,1188802800"; d="scan'208";a="28369965" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-1.cisco.com with ESMTP; 30 Oct 2007 03:17:51 -0700 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9UAHocK025702; Tue, 30 Oct 2007 11:17:50 +0100 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp4425.cisco.com [10.61.81.72]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9UAHf2X023885; Tue, 30 Oct 2007 10:17:50 GMT Message-ID: <472704E0.7040202@cisco.com> Date: Tue, 30 Oct 2007 11:18:08 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Simon Josefsson X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1118; t=1193739470; x=1194603470; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=202026,=20draft,=20full,=20etc. |Sender:=20; bh=uL+JDTzztyibL9Q8mODz6mmrBdZick1yrLHsDp45kqQ=; b=me+ucSUTd2NUWT3slg5HSGF+haKxCk8tedjObua8EmecetN4yeIDNQ/+cgLeK37PqQbDVDI2 v2mFswombu7vW+GODelWH6TcPZL9qd+ZJ4Ey7KCKxlpxCp0nQj4MDLtz; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: IETF Discussion Subject: 2026, draft, full, etc. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org [I'm changing the subject and cutting off the references list as we seem to have changed topic.] Simon, > DS designates a mature standard. If you read the requirements in RFC > 2026 for a mature standard it is clear that few of the modern IETF > protocols live up to that standard -- you need to demonstrate > interoperability between two completely independent implementations of > _all_ features in the protocol standard. I think we can all agree that the calendaring standard is mature. We are in the process of doing what I would consider to be a relatively minor update to it, and yet it is only PS. IMAPv4 is only PS and yet has MASSIVE deployment. LDAP is only PS and is MASSIVELY deployed. SIP is all over the place and it is only PS as well. And so it's pretty clear that nobody cares about DS or IS. What's more, why should they? What benefit does it bring to anyone to advance a standard to DS? AND it's a whole lot of work. So why are we even having an argument about what gets stuck into requirements for DS? Shouldn't we instead be eliminating it entirely? Eliot _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 30 07:41:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImpAZ-0004pk-Ph; Tue, 30 Oct 2007 07:22:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImpAX-0004mC-IM for ietf@ietf.org; Tue, 30 Oct 2007 07:22:01 -0400 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImpAV-00064t-Ob for ietf@ietf.org; Tue, 30 Oct 2007 07:22:01 -0400 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Tue, 30 Oct 2007 11:21:49 +0000 References: <472704E0.7040202@cisco.com> In-Reply-To: <472704E0.7040202@cisco.com> MIME-Version: 1.0 Message-Id: <1040.1193743307.922477@peirce.dave.cridland.net> Date: Tue, 30 Oct 2007 11:21:47 +0000 From: Dave Cridland To: Eliot Lear Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: -1.4 (-) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: IETF-Discussion Subject: Re: 2026, draft, full, etc. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Tue Oct 30 10:18:08 2007, Eliot Lear wrote: > I think we can all agree that the calendaring standard is mature. > We > are in the process of doing what I would consider to be a relatively > minor update to it, and yet it is only PS. IMAPv4 is only PS and > yet > has MASSIVE deployment. LDAP is only PS and is MASSIVELY deployed. > SIP > is all over the place and it is only PS as well. And so it's pretty > clear that nobody cares about DS or IS. What's more, why should > they? Well, we don't, but mostly because we tend to know what the actual status of a particular protocol is. Usually. But not always, especially when it falls outside our area of expertise, and far more importantly, people not directly involved in the IETF at all don't know. I've suggested before that the advancement of a specification is a highly overloaded action - it implies that the IETF thinks it's a good idea, it implies that the specification is sound, it implies it's well deployed. > What benefit does it bring to anyone to advance a standard to DS? > AND > it's a whole lot of work. > > But it does do some good to review past specifications and note if they're still ok, it does do some good to note that specifications are solid, and it does do some good to say they're widely deployed. Sadly, this information does not get captured anywhere. > So why are we even having an argument about what gets stuck into > requirements for DS? Shouldn't we instead be eliminating it > entirely? And lose even the small amount of information it does give people? I think we'd do better to decide what information we want to be able to provide, and provide it, rather than wondering how many levels of overloaded information we should have. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 30 07:59:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Impao-0000rg-VN; Tue, 30 Oct 2007 07:49:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Impan-0000rU-3w for ietf@ietf.org; Tue, 30 Oct 2007 07:49:09 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Impam-0008Dw-BF for ietf@ietf.org; Tue, 30 Oct 2007 07:49:09 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9UBn0q6006685; Tue, 30 Oct 2007 04:49:00 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9UBmw5e002932; Tue, 30 Oct 2007 04:48:58 -0700 Received: from 172.24.29.108 ([172.24.29.108]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Tue, 30 Oct 2007 11:48:57 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 30 Oct 2007 07:48:48 -0400 From: Eric Burger To: , , , Message-ID: Thread-Topic: Patents can be for good, not only evil Thread-Index: Acgawbo4YPVJeNJCSO+fZsiRz9x1fgAKRrhV In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 1.2 (+) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: Subject: Re: Patents can be for good, not only evil X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org More to the point, patent law is one of the only two areas of law where you are guilty until you can prove yourself innocent. The other is tax law. Yes, I could have simply published the work. That establishes prior art. However, let us consider this very real (I have experienced it) scenario. 1. I invent something. It is generally useful, yet I don't think I'll get rich on the idea. 2. I publish the invention, to put a stake in the ground, hoping to put the invention into the commons. 3. Someone else, without knowledge of my publication, invents something similar, or the same, and patents the invention. 4. That someone else sues people over my invention. 5. I am now facing US$ 250,000 minimum, US$ 1,000,000 typical, in legal fees to invalidate the patent issued in step 3. 6. I would win the case, because I have the prior art. However, I am not stupid, so I begrudgingly pay $40,000 for the privilege of using my own invention and not paying tons of legal fees. This is why I call it inoculation. US$ 12,000 in legal and filing fees today has a 20x - 80x return on investment protection. Is the system stupid? Unquestionably. Is it the system? Yes. On 10/30/07 2:52 AM, "Dean Anderson" wrote: > [I am rather getting tired of 100+ email addresses in the to: field. > Pine also doesn't allow reply-all to the bcc: field. I'm thinking of > creating a new list of everyone that posts to the IETF list. Thoughts?] > > > On Mon, 29 Oct 2007, Lawrence Rosen wrote: > >> Eric Burger wrote: >>> I specifically applied for patents underlying the technology behind >>> RFC 4722/RFC 5022 and RFC 4730 specifically to prevent third >>> parties, who are not part of the IETF process, from extracting >>> royalties from someone who implements MSCML or KPML. >> >> That was a waste of your time and money. Publication of those >> inventions by you, at zero cost to you and others, would have been >> sufficient to prevent someone else from trying to patent them. Next >> time, get good advice from a patent lawyer on how to achieve your >> goals without paying for a patent. > > This was true only in the U.S., and will not be true once the senate > passes the first-to-file legislation that recently passed the house. > > Once first-to-file is put into effect, everyone has to race to the > patent office. It doesn't matter who invented what. However, years ago > legislation passed that grandfather'd the original inventor; the > original inventor can't be charged fees. However, the original inventor > can't change the royalty structure imposed by the first filer. > >> For those here who keep asking for protection against patents in >> standards, there is no more effective technique than through a revised >> IPR policy that prohibits patent-encumbered standards from gaining the >> IETF brand in the first place. > > This sounds like a good idea at first. However, the LPF has long > promoted protective patents: > http://lpf.ai.mit.edu/Patents/mutual-def.html > > It would be a bad idea to prohibit all patents in standards. > > In a first-to-invent regime, the law still favors one with a patent, > since it gives one a cross-licensing opportunity to settle a dispute > with a similar, infringed patent, even if one uses their patent only > protectively. > > In a first-to-file regime, protective patents are absolutely necessary. > The U.S. is treaty-bound (GATT) to implement first-to-file patent law. > The House recently passed this legislation, and I think it is expected > to pass the Senate, but the Senate hasn't yet voted. > > I'm a little uneasy about changing the IETF patent policy. First, the > current policy has exactly the right idea: consider the patent and its > license, and make a smart decision. If one follows the rules honestly, > the rules are just right. > > Second, the people most in favor of changing it are the very ones who > silenced me, and who are generally pro-patent. They were the same ones > who said that RFC 3979 wasn't the policy of the IETF. When we look > closely at the proposed document, it has ambiguities (already noticed by > others) that don't distinguish free-as-in-beer from free-as-in-freedom. > > The only thing I might recommend changing about the present policy is to > add a definite mandatory penalty for deceiving the IETF. > > I think we need more honesty and accountability in the leadership of the > IETF before we make such changes. > > --Dean > > Dean Anderson > President of the League for Programming Freedom > > > > > -- > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 > > > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 30 08:20:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Impwj-00033g-2a; Tue, 30 Oct 2007 08:11:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Impwh-0002z6-FR for ietf@ietf.org; Tue, 30 Oct 2007 08:11:47 -0400 Received: from [80.74.100.144] (helo=antivir2.rad.co.il) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Impvz-0000TW-2X for ietf@ietf.org; Tue, 30 Oct 2007 08:11:03 -0400 Received: from exrad3.rad.co.il (HELO exrad3.ad.rad.co.il) ([192.114.24.112]) by antivir2.rad.co.il with ESMTP; 30 Oct 2007 14:10:59 +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" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Oct 2007 14:10:58 +0200 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D056FC808@exrad3.ad.rad.co.il> In-Reply-To: <022d01c81a7f$bd063ad0$6401a8c0@LROSENTOSHIBA> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Patents can be for good, not only evil Thread-Index: AcgaZ5Kx19fcSEWLSJa0rKtQKea0vQAB5DNgAAPBL5AAG82ssA== From: "Yaakov Stein" To: , X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: RE: Patents can be for good, not only evil X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org =20 >> I specifically applied for patents underlying the technology behind=20 >> RFC 4722/RFC 5022 and RFC 4730 specifically to prevent third parties, >> who are not part of the IETF process, from extracting royalties from=20 >> someone who implements MSCML or KPML. > That was a waste of your time and money. Publication of those inventions by you, at zero cost to you and others,=20 > would have been sufficient to prevent someone else from trying to patent them.=20 Quite untrue, in my experience. The patent examiners almost never find prior art from the open literature. Their decisions are based on their databases of existing patents. So althought you are quite right in principle, open publication has low probability of blocking someone from getting a patent.=20 Fighting a granted patent on the base of open publication prior art would cost much more. Y(J)S _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 30 08:33:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imq8M-0004Xi-RK; Tue, 30 Oct 2007 08:23:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imq8K-0004Tu-Mx for ietf@ietf.org; Tue, 30 Oct 2007 08:23:48 -0400 Received: from [212.199.240.16] (helo=antivir2.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imq8A-0000D8-DT for ietf@ietf.org; Tue, 30 Oct 2007 08:23:44 -0400 Received: from exrad3.rad.co.il (HELO exrad3.ad.rad.co.il) ([192.114.24.112]) by antivir2.rad.co.il with ESMTP; 30 Oct 2007 14:22:19 +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" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Oct 2007 14:22:18 +0200 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D056FC814@exrad3.ad.rad.co.il> In-Reply-To: <023701c81a8f$4f180980$6401a8c0@LROSENTOSHIBA> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Patents can be for good, not only evil Thread-Index: Acgahk9kWogS75/USum8MY/7v7SLiAABDmPAABkFyaA= From: "Yaakov Stein" To: , X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: RE: Patents can be for good, not only evil X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Larry Sorry that I answered before seeing that others had already said the same thing. However, even after reading your subsequent email, I am unconvinced. Requesting a re-examination is a lengthy process, and if unsuccessful further strengthens the party holding the patent (as it has gone through 2 examinations). On the other hand, the patent holder can force you to respond in a Texas court within 30 days, incurring the costs of representation. BTW, this kind of patent busting is hardly new. There used to be a "patent busters" site where bounties were offered. Y(J)S _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 30 09:34:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImqzR-0004bl-G6; Tue, 30 Oct 2007 09:18:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImqzP-0004YM-LF for ietf@ietf.org; Tue, 30 Oct 2007 09:18:39 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImqzN-0002vp-5s for ietf@ietf.org; Tue, 30 Oct 2007 09:18:37 -0400 Received: from E03MVC4-UKBR.domain1.systemhost.net ([193.113.197.116]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 13:18:36 +0000 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" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Oct 2007 13:21:18 -0000 Message-ID: In-Reply-To: <1040.1193743307.922477@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 2026, draft, full, etc. Thread-Index: Acga6fPTqjQgdW+XT72ILOqHDT5/egADTeuw References: <472704E0.7040202@cisco.com> <1040.1193743307.922477@peirce.dave.cridland.net> From: To: X-OriginalArrivalTime: 30 Oct 2007 13:18:36.0564 (UTC) FILETIME=[60EFED40:01C81AF7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: RE: 2026, draft, full, etc. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > I've suggested before that the advancement of a specification=20 > is a highly overloaded action - it implies that the IETF=20 > thinks it's a good idea, it implies that the specification is=20 > sound, it implies it's well deployed. Does the IETF have a way to communicate that a specification is=20 a good idea with a sound specification and that is well deployed? For that matter, does the IETF have a way to make that determination? One way in which the IETF has conveyed additional info in the past is by designating RFCs as part of a BCP or FYI series. Similar=20 mechanisms could be used to convey that a specification is more than just a plain old humdrum RFC. The point of all this being, that if the IETF does communicate that certain RFCs are of a higher class than others, it makes it harder for others to misunderstand the meaning (or mislead others about the meaning) of RFC status for some particular protocol. --Michael Dillon _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 30 09:56:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImrPf-000133-0T; Tue, 30 Oct 2007 09:45:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImrPd-00012t-Gl for ietf@ietf.org; Tue, 30 Oct 2007 09:45:45 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImrPd-0003l2-6C for ietf@ietf.org; Tue, 30 Oct 2007 09:45:45 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7A6012596E1; Tue, 30 Oct 2007 14:45:44 +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 14589-06; Tue, 30 Oct 2007 14:45:39 +0100 (CET) Received: from [172.27.172.121] (unknown [65.91.246.2]) by eikenes.alvestrand.no (Postfix) with ESMTP id CE6E52596D6; Tue, 30 Oct 2007 14:45:37 +0100 (CET) Date: Mon, 29 Oct 2007 22:29:41 -0700 From: Harald Tveit Alvestrand To: lrosen@rosenlaw.com, ietf@ietf.org Message-ID: <77F3A8A0C26D068BE6DB457B@B50854F0A9192E8EC6CDA126> In-Reply-To: <023701c81a8f$4f180980$6401a8c0@LROSENTOSHIBA> References: <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com> <471A5668.8060505@gmail.com><048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA> <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> <87fy00vn1l.fsf@mocca.josefsson.org> <471FB60B.3070304@gmail.com><20071024214601.28e866ce@cs.columbia.edu> <00d801c81689$f64c5f30$6401a8c0@LROSENTOSHIBA><4720FCFA.7080009@cs.utk.edu> <020d01c81a62$8a7d6510$6401a8c0@LROSENTOSHIBA><47263C98! .6080703@cs.utk.edu> <022d01c81a7f$bd063ad0$6401a8c0@LROSENTOSHIBA> <20071029234911.0f1e8d80@cs.columbia.edu> <023701c81a8f$4f180980$6401a8c0@LROSENTOSHIBA> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 1.9 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: RE: Patents can be for good, not only evil X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org --On 29. oktober 2007 17:53 -0700 Lawrence Rosen wrote: > > The notion that each IETF working group has to approach patent issues on > its own, without help, is silly. It's also a straw man. RFC 3669. You may argue that we can do better, but the argument that there is "no help" is silly. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 30 10:06:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imrcm-00042I-On; Tue, 30 Oct 2007 09:59:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imrcl-00042D-Ro for ietf@ietf.org; Tue, 30 Oct 2007 09:59:19 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imrce-0004qz-Ln for ietf@ietf.org; Tue, 30 Oct 2007 09:59:19 -0400 Received: from [65.170.117.141] ([::ffff:65.170.117.141]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 30 Oct 2007 09:58:41 -0400 id 01588024.47273891.0000799B In-Reply-To: <472388E9.8070700@gmail.com> References: <472388E9.8070700@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6D007A8C-B397-458E-A9BD-F50F069ED73F@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Tue, 30 Oct 2007 09:58:38 -0400 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ietf@ietf.org Subject: Re: Non-participants [Re: Experimental makes sense for tls-authz] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Oct 27, 2007, at 2:52 PM, Brian E Carpenter wrote: > On 2007-10-28 06:36, Andrew Newton wrote: >> On Oct 27, 2007, at 11:00 AM, David Morris wrote: >>> Well for starters, the drive-by hummers have to sit through the >>> session >>> and be present for the discussion (note I intentionally did not say >>> listen). They have to demonstrate enough interest in the IETF >>> process to >>> actually pay the costs of attending the session. >> Most of the drive-by hummers have their head buried in their email >> or other laptop work, so the expense they run for looking up to >> hum once or twice isn't at all onerous. At least in this case, >> the drive-by emailers had to spend some thought cycles on the >> email they composed. > > [By the way, when I find myself in a WG meeting I'm not prepared > for, I often have my head buried in the drafts being discussed, > so as to be able to understand the issues. Don't assume that a head > buried in a laptop is always doing email.] Has there been an assumption that these "non-participants" sending email have not read the tls-authz draft? Again, I see no difference between what is happening on this list vs. what would happen in a F2F meeting, except that I've never witnessed a chair or AD say "Well, it is obvious you guys are all non-participants and therefore your hums will be ignored" in a F2F meeting. And I agree with Frank's point about these emails. They have been unfairly classified as an "attack" or a DoS, perhaps to delegitimize their content. And this episode doesn't really compare to previous campaigns. I agree that some of the content of the emails is nonsensical, but the counter argument to them is that the document should be published because the IETF process has a slot into which it will fit. Or in other words, the IETF should publish it because it can. That does not seem like a good enough reason. > Secondly, WG chairs and the responsible AD are well able to notice > that a meeting has been packed, and to interpret any straw poll > or hum accordingly. Well, I'm not sure how often it happens. I can only think of 3 incidents in these past many years. But in a more recent one, the ADs seemed to either be unaware or unprepared. -andy _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 30 10:51:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImsCE-0001eF-KH; Tue, 30 Oct 2007 10:35:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImsCC-0001e8-An for ietf@ietf.org; Tue, 30 Oct 2007 10:35:56 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImsC2-0006Pp-CS for ietf@ietf.org; Tue, 30 Oct 2007 10:35:56 -0400 Received: from [192.168.0.3] (adsl-68-122-116-197.dsl.pltn13.pacbell.net [68.122.116.197]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l9UEYobc008845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Oct 2007 06:34:50 -0800 Message-ID: <4727411C.8040206@dcrocker.net> Date: Tue, 30 Oct 2007 07:35:08 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eric Burger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ipr@ietf.org, license-discuss@opensource.org, ietf@ietf.org, campaigns@fsf.org Subject: Re: Patents can be for good, not only evil X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Eric Burger wrote: > 5. I am now facing US$ 250,000 minimum, US$ 1,000,000 typical, in legal fees > to invalidate the patent issued in step 3. From what I've been told, $1M is more like the entry fee for this contest, if the patent holder has any tenacity at all. And if they do, it gets a lot higher, quickly. > 6. I would win the case, because I have the prior art. However, I am not > stupid, so I begrudgingly pay $40,000 for the privilege of using my own > invention and not paying tons of legal fees. Again, from what I've been told, your assertion is far too optimistic. The realities of challenging a patent are not nearly that deterministic. At a minimum, the human frailties of judges and juries makes it a gamble whether they will agree that a particular piece of prior art is, indeed, prior art. Let's remember that patents are about technical things, and judges and juries -- no matter how diligent and well-intentioned, are not classed as 'skilled in the art'. So their understanding of issues and details is typically going to be significantly constrained, no matter how well the issues are presented to them. All of which serves to strengthen your argument in favor of defensively patenting the prior art. > This is why I call it inoculation. US$ 12,000 in legal and filing fees > today has a 20x - 80x return on investment protection. But that's real money for an individual to spend. And real hassle. It's asking rather a lot to expect folks to a) think of their work as prior art, b) take the time, and c) spend the money just for the greater good. That's assuming they can afford the time and money. > Is the system stupid? Unquestionably. Is it the system? Yes. Public review during the final stages of patenting has struck me as a particularly constructive effort. Whether it works, I've no idea. As noted, patent officers are human too. But from what I've seen of patent file wrappers, the patent officers generally do seem to look for real prior art, albeit not as widely as we would wish. But, then, they operate under serious time and resource constraints. Input from the public would help counter this. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 30 12:02:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImtJK-0004DZ-3c; Tue, 30 Oct 2007 11:47:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImtJI-0004DN-LZ for ietf@ietf.org; Tue, 30 Oct 2007 11:47:20 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImtJC-0000jB-Ap for ietf@ietf.org; Tue, 30 Oct 2007 11:47:20 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 1E83A2C06F; Tue, 30 Oct 2007 11:47:04 -0400 (EDT) X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zj2F988ZQHeI; Tue, 30 Oct 2007 11:47:01 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 6A1672C073; Tue, 30 Oct 2007 11:46:55 -0400 (EDT) In-Reply-To: To: "Eric Burger" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Tue, 30 Oct 2007 11:46:53 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 10/30/2007 11:46:53 AM, Serialize complete at 10/30/2007 11:46:53 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: Keith Moore , ietf@ietf.org Subject: Re: Patents can be for good, not only evil X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0716618246==" Errors-To: ietf-bounces@ietf.org This is a multipart message in MIME format. --===============0716618246== Content-Type: multipart/alternative; boundary="=_alternative 0056AF9685257384_=" This is a multipart message in MIME format. --=_alternative 0056AF9685257384_= Content-Type: text/plain; charset="US-ASCII" Hi Eric, I generally agree, that patents are not *necessarily* evil ... just that they can be, so need to err on the side of caution. > Phil Zimmerman has applied for patents in ZRTP, specifically to ensure > that all implementations fully conform with the specification. Cost to > license for a conformant specification? $0. Cost to not really provide > privacy but claim to be implementing ZRTP? Costly! Cannot resist: I believe it was Dean Willis that described this approach as "brilliantly evil" a couple of IETF meets ago... >;-> -- Peter "Eric Burger" 29.10.07 17:16 To: "Keith Moore" , cc: ietf@ietf.org Subject: Patents can be for good, not only evil I would offer that patents are NOT categorically evil. Phil Zimmerman has applied for patents in ZRTP, specifically to ensure that all implementations fully conform with the specification. Cost to license for a conformant specification? $0. Cost to not really provide privacy but claim to be implementing ZRTP? Costly! I specifically applied for patents underlying the technology behind RFC 4722/RFC 5022 and RFC 4730 specifically to prevent third parties, who are not part of the IETF process, from extracting royalties from someone who implements MSCML or KPML. Cost to license? $0. Cost to sue someone who infringes said third-party's IPR? That depends, but at least we raised the cost of shutting down an IETF standard. Remember, just because *you* do not have IPR in an IETF standard does not mean someone *else* has IPR in the standard. If that someone else does not participate in the IETF or, for that matter, happen to not participate in the work group or, in reality, are not editors of a document, they can fully apply their IPR against the standard once it issues. I like to have a little inoculation against that situation in the stuff I submit. -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Monday, October 29, 2007 4:04 PM To: lrosen@rosenlaw.com Cc: ietf@ietf.org Subject: Re: When is using patented technology appropriate? Lawrence Rosen wrote: > Keith Moore wrote: > >> For several reasons, it is difficult to imagine an IETF-wide >> procedure that allows the existence of a patent to trump other >> considerations of protocol feasibility and deployability: >> > > Who suggested otherwise? It is not the existence of the patent that > matters, but its unavailability under license terms that allow > implementation in > *any* software. > _and_ its validity, _and_ its applicability, both of which can be subjective and difficult to determine conclusively without long delays and excessive expense. so we have to make judgments. and by "we" I mean individuals participating in IETF, not IETF itself. > The more feasible and deployable the protocol, the more important will > be FOSS implementations. > only relative to other protocols in the same space. granted that patents are the bane of any open standards-making organization, because patents do exactly the opposite of what open standards do. at the same time, we can't let FUD about patents become a denial of service attack to IETF efforts. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --=_alternative 0056AF9685257384_= Content-Type: text/html; charset="US-ASCII"
Hi Eric,

I generally agree, that patents are not *necessarily* evil ... just that they can be, so need to err on the side of caution.

> Phil Zimmerman has applied for patents in ZRTP, specifically to ensure
> that all implementations fully conform with the specification.  Cost to
> license for a conformant specification?  $0.  Cost to not really provide
> privacy but claim to be implementing ZRTP?  Costly!


Cannot resist:   I believe it was Dean Willis that described this approach as "brilliantly evil" a couple of IETF meets ago...  >;->

-- Peter





"Eric Burger" <eburger@bea.com>

29.10.07 17:16

       
        To:        "Keith Moore" <moore@cs.utk.edu>, <lrosen@rosenlaw.com>
        cc:        ietf@ietf.org
        Subject:        Patents can be for good, not only evil



I would offer that patents are NOT categorically evil.

Phil Zimmerman has applied for patents in ZRTP, specifically to ensure
that all implementations fully conform with the specification.  Cost to
license for a conformant specification?  $0.  Cost to not really provide
privacy but claim to be implementing ZRTP?  Costly!

I specifically applied for patents underlying the technology behind RFC
4722/RFC 5022 and RFC 4730 specifically to prevent third parties, who
are not part of the IETF process, from extracting royalties from someone
who implements MSCML or KPML.  Cost to license?  $0.  Cost to sue
someone who infringes said third-party's IPR?  That depends, but at
least we raised the cost of shutting down an IETF standard.

Remember, just because *you* do not have IPR in an IETF standard does
not mean someone *else* has IPR in the standard.  If that someone else
does not participate in the IETF or, for that matter, happen to not
participate in the work group or, in reality, are not editors of a
document, they can fully apply their IPR against the standard once it
issues.

I like to have a little inoculation against that situation in the stuff
I submit.

-----Original Message-----
From: Keith Moore [mailto:moore@cs.utk.edu]
Sent: Monday, October 29, 2007 4:04 PM
To: lrosen@rosenlaw.com
Cc: ietf@ietf.org
Subject: Re: When is using patented technology appropriate?

Lawrence Rosen wrote:
> Keith Moore wrote:
>  
>> For several reasons, it is difficult to imagine an IETF-wide
>> procedure that allows the existence of a patent to trump other
>> considerations of protocol feasibility and deployability:
>>    
>
> Who suggested otherwise? It is not the existence of the patent that
> matters, but its unavailability under license terms that allow
> implementation in
> *any* software.
>  
_and_ its validity, _and_ its applicability, both of which can be
subjective and difficult to determine conclusively without long delays
and excessive expense.   so we have to make judgments.  and by "we" I
mean individuals participating in IETF, not IETF itself.
> The more feasible and deployable the protocol, the more important will

> be FOSS implementations.
>  
only relative to other protocols in the same space.

granted that patents are the bane of any open standards-making
organization, because patents do exactly the opposite of what open
standards do.  at the same time, we can't let FUD about patents become a
denial of service attack to IETF efforts.

Keith


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--=_alternative 0056AF9685257384_=-- --===============0716618246== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0716618246==-- From ietf-bounces@ietf.org Tue Oct 30 14:35:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imvb1-00041V-VA; Tue, 30 Oct 2007 14:13:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imvb0-00041H-Ao for ietf@ietf.org; Tue, 30 Oct 2007 14:13:46 -0400 Received: from dizzyd.com ([207.210.219.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imvao-0006On-Sq for ietf@ietf.org; Tue, 30 Oct 2007 14:13:46 -0400 Received: from wrk225.corp.jabber.com (dencfw1.jabber.com [207.182.164.5]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTP id 1A67840091; Tue, 30 Oct 2007 12:13:16 -0600 (MDT) Message-ID: <4727748D.8060001@stpeter.im> Date: Tue, 30 Oct 2007 12:14:37 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Dave Cridland References: <472704E0.7040202@cisco.com> <1040.1193743307.922477@peirce.dave.cridland.net> In-Reply-To: <1040.1193743307.922477@peirce.dave.cridland.net> X-Enigmail-Version: 0.95.4 OpenPGP: id=7BBD0573; url=http://www.saint-andre.com/me/stpeter.asc Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: IETF-Discussion , Eliot Lear Subject: Re: 2026, draft, full, etc. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1677862501==" Errors-To: ietf-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1677862501== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030101060503080207090606" This is a cryptographically signed message in MIME format. --------------ms030101060503080207090606 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dave Cridland wrote: > On Tue Oct 30 10:18:08 2007, Eliot Lear wrote: >> What benefit does it bring to anyone to advance a standard to DS? AND >> it's a whole lot of work. >> > But it does do some good to review past specifications and note if > they're still ok, it does do some good to note that specifications are > solid, and it does do some good to say they're widely deployed. Sadly, > this information does not get captured anywhere. Not to mention the value of incorporating the results of implementation and deployment experience (though perhaps that's part of what you call reviewing past specifications). I suppose that incorporating experience, reviewing the specification, and the like can be done by cycling at PS forever, so it's not clear whether DS and IS really matter. However, it may be that those good things happen only by advancing a technology to DS. If so, then perhaps it's OK that doing so is "a whole lot of work" as Eliot says. After all, advancing an I-D to RFC is a whole lot of work, too, but we generally consider that process to be beneficial. Maybe we need to more clearly enunciate the benefits of advancing a technology to DS? Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms030101060503080207090606 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0 4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+ JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE 9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0 aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0 ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/ yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA 75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna 1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf 5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3 DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0 aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0 Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0 dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1 My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMzAxODE0MzdaMCMGCSqG SIb3DQEJBDEWBBQjWvrfmEyMmZ9JsrQpMFSTST8CgzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC AQCHUsu17hvzHoZze+LBp3BkQZTxvbMeebrxBBTWvOb7ligZNoLYQ97pM2Lny5/rUlU+7le5 8yRep3R22le9GfsztNN9VgVLe+pedWG7GTj/69oli45qRSXeXWwybKREwJ//1ziQmsRACVQ0 ysR7EUrEuyJMo2jbdBYQhnghzYifH2OoS+lB+4h7dpl+F743RDWXZNyv5iVdRtokP9r81Wb4 5/8Scm62IAtC+UfKTLR04OkOC0Snhknj98P8pzGvXqYDjxjl/se2pRq+jnQWzoUa+P5aCRYZ Csw03OOg3c40s07hzqVZ8c0mkkiVedJYfsVGav+OzpMK/e99BzGaHOScAAAAAAAA --------------ms030101060503080207090606-- --===============1677862501== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============1677862501==-- From ietf-bounces@ietf.org Tue Oct 30 14:46:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imvyl-0003Ai-Ge; Tue, 30 Oct 2007 14:38:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imvyj-00037D-R1 for ietf@ietf.org; Tue, 30 Oct 2007 14:38:17 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imvyd-0007Oc-J2 for ietf@ietf.org; Tue, 30 Oct 2007 14:38:17 -0400 X-IronPort-AV: E=Sophos;i="4.21,348,1188802800"; d="scan'208";a="411767836" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-2.cisco.com with ESMTP; 30 Oct 2007 11:38:05 -0700 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9UIc5U6020741; Tue, 30 Oct 2007 14:38:05 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9UIbTBI006336; Tue, 30 Oct 2007 18:37:51 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 14:37:24 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.17.26]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 14:37:23 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Oct 2007 13:37:23 -0500 To: Simon Josefsson From: "James M. Polk" In-Reply-To: <87640pneeb.fsf@mocca.josefsson.org> References: <871wbdvbg7.fsf@mocca.josefsson.org> <87640pneeb.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 30 Oct 2007 18:37:24.0060 (UTC) FILETIME=[E9D031C0:01C81B23] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15514.002 X-TM-AS-Result: No--20.166000-8.000000-4 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=665; t=1193769485; x=1194633485; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20Oppose=20draft-carpenter-ipr-patent-frswds-00 |Sender:=20 |To:=20Simon=20Josefsson=20; bh=m13gooLMFpFHXIkT8f3y/T3F5vfLLInZOIrKxaH1fWY=; b=OkWr2hpSJtSgandNCBxv3MUArrwqek6Z+Nb3uEHDp5T5L9enSqkZBpg4myyWZLPJSscB5QaK rauwgqOFAGaKY+hnmRVZBXt7UUwTyOv5y6twRrpSOFm7chSOZhOVCpH4; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ietf@ietf.org Subject: Re: Oppose draft-carpenter-ipr-patent-frswds-00 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 04:24 AM 10/30/2007, Simon Josefsson wrote: > > I admit now s/now/not >all PSs have IPR attached, but this is almost certainly > > intended to kill any IPR from achieving DS. Is that what is intended > > here? > >I don't believe that was the intention, but that's a question for Brian. > >I disagree that all PSs are patented (if that is what you meant). see above - I misspelled a word that means something else. sorry >I've >implemented several such standards without worrying about patents. I >believe the majority of PSs are actually published without known >patents. A search in the IETF IPR tracker should answer that. > >/Simon _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 30 14:48:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imw5f-00088G-6j; Tue, 30 Oct 2007 14:45:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imw5d-00087z-Mg for ietf@ietf.org; Tue, 30 Oct 2007 14:45:25 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imw5c-0007iE-Fb for ietf@ietf.org; Tue, 30 Oct 2007 14:45:25 -0400 X-IronPort-AV: E=Sophos;i="4.21,348,1188802800"; d="scan'208";a="541399253" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-3.cisco.com with ESMTP; 30 Oct 2007 11:45:23 -0700 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9UIjNN9024656; Tue, 30 Oct 2007 14:45:23 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9UIilBo009104; Tue, 30 Oct 2007 18:45:23 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 14:45:19 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.17.26]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 14:45:19 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Oct 2007 13:45:19 -0500 To: Simon Josefsson From: "James M. Polk" In-Reply-To: <87640pneeb.fsf@mocca.josefsson.org> References: <871wbdvbg7.fsf@mocca.josefsson.org> <87640pneeb.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 30 Oct 2007 18:45:19.0369 (UTC) FILETIME=[051E9790:01C81B25] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15514.002 X-TM-AS-Result: No--26.653600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3008; t=1193769923; x=1194633923; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20Oppose=20draft-carpenter-ipr-patent-frswds-00 |Sender:=20 |To:=20Simon=20Josefsson=20; bh=tNLcDocCKQhxR2VKZRReXeXXBKy8ydL3dQWnOpoD+qI=; b=Zi/BdJVOf54RSfxjSc/fJKJO4HTE9KByIS0t0KeCVpNNQ8Hh2kClH6EYRZD5rYKLEC5Wp5JE WPUsGLfQtxEh29nDcubHbNH93pEhlgyXerU3LgUN2kAcBYzbAY6psAli; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ietf@ietf.org Subject: Re: Oppose draft-carpenter-ipr-patent-frswds-00 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 04:24 AM 10/30/2007, Simon Josefsson wrote: > > At 04:48 PM 10/29/2007, Simon Josefsson wrote: > >>"Eric Burger" writes: > >> > >> > One interesting side effect of the existence of an open source > >> > implementation of a protocol is monoculture. We ran into a problem in > >> > ifax year ago when it turned out that all eight "independent" > >> > implementations all relied on the same library, thus rendering the > >> > "independent" implementations label difficult, to say the least. Why > >> > were there no independent implementations? Because in this case, the > >> > open source implementation was pretty good, and it was not worth > >> > investing in a proprietary implementation. The result here has a really > >> > bad side effect for the IETF: if there is a good open source, free > >> > implementation, there will be no second implementation, resulting in it > >> > being impossible for the standard to progress. > >> > >>But that is how it is supposed to work! If there is only one > >>implementation, a standard is not mature enough to move to DS. You need > >>to have at least two, preferably several more, completely independent > >>implementations in order to quality-test a standard. > > > > but why does one or both have to be open source? > > > > Why can't both be commercial? > >DS designates a mature standard. If you read the requirements in RFC >2026 for a mature standard it is clear that few of the modern IETF >protocols live up to that standard -- you need to demonstrate >interoperability between two completely independent implementations of >_all_ features in the protocol standard. Another (existing) requirement >is that any patent licenses needs to be obtained through separate >processes. I believe that a good way to demonstrate that the patent >license process works is to require that a free software implementation >exists. I strongly believe it should be possible to participate on the >Internet without paying a software patent tax to some organizations. I believe you are arguing that the ends justify the means. In other words, because all the licensing has to be worked out (to become a DS), you believe a free implementation is the answer. I say it is not. Two commercial organizations can work out licensing and comply with this requirement - but you don't want that to be acceptable. I hold that this is what I'm referring to as "bad for the IETF" because corporations will either start involving themselves less in the IETF (directly affecting the IETF's revenue - which is already too low, and probably adversely affecting corporate sponsorship of meetings - which is already hard to acquire), and/or have fewer corporate participants care about DS and FS RFCs, because there is no incentive for them to do the work. BTW - if you believe a free (cost-wise) implementation be mandatory for elevation to DS, why don't you suggest the text be changed to say that? _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 30 15:12:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImwKi-0007o0-RQ; Tue, 30 Oct 2007 15:01:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImwKh-0007nv-81 for ietf@ietf.org; Tue, 30 Oct 2007 15:00:59 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImwKg-0005je-Q9 for ietf@ietf.org; Tue, 30 Oct 2007 15:00:59 -0400 X-IronPort-AV: E=Sophos;i="4.21,348,1188802800"; d="scan'208";a="183774600" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 30 Oct 2007 12:00:58 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9UJ0vIV014733; Tue, 30 Oct 2007 12:00:57 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l9UJ0kTk021567; Tue, 30 Oct 2007 19:00:46 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 12:00:43 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.17.26]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 12:00:42 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Oct 2007 14:00:42 -0500 To: Eliot Lear , Simon Josefsson From: "James M. Polk" In-Reply-To: <472704E0.7040202@cisco.com> References: <472704E0.7040202@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 30 Oct 2007 19:00:42.0753 (UTC) FILETIME=[2B7FCF10:01C81B27] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1915; t=1193770857; x=1194634857; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=202026,=20draft,=20full,=20etc. |Sender:=20; bh=IQeziHOmGE/ozmvcnh0BpRuyT3lCZt5a7HvaqjU6/tk=; b=ps1SYDAsnfU/3EJT7UxEBDq/UFm2tUFnKbptKIRY17bBMqZOVreGTaHa6+jh5PW1xzOpymcp 1wG8pEO5F1ApTdoZwW30mpsN50F0CBoK4h2gHGuTMqxPsz4WuCxrnwZ6; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: IETF Discussion Subject: Re: 2026, draft, full, etc. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 05:18 AM 10/30/2007, Eliot Lear wrote: >[I'm changing the subject and cutting off the references list as we seem >to have changed topic.] > >Simon, > > > DS designates a mature standard. If you read the requirements in RFC > > 2026 for a mature standard it is clear that few of the modern IETF > > protocols live up to that standard -- you need to demonstrate > > interoperability between two completely independent implementations of > > _all_ features in the protocol standard. > > >I think we can all agree that the calendaring standard is mature. We >are in the process of doing what I would consider to be a relatively >minor update to it, and yet it is only PS. IMAPv4 is only PS and yet >has MASSIVE deployment. LDAP is only PS and is MASSIVELY deployed. DHCP is the best (worse?) example of this, IMO. It's been DS (meaning at least 2 independent implementations) for how many years now (5, 6 or 8+ years)? It's (as you say) MASSIVELY deployed. Yet it isn't a Full STD. That one had always caused me to pause about how serious IETFers are really about 2026 processes... >SIP >is all over the place and it is only PS as well. And so it's pretty >clear that nobody cares about DS or IS. Actually some do care *AND* the IETF gets dinged on this one by those that aren't IETFers as not mature. These are the same (psst: idoits) that confuse Internet "Draft" with "Draft" Standard, somehow thinking each status is the same (...somehow). >What's more, why should they? >What benefit does it bring to anyone to advance a standard to DS? AND >it's a whole lot of work. > >So why are we even having an argument about what gets stuck into >requirements for DS? Shouldn't we instead be eliminating it entirely? > >Eliot > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 30 17:25:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImyNE-0001bI-V0; Tue, 30 Oct 2007 17:11:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImyNC-0001XU-RO for ietf@ietf.org; Tue, 30 Oct 2007 17:11:42 -0400 Received: from rv-out-0910.google.com ([209.85.198.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImyN1-0006YK-HK for ietf@ietf.org; Tue, 30 Oct 2007 17:11:37 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1822614rvb for ; Tue, 30 Oct 2007 14:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=BRu/EaSFq+KApENB+TG1MVkp6IU8Dz8gZ73xVi3/aPY=; b=uN6ouIbLmmOX1KR/VKm01gM9W4NDt7+SfQ7enF9Jy8w26Ni9WNO51t3xIujR3+7HNNSxEOCnnq3cY0Ije4hefCXmOlgHA8dRucifpOTI5c3+dq4pEax2EpQs/TJ7tK/g4BjFg0OjdVPaCfxhi2VlMiCWYKGldnEQnu4G4pNJ46Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=HZQji9KtLcTZAS4+4E70+0kTu/IbzlBPokSJO39ckT2dnKJJXJPQNjiZI79qJbg8MSXLZvlOrkGhr85NmVqQj0NWAApl3r/jV2/vj+yHhlT19RDzovyz1dHSX2g/2SuQw+RYAKDGG4l1yAozhkxu9hLqZHHJ0eoqp3/WZv9S/eA= Received: by 10.141.167.5 with SMTP id u5mr3591362rvo.1193778667891; Tue, 30 Oct 2007 14:11:07 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id c36sm13661174rvf.2007.10.30.14.11.06 (version=SSLv3 cipher=RC4-MD5); Tue, 30 Oct 2007 14:11:07 -0700 (PDT) Message-ID: <47279DE8.2000907@gmail.com> Date: Wed, 31 Oct 2007 10:11:04 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eliot Lear References: <472704E0.7040202@cisco.com> In-Reply-To: <472704E0.7040202@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: IETF Discussion , Simon Josefsson Subject: Re: 2026, draft, full, etc. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-10-30 23:18, Eliot Lear wrote: > [I'm changing the subject and cutting off the references list as we seem > to have changed topic.] > > Simon, > >> DS designates a mature standard. If you read the requirements in RFC >> 2026 for a mature standard it is clear that few of the modern IETF >> protocols live up to that standard -- you need to demonstrate >> interoperability between two completely independent implementations of >> _all_ features in the protocol standard. > > > I think we can all agree that the calendaring standard is mature. We > are in the process of doing what I would consider to be a relatively > minor update to it, and yet it is only PS. IMAPv4 is only PS and yet > has MASSIVE deployment. LDAP is only PS and is MASSIVELY deployed. SIP > is all over the place and it is only PS as well. And so it's pretty > clear that nobody cares about DS or IS. What's more, why should they? > What benefit does it bring to anyone to advance a standard to DS? AND > it's a whole lot of work. > > So why are we even having an argument about what gets stuck into > requirements for DS? Shouldn't we instead be eliminating it entirely? Well, as you know Eliot, we tested the IETF's enthusiasm for tackling that discussion a couple of years ago, and found it lacking. I continue to believe that to keep the "running code" goal alive, we need something like the PS to DS promotion available, but we need to change things to make it more attainable in practice. But if you want to see progress, you're going to have to show a measure of consensus to the General AD. Comments on draft-carpenter-rfc2026-changes-01.txt are welcome. Brian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 30 17:38:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imydm-0005DZ-08; Tue, 30 Oct 2007 17:28:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imydh-0005DH-N1 for ietf@ietf.org; Tue, 30 Oct 2007 17:28:45 -0400 Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImydZ-0007HX-Nb for ietf@ietf.org; Tue, 30 Oct 2007 17:28:45 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MN4YDX7O3K00FQ4K@mauve.mrochek.com> for ietf@ietf.org; Tue, 30 Oct 2007 14:28:16 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MN4W6BEQDS00BDC1@mauve.mrochek.com>; Tue, 30 Oct 2007 14:28:11 -0700 (PDT) Message-id: <01MN4YDVFDI400BDC1@mauve.mrochek.com> Date: Tue, 30 Oct 2007 13:35:41 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 30 Oct 2007 09:58:38 -0400" <6D007A8C-B397-458E-A9BD-F50F069ED73F@hxr.us> MIME-version: 1.0 Content-type: TEXT/PLAIN; delsp=yes; format=flowed References: <472388E9.8070700@gmail.com> <6D007A8C-B397-458E-A9BD-F50F069ED73F@hxr.us> To: Andrew Newton DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1193779694; h=Date: From:Subject:MIME-version:Content-type; b=hmY5aGYAfVRHEAhgYdVILB19o 3ce6xg2lspk2UECZo7R2oI//6E907xidULEkTwfSKqmgK79eFEpySOvQbH0jQ== X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ietf@ietf.org Subject: Re: Non-participants [Re: Experimental makes sense for tls-authz] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > > [By the way, when I find myself in a WG meeting I'm not prepared > > for, I often have my head buried in the drafts being discussed, > > so as to be able to understand the issues. Don't assume that a head > > buried in a laptop is always doing email.] > Has there been an assumption that these "non-participants" sending > email have not read the tls-authz draft? I'ts impossible to be sure given the lack of technical content in the comments in question, but given that the call for comments that appeared on the FSF site basically said "write in and voice your opposition to the publication of tls-authz" and did not mention actually reviewing the specification, it seems reasonable to be skeptical. And even if they have read tls-authz it is hard to take comments containing oxymorons like "experimental standard" very seriously, since such comments are a strong indicator of lack of familiarity with our process or 2026 criteria. > Again, I see no difference > between what is happening on this list vs. what would happen in a F2F > meeting, except that I've never witnessed a chair or AD say "Well, it > is obvious you guys are all non-participants and therefore your hums > will be ignored" in a F2F meeting. OTOH, I've seen plenty of F2F meetings where people were asked if they have actually read the draft and this information was definitely a factor in how things preceeded from there. > And I agree with Frank's point about these emails. They have been > unfairly classified as an "attack" or a DoS, perhaps to delegitimize > their content. And this episode doesn't really compare to previous > campaigns. I, OTOH, have to say that I agree with Scott Bradner's assessment that this is effectively a call to engage in censorship. > I agree that some of the content of the emails is nonsensical, but > the counter argument to them is that the document should be published > because the IETF process has a slot into which it will fit. Or in > other words, the IETF should publish it because it can. That does > not seem like a good enough reason. Speaking as someone who previously sent in a message saying I support publication of tls-authz as experimental, now you're the one being unfair. I _never_ voice support or opposition for a specification I have not read and tls-authz is no exception. (And I doubt very much I alone have this policy.) In fact as it happens I not only reviewed the specification I even managed to make it to a WG meeting where the document was discussed some time back - unusual for me given that I don't track TLS work all that closely. I will add that the criteria I use in evaluting documents vary depending on the status that is sought. In this specific case I actually think the document is close to being of sufficient quality and more thatn sufficient utility to be approved as proposed were it not for the patent issue. The concerns I would have raised had there been no patent issue and had this document tried for proposed standard have to do with the use of URLs to access "large" SAML assertions and X.509 ACs. I'm always leery of protocols that can cause an agent to silently dereference a URL outside of a user's control. I think the possibility that such access needs to be controlled in some way might deserve some mention in the security considerations section. I'm also unsure if the warning against the possibility of a circular reference (the x509_attr_cert_url or saml_assertion_url refer to a some URL which requires tls-authz support in order to dereference) is quite strong enough. But these concerns didn't seem sufficiently serious to require attention prior to publication as experimental. I believe the main concerns with experimental specifications should be (a) Whether or not things are clear enough for meaningful experimentation to take place and (b) Whether or not the experimentation has been defined in such a way that it won't interfere with existing standards-compliant usage or any other experiements. And in my view this specification easily meets both of these criteria. (I note in passing that in my view the sender-id and SPF experiments taken together fail to meet the last of these criteria and IMO should not have been published without first being modified so there's no chance of them interfering with each other.) The one thing I wasn't sure of and did check for tls-authz was the size of the ExtensionType field. Had that field been small I would have been concerned about this extension wasting a valuable "slot". But since this is a 16 bit field there's no shortage of values and I cannot get excited about the possibility of wasting one. Ned _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 30 19:43:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In0Qv-0007lf-Pm; Tue, 30 Oct 2007 19:23:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In0Qu-0007lW-W2 for ietf@ietf.org; Tue, 30 Oct 2007 19:23:41 -0400 Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In0Qu-0007Vx-Dk for ietf@ietf.org; Tue, 30 Oct 2007 19:23:40 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MN52EYDXB400EDGV@mauve.mrochek.com> for ietf@ietf.org; Tue, 30 Oct 2007 16:23:37 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MN4W6BEQDS00BDC1@mauve.mrochek.com>; Tue, 30 Oct 2007 16:23:32 -0700 (PDT) Message-id: <01MN52EVOC0000BDC1@mauve.mrochek.com> Date: Tue, 30 Oct 2007 16:02:44 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 30 Oct 2007 11:18:08 +0100" <472704E0.7040202@cisco.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=UTF-8 References: <472704E0.7040202@cisco.com> To: Eliot Lear DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1193786616; h=Date: From:Subject:MIME-version:Content-type; b=HwJuOac/gC73qxlpbi9GzQUUX Ov46RxPn7suokYC/QGwmepdUsc09iza4/CiEBytPPXZDlx2VxDF7xAoxp+s3Q== X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: IETF Discussion , Simon Josefsson Subject: Re: 2026, draft, full, etc. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org > [I'm changing the subject and cutting off the references list as we seem > to have changed topic.] > Simon, > > DS designates a mature standard. If you read the requirements in RFC > > 2026 for a mature standard it is clear that few of the modern IETF > > protocols live up to that standard -- you need to demonstrate > > interoperability between two completely independent implementations of > > _all_ features in the protocol standard. > I think we can all agree that the calendaring standard is mature. We > are in the process of doing what I would consider to be a relatively > minor update to it, and yet it is only PS. It is less clear, however, that all of its many features have been implemented interoperabiy. > IMAPv4 is only PS and yet has MASSIVE deployment. The main barrier to IMAP moving to draft is the large number of normative references that first need to move first. Getting RFC 2822 to draft is a necessary first step and we're working on that. But what about TLS? The now-widespread use of TLS+plain has solved a lot of problems for appplications but has created a serious obstacle to standards track advancement. Perhaps a downreference exception needs to be made here, but if so that needs to be approved in advance because nobody is going to bother going through all the pain of documenting interoperability without first being sure that a normative reference issue isn't going to render their work meaningless. > LDAP is only PS and is MASSIVELY deployed. I suspect the main issue is the same as for IMAP. > SIP > is all over the place and it is only PS as well. And so it's pretty > clear that nobody cares about DS or IS. I really don't think that's true. The problem is rather than people have (correctly IMO) assessed that while the benefits of DS are real they just aren't worth the cost. The question, then, is whether or not the cost can be lowered without compromising the status, and if so, how. My personal opinion is that major loosening of the downref rules as well as less nit-picking on feature lists would help a lot without damaging the brand in any significant way. > What's more, why should they? > What benefit does it bring to anyone to advance a standard to DS? AND > it's a whole lot of work. > So why are we even having an argument about what gets stuck into > requirements for DS? Shouldn't we instead be eliminating it entirely? I agree with Brian that this isn't the answer. But the current situation isn't right either. We need to focus on what's important, which is real world interoperability. Things have gotten too complex for a more exhaustive academic approach to be viable. Ned P.S. I actually started working on a feature checklist for RFC 3501 at one point but after looking at the issues with normative refrences I simply gave up. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 30 20:47:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1Wn-0002zP-Vt; Tue, 30 Oct 2007 20:33:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1Wm-0002vh-PK for ietf@ietf.org; Tue, 30 Oct 2007 20:33:48 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In1Wa-0006lF-Ef for ietf@ietf.org; Tue, 30 Oct 2007 20:33:43 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l9V0TNr1023826; Tue, 30 Oct 2007 17:29:23 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 17:32:32 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 30 Oct 2007 17:32:32 -0700 Message-ID: <2788466ED3E31C418E9ACC5C3166155707A79A@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Patents can be for good, not only evil Thread-Index: AcgaZ5Kx19fcSEWLSJa0rKtQKea0vQAB5DNgACEO2JA= From: "Hallam-Baker, Phillip" To: "Eric Burger" , "Keith Moore" , X-OriginalArrivalTime: 31 Oct 2007 00:32:32.0767 (UTC) FILETIME=[86CAD8F0:01C81B55] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: ietf@ietf.org Subject: RE: Patents can be for good, not only evil X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Phil's strategy here is not without issues. This was raised during the = W3C discussion when IBM pointed out at length that a license fee can be = considerably less of an inconvenience than certain Zero fee licenses. So for example a requirement that you can only implement a protocol = using Java (or chose your language). Or use certain cipher suites, or a = directory root controlled by the patent holder, or any number of similar = schemes. Defensive patents are certainly an acceptable practice, one that I would = like to see encouraged. At this point I believe that you would find 95% = of corporate patent lawyers at Internet companies would rank defending = against patent lawsuits as a much higher priority than recovering = revenue.=20 One of the problems I see here is that engineers can be dissuaded from = applying for defensive patents as doing so is likely to lead to them = being held up for ridicule on forums like Slashdot. This is particular = the case with defensive security patents which make claims against = specific attacks against a system. The point here being not to sell = products that implement the attack but to prevent others from doing so. =20 > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: Monday, October 29, 2007 5:16 PM > To: Keith Moore; lrosen@rosenlaw.com > Cc: ietf@ietf.org > Subject: Patents can be for good, not only evil >=20 > I would offer that patents are NOT categorically evil. >=20 > Phil Zimmerman has applied for patents in ZRTP, specifically=20 > to ensure that all implementations fully conform with the=20 > specification. Cost to license for a conformant=20 > specification? $0. Cost to not really provide privacy but=20 > claim to be implementing ZRTP? From ietf-bounces@ietf.org Tue Oct 30 20:47:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1Wn-0002zP-Vt; Tue, 30 Oct 2007 20:33:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1Wm-0002vh-PK for ietf@ietf.org; Tue, 30 Oct 2007 20:33:48 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In1Wa-0006lF-Ef for ietf@ietf.org; Tue, 30 Oct 2007 20:33:43 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l9V0TNr1023826; Tue, 30 Oct 2007 17:29:23 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 17:32:32 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 30 Oct 2007 17:32:32 -0700 Message-ID: <2788466ED3E31C418E9ACC5C3166155707A79A@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Patents can be for good, not only evil Thread-Index: AcgaZ5Kx19fcSEWLSJa0rKtQKea0vQAB5DNgACEO2JA= From: "Hallam-Baker, Phillip" To: "Eric Burger" , "Keith Moore" , X-OriginalArrivalTime: 31 Oct 2007 00:32:32.0767 (UTC) FILETIME=[86CAD8F0:01C81B55] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: ietf@ietf.org Subject: RE: Patents can be for good, not only evil X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Phil's strategy here is not without issues. This was raised during the = W3C discussion when IBM pointed out at length that a license fee can be = considerably less of an inconvenience than certain Zero fee licenses. So for example a requirement that you can only implement a protocol = using Java (or chose your language). Or use certain cipher suites, or a = directory root controlled by the patent holder, or any number of similar = schemes. Defensive patents are certainly an acceptable practice, one that I would = like to see encouraged. At this point I believe that you would find 95% = of corporate patent lawyers at Internet companies would rank defending = against patent lawsuits as a much higher priority than recovering = revenue.=20 One of the problems I see here is that engineers can be dissuaded from = applying for defensive patents as doing so is likely to lead to them = being held up for ridicule on forums like Slashdot. This is particular = the case with defensive security patents which make claims against = specific attacks against a system. The point here being not to sell = products that implement the attack but to prevent others from doing so. =20 > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: Monday, October 29, 2007 5:16 PM > To: Keith Moore; lrosen@rosenlaw.com > Cc: ietf@ietf.org > Subject: Patents can be for good, not only evil >=20 > I would offer that patents are NOT categorically evil. >=20 > Phil Zimmerman has applied for patents in ZRTP, specifically=20 > to ensure that all implementations fully conform with the=20 > specification. Cost to license for a conformant=20 > specification? $0. Cost to not really provide privacy but=20 > claim to be implementing ZRTP? Costly! >=20 > I specifically applied for patents underlying the technology=20 > behind RFC 4722/RFC 5022 and RFC 4730 specifically to prevent=20 > third parties, who are not part of the IETF process, from=20 > extracting royalties from someone who implements MSCML or=20 > KPML. Cost to license? $0. Cost to sue someone who=20 > infringes said third-party's IPR? That depends, but at least=20 > we raised the cost of shutting down an IETF standard. >=20 > Remember, just because *you* do not have IPR in an IETF=20 > standard does not mean someone *else* has IPR in the=20 > standard. If that someone else does not participate in the=20 > IETF or, for that matter, happen to not participate in the=20 > work group or, in reality, are not editors of a document,=20 > they can fully apply their IPR against the standard once it issues. >=20 > I like to have a little inoculation against that situation in=20 > the stuff I submit. >=20 > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Monday, October 29, 2007 4:04 PM > To: lrosen@rosenlaw.com > Cc: ietf@ietf.org > Subject: Re: When is using patented technology appropriate? >=20 > Lawrence Rosen wrote: > > Keith Moore wrote: > > =20 > >> For several reasons, it is difficult to imagine an IETF-wide=20 > >> procedure that allows the existence of a patent to trump other=20 > >> considerations of protocol feasibility and deployability: > >> =20 > > > > Who suggested otherwise? It is not the existence of the patent that=20 > > matters, but its unavailability under license terms that allow=20 > > implementation in > > *any* software. > > =20 > _and_ its validity, _and_ its applicability, both of which=20 > can be subjective and difficult to determine conclusively=20 > without long delays > and excessive expense. so we have to make judgments. and by "we" I > mean individuals participating in IETF, not IETF itself. > > The more feasible and deployable the protocol, the more=20 > important will >=20 > > be FOSS implementations. > > =20 > only relative to other protocols in the same space. >=20 > granted that patents are the bane of any open=20 > standards-making organization, because patents do exactly the=20 > opposite of what open standards do. at the same time, we=20 > can't let FUD about patents become a denial of service attack=20 > to IETF efforts. >=20 > Keith >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 30 20:47:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1Wa-0002rR-1i; Tue, 30 Oct 2007 20:33:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1WY-0002pZ-OF for ietf@ietf.org; Tue, 30 Oct 2007 20:33:34 -0400 Received: from robin.verisign.com ([65.205.251.75]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In1WJ-0001Wz-6z for ietf@ietf.org; Tue, 30 Oct 2007 20:33:19 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l9V0TOhh023829; Tue, 30 Oct 2007 17:29:24 -0700 Received: fromCostly! >=20 > I specifically applied for patents underlying the technology=20 > behind RFC 4722/RFC 5022 and RFC 4730 specifically to prevent=20 > third parties, who are not part of the IETF process, from=20 > extracting royalties from someone who implements MSCML or=20 > KPML. Cost to license? $0. Cost to sue someone who=20 > infringes said third-party's IPR? That depends, but at least=20 > we raised the cost of shutting down an IETF standard. >=20 > Remember, just because *you* do not have IPR in an IETF=20 > standard does not mean someone *else* has IPR in the=20 > standard. If that someone else does not participate in the=20 > IETF or, for that matter, happen to not participate in the=20 > work group or, in reality, are not editors of a document,=20 > they can fully apply their IPR against the standard once it issues. >=20 > I like to have a little inoculation against that situation in=20 > the stuff I submit. >=20 > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Monday, October 29, 2007 4:04 PM > To: lrosen@rosenlaw.com > Cc: ietf@ietf.org > Subject: Re: When is using patented technology appropriate? >=20 > Lawrence Rosen wrote: > > Keith Moore wrote: > > =20 > >> For several reasons, it is difficult to imagine an IETF-wide=20 > >> procedure that allows the existence of a patent to trump other=20 > >> considerations of protocol feasibility and deployability: > >> =20 > > > > Who suggested otherwise? It is not the existence of the patent that=20 > > matters, but its unavailability under license terms that allow=20 > > implementation in > > *any* software. > > =20 > _and_ its validity, _and_ its applicability, both of which=20 > can be subjective and difficult to determine conclusively=20 > without long delays > and excessive expense. so we have to make judgments. and by "we" I > mean individuals participating in IETF, not IETF itself. > > The more feasible and deployable the protocol, the more=20 > important will >=20 > > be FOSS implementations. > > =20 > only relative to other protocols in the same space. >=20 > granted that patents are the bane of any open=20 > standards-making organization, because patents do exactly the=20 > opposite of what open standards do. at the same time, we=20 > can't let FUD about patents become a denial of service attack=20 > to IETF efforts. >=20 > Keith >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Tue Oct 30 20:47:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1Wa-0002rR-1i; Tue, 30 Oct 2007 20:33:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1WY-0002pZ-OF for ietf@ietf.org; Tue, 30 Oct 2007 20:33:34 -0400 Received: from robin.verisign.com ([65.205.251.75]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In1WJ-0001Wz-6z for ietf@ietf.org; Tue, 30 Oct 2007 20:33:19 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l9V0TOhh023829; Tue, 30 Oct 2007 17:29:24 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 17:32:33 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 30 Oct 2007 17:32:33 -0700 Message-ID: <2788466ED3E31C418E9ACC5C3166155707A79B@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <472704E0.7040202@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 2026, draft, full, etc. Thread-Index: Acga37GbKxyiuc/1Rc+rvnSxDa+RFAAFQuyQ From: "Hallam-Baker, Phillip" To: "Eliot Lear" , "Simon Josefsson" X-OriginalArrivalTime: 31 Oct 2007 00:32:33.0971 (UTC) FILETIME=[87829030:01C81B55] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: IETF Discussion Subject: RE: 2026, draft, full, etc. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0428526646==" Errors-To: ietf-bounces@ietf.org --===============0428526646== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSwgYnV0IG9ubHkgcGFydGx5Lg0KDQpBIHNlY29uZCBwYXNzIG9uIHRoZSBkb2N1bWVu dHMgZG9lcyBoYXZlIGEgYmVuZWZpY2lhbCBlZmZlY3QuIFRoaXMgaXMgcGFydGljdWxhcmx5IHRo ZSBjYXNlIGZvciBvbGRlciAnc3RhbmRhcmRzJyB3aGVyZSB0aGUgZG9jdW1lbnRzIHNpbXBseSBk b24ndCBtYXRjaCBjdXJyZW50IHJlcXVpcmVtZW50cyAobm8gc2VjdXJpdHksIGlhbmEgY29uc2lk ZXJhdGlvbnMgZm9yIGEgc3RhcnQpIGFuZCBhcmUgb2Z0ZW4gbWlzc2luZyBrZXkgZm9sa2xvcmUg ZXNzZW50aWFsIGZvciBpbnRlcm9wZXJhYmlsaXR5Lg0KDQoNCldoZXJlIEkgdGhpbmsgdGhlIHBy b2Nlc3MgZ29lcyB3cm9uZyBpcyB0aGF0IGl0IGFwcGxpZXMgdG8gZG9jdW1lbnRzLCBub3QgcHJv dG9jb2xzLiBBIGxvdCBvZiBjcnVkIGdvZXMgdGhyb3VnaCB0aGUgbWlsbCBpbiB0aGUgbmFtZSBv ZiBhdm9pZGluZyByZWN5Y2xpbmcgYXQgcHJvcG9zZWQuIEFuZCB3aGVuIGEgbWFqb3IgcmV2aXNp b24gb2YgYW4gZXhpc3RpbmcgcHJvdG9jb2wgaXMgZG9uZSB0aGUgcmV2aXNpb24gZ29lcyBiYWNr IHRvIHByb3Bvc2VkIGJlZm9yZSBiZWluZyBwcm9taXRlZCB0byBkcmFmdC4NCiANCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBFbGlvdCBMZWFyIFttYWlsdG86bGVhckBj aXNjby5jb21dIA0KPiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDMwLCAyMDA3IDY6MTggQU0NCj4g VG86IFNpbW9uIEpvc2Vmc3Nvbg0KPiBDYzogSUVURiBEaXNjdXNzaW9uDQo+IFN1YmplY3Q6IDIw MjYsIGRyYWZ0LCBmdWxsLCBldGMuDQo+IA0KPiBbSSdtIGNoYW5naW5nIHRoZSBzdWJqZWN0IGFu ZCBjdXR0aW5nIG9mZiB0aGUgcmVmZXJlbmNlcyBsaXN0IA0KPiBhcyB3ZSBzZWVtIHRvIGhhdmUg Y2hhbmdlZCB0b3BpYy5dDQo+IA0KPiBTaW1vbiwNCj4gDQo+ID4gRFMgZGVzaWduYXRlcyBhIG1h dHVyZSBzdGFuZGFyZC4gIElmIHlvdSByZWFkIHRoZSANCj4gcmVxdWlyZW1lbnRzIGluIFJGQw0K PiA+IDIwMjYgZm9yIGEgbWF0dXJlIHN0YW5kYXJkIGl0IGlzIGNsZWFyIHRoYXQgZmV3IG9mIHRo ZSBtb2Rlcm4gSUVURiANCj4gPiBwcm90b2NvbHMgbGl2ZSB1cCB0byB0aGF0IHN0YW5kYXJkIC0t IHlvdSBuZWVkIHRvIGRlbW9uc3RyYXRlIA0KPiA+IGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiB0 d28gY29tcGxldGVseSBpbmRlcGVuZGVudCANCj4gaW1wbGVtZW50YXRpb25zIG9mIA0KPiA+IF9h bGxfIGZlYXR1cmVzIGluIHRoZSBwcm90b2NvbCBzdGFuZGFyZC4NCj4gDQo+IA0KPiBJIHRoaW5r IHdlIGNhbiBhbGwgYWdyZWUgdGhhdCB0aGUgY2FsZW5kYXJpbmcgc3RhbmRhcmQgaXMgDQo+IG1h dHVyZS4gIFdlIGFyZSBpbiB0aGUgcHJvY2VzcyBvZiBkb2luZyB3aGF0IEkgd291bGQgY29uc2lk ZXIgDQo+IHRvIGJlIGEgcmVsYXRpdmVseSBtaW5vciB1cGRhdGUgdG8gaXQsIGFuZCB5ZXQgaXQg aXMgb25seSBQUy4gDQo+ICBJTUFQdjQgaXMgb25seSBQUyBhbmQgeWV0IGhhcyBNQVNTSVZFIGRl cGxveW1lbnQuICBMREFQIGlzIA0KPiBvbmx5IFBTIGFuZCBpcyBNQVNTSVZFTFkgZGVwbG95ZWQu ICBTSVAgaXMgYWxsIG92ZXIgdGhlIHBsYWNlIA0KPiBhbmQgaXQgaXMgb25seSBQUyBhcyB3ZWxs LiAgQW5kIHNvIGl0J3MgcHJldHR5IGNsZWFyIHRoYXQgDQo+IG5vYm9keSBjYXJlcyBhYm91dCBE UyBvciBJUy4gIFdoYXQncyBtb3JlLCB3aHkgc2hvdWxkIHRoZXk/IA0KPiBXaGF0IGJlbmVmaXQg ZG9lcyBpdCBicmluZyB0byBhbnlvbmUgdG8gYWR2YW5jZSBhIHN0YW5kYXJkIHRvIA0KPiBEUz8g IEFORCBpdCdzIGEgd2hvbGUgbG90IG9mIHdv MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 17:32:33 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 30 Oct 2007 17:32:33 -0700 Message-ID: <2788466ED3E31C418E9ACC5C3166155707A79B@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <472704E0.7040202@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 2026, draft, full, etc. Thread-Index: Acga37GbKxyiuc/1Rc+rvnSxDa+RFAAFQuyQ From: "Hallam-Baker, Phillip" To: "Eliot Lear" , "Simon Josefsson" X-OriginalArrivalTime: 31 Oct 2007 00:32:33.0971 (UTC) FILETIME=[87829030:01C81B55] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: IETF Discussion Subject: RE: 2026, draft, full, etc. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0428526646==" Errors-To: ietf-bounces@ietf.org --===============0428526646== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSwgYnV0IG9ubHkgcGFydGx5Lg0KDQpBIHNlY29uZCBwYXNzIG9uIHRoZSBkb2N1bWVu dHMgZG9lcyBoYXZlIGEgYmVuZWZpY2lhbCBlZmZlY3QuIFRoaXMgaXMgcGFydGljdWxhcmx5IHRo ZSBjYXNlIGZvciBvbGRlciAnc3RhbmRhcmRzJyB3aGVyZSB0aGUgZG9jdW1lbnRzIHNpbXBseSBk b24ndCBtYXRjaCBjdXJyZW50IHJlcXVpcmVtZW50cyAobm8gc2VjdXJpdHksIGlhbmEgY29uc2lk ZXJhdGlvbnMgZm9yIGEgc3RhcnQpIGFuZCBhcmUgb2Z0ZW4gbWlzc2luZyBrZXkgZm9sa2xvcmUg ZXNzZW50aWFsIGZvciBpbnRlcm9wZXJhYmlsaXR5Lg0KDQoNCldoZXJlIEkgdGhpbmsgdGhlIHBy b2Nlc3MgZ29lcyB3cm9uZyBpcyB0aGF0IGl0IGFwcGxpZXMgdG8gZG9jdW1lbnRzLCBub3QgcHJv dG9jb2xzLiBBIGxvdCBvZiBjcnVkIGdvZXMgdGhyb3VnaCB0aGUgbWlsbCBpbiB0aGUgbmFtZSBv ZiBhdm9pZGluZyByZWN5Y2xpbmcgYXQgcHJvcG9zZWQuIEFuZCB3aGVuIGEgbWFqb3IgcmV2aXNp b24gb2YgYW4gZXhpc3RpbmcgcHJvdG9jb2wgaXMgZG9uZSB0aGUgcmV2aXNpb24gZ29lcyBiYWNr IHRvIHByb3Bvc2VkIGJlZm9yZSBiZWluZyBwcm9taXRlZCB0byBkcmFmdC4NCiANCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBFbGlvdCBMZWFyIFttYWlsdG86bGVhckBj aXNjby5jb21dIA0KPiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDMwLCAyMDA3IDY6MTggQU0NCj4g VG86IFNpbW9uIEpvc2Vmc3Nvbg0KPiBDYzogSUVURiBEaXNjdXNzaW9uDQo+IFN1YmplY3Q6IDIw MjYsIGRyYWZ0LCBmdWxsLCBldGMuDQo+IA0KPiBbSSdtIGNoYW5naW5nIHRoZSBzdWJqZWN0IGFu ZCBjdXR0aW5nIG9mZiB0aGUgcmVmZXJlbmNlcyBsaXN0IA0KPiBhcyB3ZSBzZWVtIHRvIGhhdmUg Y2hhbmdlZCB0b3BpYy5dDQo+IA0KPiBTaW1vbiwNCj4gDQo+ID4gRFMgZGVzaWduYXRlcyBhIG1h dHVyZSBzdGFuZGFyZC4gIElmIHlvdSByZWFkIHRoZSANCj4gcmVxdWlyZW1lbnRzIGluIFJGQw0K PiA+IDIwMjYgZm9yIGEgbWF0dXJlIHN0YW5kYXJkIGl0IGlzIGNsZWFyIHRoYXQgZmV3IG9mIHRo ZSBtb2Rlcm4gSUVURiANCj4gPiBwcm90b2NvbHMgbGl2ZSB1cCB0byB0aGF0IHN0YW5kYXJkIC0t IHlvdSBuZWVkIHRvIGRlbW9uc3RyYXRlIA0KPiA+IGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiB0 d28gY29tcGxldGVseSBpbmRlcGVuZGVudCANCj4gaW1wbGVtZW50YXRpb25zIG9mIA0KPiA+IF9h bGxfIGZlYXR1cmVzIGluIHRoZSBwcm90b2NvbCBzdGFuZGFyZC4NCj4gDQo+IA0KPiBJIHRoaW5r IHdlIGNhbiBhbGwgYWdyZWUgdGhhdCB0aGUgY2FsZW5kYXJpbmcgc3RhbmRhcmQgaXMgDQo+IG1h dHVyZS4gIFdlIGFyZSBpbiB0aGUgcHJvY2VzcyBvZiBkb2luZyB3aGF0IEkgd291bGQgY29uc2lk ZXIgDQo+IHRvIGJlIGEgcmVsYXRpdmVseSBtaW5vciB1cGRhdGUgdG8gaXQsIGFuZCB5ZXQgaXQg aXMgb25seSBQUy4gDQo+ICBJTUFQdjQgaXMgb25seSBQUyBhbmQgeWV0IGhhcyBNQVNTSVZFIGRl cGxveW1lbnQuICBMREFQIGlzIA0KPiBvbmx5IFBTIGFuZCBpcyBNQVNTSVZFTFkgZGVwbG95ZWQu ICBTSVAgaXMgYWxsIG92ZXIgdGhlIHBsYWNlIA0KPiBhbmQgaXQgaXMgb25seSBQUyBhcyB3ZWxs LiAgQW5kIHNvIGl0J3MgcHJldHR5IGNsZWFyIHRoYXQgDQo+IG5vYm9keSBjYXJlcyBhYm91dCBE UyBvciBJUy4gIFdoYXQncyBtb3JlLCB3aHkgc2hvdWxkIHRoZXk/IA0KPiBXaGF0IGJlbmVmaXQg ZG9lcyBpdCBicmluZyB0byBhbnlvbmUgdG8gYWR2YW5jZSBhIHN0YW5kYXJkIHRvIA0KPiBEUz8g IEFORCBpdCdzIGEgd2hvbGUgbG90IG9mIHdvcmsuDQo+IA0KPiBTbyB3aHkgYXJlIHdlIGV2ZW4g aGF2aW5nIGFuIGFyZ3VtZW50IGFib3V0IHdoYXQgZ2V0cyBzdHVjayANCj4gaW50byByZXF1aXJl bWVudHMgZm9yIERTPyAgU2hvdWxkbid0IHdlIGluc3RlYWQgYmUgDQo+IGVsaW1pbmF0aW5nIGl0 IGVudGlyZWx5Pw0KPiANCj4gRWxpb3QNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IElldGYgbWFpbGluZyBsaXN0DQo+IElldGZAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWV0Zg0KPiANCg== --===============0428526646== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0428526646==-- cmsuDQo+IA0KPiBTbyB3aHkgYXJlIHdlIGV2ZW4g aGF2aW5nIGFuIGFyZ3VtZW50IGFib3V0IHdoYXQgZ2V0cyBzdHVjayANCj4gaW50byByZXF1aXJl bWVudHMgZm9yIERTPyAgU2hvdWxkbid0IHdlIGluc3RlYWQgYmUgDQo+IGVsaW1pbmF0aW5nIGl0 IGVudGlyZWx5Pw0KPiANCj4gRWxpb3QNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IElldGYgbWFpbGluZyBsaXN0DQo+IElldGZAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWV0Zg0KPiANCg== --===============0428526646== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0428526646==-- From ietf-bounces@ietf.org Wed Oct 31 04:26:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In8Xs-0000kT-8b; Wed, 31 Oct 2007 04:03:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In8Xq-0000kJ-05 for ietf@ietf.org; Wed, 31 Oct 2007 04:03:22 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In8Xi-0006iD-15 for ietf@ietf.org; Wed, 31 Oct 2007 04:03:21 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1In8XK-0008Sp-T3 for ietf@ietf.org; Wed, 31 Oct 2007 08:02:50 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Oct 2007 08:02:50 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Oct 2007 08:02:50 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: "Frank Ellermann" Date: Wed, 31 Oct 2007 08:59:50 +0100 Lines: 40 Message-ID: References: <472388E9.8070700@gmail.com><6D007A8C-B397-458E-A9BD-F50F069ED73F@hxr.us> <01MN4YDVFDI400BDC1@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: Re: Non-participants X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Ned Freed wrote: > the FSF site basically said "write in and voice your opposition to > the publication of tls-authz" and did not mention actually reviewing > the specification, it seems reasonable to be skeptical. Yes. That's of course not the same as dismissing all contributions in this thread as nonsense, e.g. one author writing on behalf of FIFF. And it already resulted in constructive proposals like Brian's draft. > I agree with Scott Bradner's assessment that this is effectively a > call to engage in censorship. Maybe the IESG could add one of its (in)famous "notes" to the memo, the day before yesterday I stumbled over RFC 3974 mentioned in the 2821bis draft. > I believe the main concerns with experimental specifications should be > (a) Whether or not things are clear enough for meaningful=20 > experimentation to take place and=20 > (b) Whether or not the experimentation has been defined in such a way > that it won't interfere with existing standards-compliant usage or > any other experiements.=20 > And in my view this specification easily meets both of these criteria. > (I note in passing that in my view the sender-id and SPF experiments > taken together fail to meet the last of these criteria and IMO should > not have been published without first being modified so there's no=20 > chance of them interfering with each other.) Unfortunately the IAB decreed that it's no problem when the sender-id experiment gets an IESG "note" stating that it does interfere with existing standards, will never enter standards track as is, and tries an unfriendly takeover of SPF. That means if an experiment tries the stunt to say "update MIME" it=20 would be a waste of time to ask the IAB what they think about it. They'd say "experiments are experiments, nobody really cares" :-( Frank _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 31 05:38:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In9kj-0000Jx-QD; Wed, 31 Oct 2007 05:20:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In9ki-0000Jm-Gg for ietf@ietf.org; Wed, 31 Oct 2007 05:20:44 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In9kh-0002ST-QU for ietf@ietf.org; Wed, 31 Oct 2007 05:20:44 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1In9kb-0001pT-G7 for ietf@ietf.org; Wed, 31 Oct 2007 09:20:37 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Oct 2007 09:20:37 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Oct 2007 09:20:37 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: "Frank Ellermann" Date: Wed, 31 Oct 2007 10:17:01 +0100 Lines: 73 Message-ID: References: <472704E0.7040202@cisco.com> <47279DE8.2000907@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: Re: 2026, draft, full, etc. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Brian E Carpenter wrote: > Comments on draft-carpenter-rfc2026-changes-01.txt are welcome. | Formally abolishing the now pointless "STD 1" RFCs. NAK - I hope we get a new STD 1 soon, ideally after 4234bis got its STD number. | The IETF will not normally modify protocols developed elsewhere, IMO the IETF must be able to adopt specific versions of a standard developed elsewhere. E.g. UTF-8 is what STD 63 says, it can't be modified "elsewhere". | It would be much less confusing if a new or existing acronym was=20 | assigned as part of the initial standards action (thus RFC 2821=20 | would have been associated with SMTP). IMO more with ESMTP than with SMTP, I think you need a better example here. | Similarly, the STD number should be assigned at PS stage for | simpler tracking - thus RFC 2821 would also be known as PS10, | for example.=20 NAK, adding a "PS10" alias to "RFC 2821" doesn't help. Many PS don't deserve a separate STD number, unless they actually make it to this level. Some PS even don't need a nice acronym. It might be different when a PS tries to update an existing STD, as it's the case for RFC 2821. | Rename PS as Preliminary Standard. Some PS really are "proposed standards" as defined in 2026, i.e. "immature specifications". Or mature protocols where the specification needs a thorough cleanup, e.g. RFC 2616. [2026] | A standards action is initiated [...] | in the case of a specification not associated with a Working Group, a | recommendation by an individual to the IESG. [your text] | A standards action is initiated [...] | in the case of a specification not associated with a Working Group, an | agreement by an Area Director to recommend a specification to the | IESG. The IESG is empowered to define the procedures for this. | RATIONALE: Aligning with reality. JFTR, in reality I used the "recommendation by an individual" loophole in two cases, for 4234bis and Archived-At.=20 We had a similar debate about the shepherd-ION some months ago. I need an appealable offense if the IESG refuses a "standards action"=20 for frivolous reasons. The RFC 2026 text offers this, I'm not sure about your text. | Remove the reference to gopher. Sigh. I kind of like RFC 4266, is that "PS gopher" in your terminology = ? | Add a note that the RFC Editor maintains errata for published RFCs. Also add a note that they maintain a pending errata mailbox with a submission from February 2005 waiting for publication. Frank _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 31 07:37:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InBgB-0004cm-TF; Wed, 31 Oct 2007 07:24:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InBg9-0004cX-Ev for ietf@ietf.org; Wed, 31 Oct 2007 07:24:09 -0400 Received: from mail.sfc.wide.ad.jp ([2001:200:0:8803:203:47ff:fedf:73a6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InBg7-0007rz-Gs for ietf@ietf.org; Wed, 31 Oct 2007 07:24:09 -0400 Received: from [192.168.0.4] (6.122.30.125.dy.iij4u.or.jp [125.30.122.6]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 4F2B94DB0A; Wed, 31 Oct 2007 20:23:50 +0900 (JST) Message-ID: <472865A8.1060506@wide.ad.jp> Date: Wed, 31 Oct 2007 20:23:20 +0900 From: Jun Murai User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ietf@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: Dr. JunIchiro 'Itojun' Hagino X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Dear IETF Friends, I am regretful to pass along the sad news that Itojun (Dr. Junichiro Hagino) passed away on October 29, 2007. He was 37 years old. The WIDE community would like to send our condolences to his family and friends. Itojun has been an important member of the Internet commmunity such as IETF/IAB and WIDE project, making numerous worldwide contributions in the field of network computing, especially on KAME/IPv6 and the Internet protocol area. He has had an important influence on each of our experiences in the WIDE project, IETF, and on the Internet community. We will miss him terribly. The family is planning a memorial service at Rinkai Saijo (Tokyo, Japan http://www.rinkaisaijo.or.jp/info/index.html) on November 6th from 6:00pm, and a funeral service the following day on November 7th from 11:00am. We have received warm requests from many wishing if they can be of any help. We are presently coordinating efforts with Itojun's family to see how we may be of assistance during this difficult time. On behalf of the Internet community we will be arranging for flowers to be sent, but as many of Itojun's close colleagues may be overseas, we understand it may be difficult to attend or arrange for flowers from abroad. As an alternative suggestion we would like to accept warm messages to the family and/or memorable events with Itojun that you may want to share. We will deliver these messages to Itojun at the memorial and funeral service. Please send these messages to message_for_itojun@wide.ad.jp. Our deepest sympathies are with Itojun's family for this loss. As a community, I hope we can come together and support one another in fondly remembering Itojun. Jun Murai On behalf of WIDE Project _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 31 07:37:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InBdW-0003mS-0v; Wed, 31 Oct 2007 07:21:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InBdT-0003mJ-TW for ietf@ietf.org; Wed, 31 Oct 2007 07:21:23 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InBdT-0007iE-LC for ietf@ietf.org; Wed, 31 Oct 2007 07:21:23From ietf-bounces@ietf.org Wed Oct 31 07:37:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InBgB-0004cm-TF; Wed, 31 Oct 2007 07:24:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InBg9-0004cX-Ev for ietf@ietf.org; Wed, 31 Oct 2007 07:24:09 -0400 Received: from mail.sfc.wide.ad.jp ([2001:200:0:8803:203:47ff:fedf:73a6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InBg7-0007rz-Gs for ietf@ietf.org; Wed, 31 Oct 2007 07:24:09 -0400 Received: from [192.168.0.4] (6.122.30.125.dy.iij4u.or.jp [125.30.122.6]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 4F2B94DB0A; Wed, 31 Oct 2007 20:23:50 +0900 (JST) Message-ID: <472865A8.1060506@wide.ad.jp> Date: Wed, 31 Oct 2007 20:23:20 +0900 From: Jun Murai User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ietf@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: Dr. JunIchiro 'Itojun' Hagino X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Dear IETF Friends, I am regretful to pass along the sad news that Itojun (Dr. Junichiro Hagino) passed away on October 29, 2007. He was 37 years old. The WIDE community would like to send our condolences to his family and friends. Itojun has been an important member of the Internet commmunity such as IETF/IAB and WIDE project, making numerous worldwide contributions in the field of network computing, especially on KAME/IPv6 and the Internet protocol area. He has had an important influence on each of our experiences in the WIDE project, IETF, and on the Internet community. We will miss him terribly. The family is planning a memorial service at Rinkai Saijo (Tokyo, Japan http://www.rinkaisaijo.or.jp/info/index.html) on November 6th from 6:00pm, and a funeral service the following day on November 7th from 11:00am. We have received warm requests from many wishing if they can be of any help. We are presently coordinating efforts with Itojun's family to see how we may be of assistance during this difficult time. On behalf of the Internet community we will be arranging for flowers to be sent, but as many of Itojun's close colleagues may be overseas, we understand it may be difficult to attend or arrange for flowers from abroad. As an alternative suggestion we would like to accept warm messages to the family and/or memorable events with Itojun that you may want to share. We will deliver these messages to Itojun at the memorial and funeral service. Please send these messages to message_for_itojun@wide.ad.jp. Our deepest sympathies are with Itojun's family for this loss. As a community, I hope we can come together and support one another in fondly remembering Itojun. Jun Murai On behalf of WIDE Project _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 31 07:37:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InBdW-0003mS-0v; Wed, 31 Oct 2007 07:21:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InBdT-0003mJ-TW for ietf@ietf.org; Wed, 31 Oct 2007 07:21:23 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InBdT-0007iE-LC for ietf@ietf.org; Wed, 31 Oct 2007 07:21:23 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 427BB4A47; Wed, 31 Oct 2007 07:21:23 -0400 (EDT) From: Sam Hartman To: ietf@ietf.org Cc: References: Date: Wed, 31 Oct 2007 07:21:23 -0400 In-Reply-To: (The IESG's message of "Mon, 08 Oct 2007 09:28:58 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: Re: Last Call: draft-ietf-xcon-framework (A Framework for Centralized Conferencing) to Proposed Standard X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I'd like to draw the attention of the IETF community to this document. It seems hugely complex. I'd like to ask those not involved in the xcon working group to take time to read it and to consider whether this complexity is necessary. I'd particularly like to ask people to consider section 9. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 427BB4A47; Wed, 31 Oct 2007 07:21:23 -0400 (EDT) From: Sam Hartman To: ietf@ietf.org Cc: References: Date: Wed, 31 Oct 2007 07:21:23 -0400 In-Reply-To: (The IESG's message of "Mon, 08 Oct 2007 09:28:58 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: Re: Last Call: draft-ietf-xcon-framework (A Framework for Centralized Conferencing) to Proposed Standard X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I'd like to draw the attention of the IETF community to this document. It seems hugely complex. I'd like to ask those not involved in the xcon working group to take time to read it and to consider whether this complexity is necessary. I'd particularly like to ask people to consider section 9. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 31 12:00:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InFfk-0006Ey-MJ; Wed, 31 Oct 2007 11:40:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InFfj-000652-W2 for ietf@ietf.org; Wed, 31 Oct 2007 11:39:59 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InFfU-00042D-Dn for ietf@ietf.org; Wed, 31 Oct 2007 11:39:50 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l9VFZ74c031363; Wed, 31 Oct 2007 08:35:07 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Oct 2007 08:38:46 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 31 Oct 2007 08:38:45 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557084F23@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Patents can be for good, not only evil Thread-Index: Acga/Pig8/NbCMT3RTejDItHgVUa+gAz472w References: <2788466ED3E31C418E9ACC5C31661557084EE8@mou1wnexmb09.vcorp.ad.vrsn.com><471A5668.8060505@gmail.com><048d01c81388$5230a9a0$6401a8c0@LROSENTOSHIBA><20071022195723.4D9A22202DA@quill.bollow.ch><20071023105651.8D9AC2202DA@quill.bollow.ch><87abqa2i1z.fsf@mocca.josefsson.org><871wbm2cze.fsf@mocca.josefsson.org><87fy00vn1l.fsf@mocca.josefsson.org><471FB60B.3070304@gmail.com><20071024214601.28e866ce@cs.columbia.edu><00d801c81689$f64c5f30$6401a8c0@LROSENTOSHIBA><4720FCFA.7080009@cs.utk.edu><020d01c81a62$8a7d6510$6401a8c0@LROSENTOSHIBA><47263C98! .6080703@cs.utk.edu><022d01c81a7f$bd063ad0$6401a8c0@LROSENTOSHIBA><20071029234911.0f1e8d80@cs.columbia.edu><023701c81a8f$4f180980$6401a8c0@LR! OSENTOSHI BA> <77F3A8A0C26D068BE6DB457B@B50854F0A9192E8EC6CDA126> From: "Hallam-Baker, Phillip" To: "Harald Tveit Alvestrand" , , X-OriginalArrivalTime: 31 Oct 2007 15:38:46.0226 (UTC) FILETIME=[1FE64320:01C81BD4] X-Spam-Score: -2.2 (--) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: Subject: RE: Patents can be for good, not only evil X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2064752851==" Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============2064752851== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81BD4.1FACE515" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81BD4.1FACE515 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How many Working Group participants who vent on patent issues have read = RFC 3669? =20 Of those who have read it, how many consider it to be binding? =20 All RFC 3669 does is to allow endless discussion of topics that most WGs = do not consider core. They may be important considerations but the = Working Groups themselves are the wrong place to do design work in the = IPR space. =20 Very few Working Group participants have any real interest or = understanding of the patent system other than to wish it would go away. = The most likely reason a WG participant would have detailed knowedge is = if they were an unwilling participant in a patent lawsuit or had a = proposal shot down because some group of lawyers objected to the IPR = terms (both have happend to me).=20 =20 The bulk of the opinions expressed might be characterized as ideological = rather than informed. So what we get as a result is not a useful = discussion, its more like a slashdot flamewa =20 Its not productive discussion, the arguments are entirely repetative. =20 Eliminating repetative, unproductive arguments is the function of the = charter. We write charters that rule technical issues such as designing = a new PKI, Web Services transport layer, cryptographic algorithm, &ct = &ct out of scope. So why not rule the IPR question out of scope at the = charter stage unlss there is a specific reason to beleive that a WG = would need to deal with it? =20 A charter statement is never the final word, WGs discover that their = charter needs changing all the time. If a group discovers that there are = unforseen IPR issues it cannot resolve it has the choice of disbanding = without a recommendation, rechartering or making non standards track = submissions. =20 Understanding the IPR landscape is one of the things I always try to do = before starting or joining a group. IPR is always a BOF topic. It is not = that we don't discuss in advance. In fact in many cases the whole raison = d'etre for the group is to create an unencumbered standard to replace a = proprietary protocol. =20 For example, take a look at the Ford-Wienner key management patent which = is due to expire at some point in the not so distant future. The = invention describes a lightweight CRM scheme. I can well imagine that = someone might want to start a working group to produce an unencumbered = CRM protocol based on Ford-Wienner and S/MIME. The whole point of = chartering a group of that type would be to produce a RANDZ protocol and = so it should be stated in the charter. =20 =20 I don't think that there are many cases where a non RANDZ IPR clause is = going to fly. About the only one I can think of offhand would be that we = are comming to a situation where ECC crypto is becomming seen as = necessary for certain applications. There are credible IPR claims to at = least some methods of performing ECC crypto. There are certainly parties = that see a need to deploy ECC before the IPR encumberances expire. =20 The main objection to specifying IPR in a WG charter appears to be that = it would prevent groups like S/MIME from considering ECC algorithms. = While this would be true if S/MIME were rechartered with a restriction = of that type I also think that its the wrong forum for the discussion. = One WG chartered with applying ECC to all active IETF protocols would be = a much more efficient approach and much more likely to provide a = consistent result. =20 =20 I can even imagine that a WG of that type might have a time horizon. = Allowing technologies to be considered if they will be available on = RANDZ terms after a specific date. That would create an incentive for = the Patent Rights Holder to remove ambiguity as to which patents are = covered and when they expire. This might possibly provide an incentive = for the Patent Rights Holder to renounce rights to certain claims after = the time horizon expires in order to get their technology adopted. =20 If we have two technologies on offer, A and B from different parties I = want to be able to set up a bidding war between the parties to offer the = most favorable terms. =20 The current IETF practice looks more like the prisoners dilema, the = rules of the game cause the parties to chose the worst outcome. = Axelrod's point was you can change the rules of the game. =20 =20 ________________________________ From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] Sent: Tue 30/10/2007 1:29 AM To: lrosen@rosenlaw.com; ietf@ietf.org Subject: RE: Patents can be for good, not only evil --On 29. oktober 2007 17:53 -0700 Lawrence Rosen wrote: > > The notion that each IETF working group has to approach patent issues = on > its own, without help, is silly. It's also a straw man. RFC 3669. You may argue that we can do better, but the argument that = there is "no help" is silly. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ------_=_NextPart_001_01C81BD4.1FACE515 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Patents can be for good, not only = evil=0A= =0A= =0A= =0A=
=0A=
How many = Working Group participants who vent on patent issues have read RFC = 3669?
=0A=
 
=0A=
Of those who have read it, = how many consider it to be binding?
=0A=
 
=0A=
All RFC 3669 does is to allow = endless discussion of topics that most WGs do not consider core. They = may be important considerations but the Working Groups themselves are = the wrong place to do design work in the IPR space.
=0A=
 
=0A=
Very few Working Group = participants have any real interest or understanding of the patent = system other than to wish it would go away. The most likely reason a WG = participant would have detailed knowedge is if they were an unwilling = participant in a patent lawsuit or had a proposal shot down because some = group of lawyers objected to the IPR terms (both have happend to me). =
=0A=
 
=0A=
The bulk of the opinions = expressed might be characterized as ideological rather than informed. = So what we get as a result is not a = useful discussion, its more like a slashdot flamewa
=0A=
 
=0A=
Its not productive = discussion, the arguments are entirely repetative.
=0A=
 
=0A=
Eliminating repetative, = unproductive arguments is the function of the charter. We write charters = that rule technical issues such as designing a new PKI, Web Services = transport layer, cryptographic algorithm, &ct &ct out of scope. = So why not rule the IPR question out of scope at the charter stage unlss = there is a specific reason to beleive that a WG would need to deal with = it?
=0A=
 
=0A=
A charter statement is never = the final word, WGs discover that their charter needs changing all the = time. If a group discovers that there are unforseen IPR issues it cannot = resolve it has the choice of disbanding without a recommendation, = rechartering or making non standards track submissions.
=0A=
 
=0A=
Understanding the IPR = landscape is one of the things I always try to do before starting or = joining a group. IPR is always a BOF topic. It is not that we don't = discuss in advance. In fact in many cases the whole raison d'etre for = the group is to create an unencumbered standard to replace a proprietary = protocol.
=0A=
 
=0A=
For example, take a look at = the Ford-Wienner key management patent which is due to expire at some = point in the not so distant future. The invention describes a = lightweight CRM scheme. I can well imagine that someone might want = to start a working group to produce an unencumbered CRM protocol based = on Ford-Wienner and S/MIME. The whole point of chartering a group of = that type would be to produce a RANDZ protocol and so it should be = stated in the charter.
=0A=
 
=0A=
 
=0A=
I don't think that there are = many cases where a non RANDZ IPR clause is going to fly. About the only = one I can think of offhand would be that we are comming to a situation = where ECC crypto is becomming seen as necessary for certain = applications. There are credible IPR claims to at least some methods of = performing ECC crypto. There are certainly parties that see a need to = deploy ECC before the IPR encumberances expire.
=0A=
 
=0A=
The main objection to = specifying IPR in a WG charter appears to be that it would prevent = groups like S/MIME from considering ECC algorithms. While this would be = true if S/MIME were rechartered with a restriction of that type I also = think that its the wrong forum for the discussion. One WG chartered with = applying ECC to all active IETF protocols would be a much more efficient = approach and much more likely to provide a consistent = result.
=0A=
 
=0A=
 
=0A=
I can even imagine that a WG = of that type might have a time horizon. Allowing technologies to be = considered if they will be available on RANDZ terms after a specific = date. That would create an incentive for the Patent Rights Holder to = remove ambiguity as to which patents are covered and when they expire. = This might possibly provide an incentive for the Patent Rights = Holder to renounce rights to certain claims after the time horizon = expires in order to get their technology adopted.
=0A=
 
=0A=
If we have two technologies = on offer, A and B from different parties I want to be able to set up a = bidding war between the parties to offer the most favorable = terms.
=0A=
 
=0A=
The current IETF practice = looks more like the prisoners dilema, the rules of the game cause the = parties to chose the worst outcome. Axelrod's point was you can change = the rules of the game.
=0A=
 
=0A=
 
=0A=
=0A=
=0A=
=0A=
From: Harald Tveit = Alvestrand [mailto:harald@alvestrand.no]
Sent: Tue 30/10/2007 = 1:29 AM
To: lrosen@rosenlaw.com; = ietf@ietf.org
Subject: RE: Patents can be for good, not only = evil

=0A=


=0A=

--On 29. oktober 2007 17:53 -0700 Lawrence Rosen = <lrosen@rosenlaw.com>
wrote:

>
> The notion = that each IETF working group has to approach patent issues on
> = its own, without help, is silly.

It's also a straw = man.

RFC 3669. You may argue that we can do better, but the = argument that there
is "no help" is = silly.




_______________________________________________=
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.or= g/mailman/listinfo/ietf

------_=_NextPart_001_01C81BD4.1FACE515-- --===============2064752851== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============2064752851==-- From ietf-bounces@ietf.org Wed Oct 31 12:00:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InFpv-0001qQ-V0; Wed, 31 Oct 2007 11:50:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InFpu-0001nU-Ta for ietf@ietf.org; Wed, 31 Oct 2007 11:50:30 -0400 Received: from ns1.qubic.net ([208.78.240.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InFpo-0004Y3-Lp for ietf@ietf.org; Wed, 31 Oct 2007 11:50:30 -0400 Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.2.Beta1/8.14.2.Beta1) with ESMTP id l9VFnqH4005401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Oct 2007 08:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1193845808; x=1193932208; bh=soWGtLA+ZoJ6W75cdOUlrEBiQQ4HONKn2rLQ BEcWa1Y=; h=DomainKey-Signature:Message-Id:X-Mailer:Date:To:From: Subject:In-Reply-To:References:Mime-Version:Content-Type:Cc; b=Osx v80POB6YI9Se5FDoLfRGLCZ7EKPmDYmNmiQ34MC6h2CjFqD7LzHRq0aJOZ4OZPemGt7 WwpTaw4jT+rmLwRqyo/BEAKx4mpK8hZgFBjg5vesGjwemUN+GMKG/KWZXKYXC8ETEY3 oG72QeTm7k5pypsYh7F44KPiFxnQBiZDww= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=SLWD4mn3ExIbNB2GKS2t8J8763oYv2bY34ijLbZkHvlcnEPBeiC/SOBEHODIrk0vQ g5Z+IdeG+lI61W0bjycm+7E0tKvNpgZ8UMu75XfrkBfBcyiYsOBag5sSiaKZ4IbJi4d wdFKeYOjMBJK8YvhdvAxH7IR5XZZSp1+/bY6IeE= Message-Id: <6.2.5.6.2.20071031081514.02cb0ae0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 31 Oct 2007 08:49:42 -0700 To: ietf@ietf.org From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: Re: Last Call: draft-ietf-xcon-framework (A Framework for Centralized Conferencing) to Proposed Standard X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org At 04:21 31-10-2007, Sam Hartman wrote: >I'd particularly like to ask people to consider section 9. Quoting Section 9: "The SIP Conferencing Framework [8] provides an overview of a wide range of centralized conferencing solutions known today in the conferencing industry. The document introduces a terminology and logical entities in order to systemize the overview and to show the common core of many of these systems." This draft redefines some of the terminology defined in the SIP Conferencing Framework. It would be better to use the same terminology to show a common core. Is there a reason why this draft should be on "Standards Track"? Regards, -sm _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 31 14:04:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InHkx-0000W5-TT; Wed, 31 Oct 2007 13:53:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InHkw-0000Vz-FR for ietf@ietf.org; Wed, 31 Oct 2007 13:53:30 -0400 Received: from machshav.com ([198.180.150.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InHkp-00025X-Bc for ietf@ietf.org; Wed, 31 Oct 2007 13:53:30 -0400 Received: by machshav.com (Postfix, from userid 512) id 29D765B8; Wed, 31 Oct 2007 17:53:06 +0000 (GMT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 80238170; Wed, 31 Oct 2007 17:53:05 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id A171376616D; Wed, 31 Oct 2007 13:53:04 -0400 (EDT) Date: Wed, 31 Oct 2007 17:53:04 +0000 From: "Steven M. Bellovin" To: "Hallam-Baker, Phillip" Message-ID: <20071031175304.476db1a4@cs.columbia.edu> In-Reply-To: <2788466ED3E31C418E9ACC5C31661557084F23@mou1wnexmb09.vcorp.ad.vrsn.com> References: <20071022195723.4D9A22202DA@quill.bollow.ch> <20071023105651.8D9AC2202DA@quill.bollow.ch> <87abqa2i1z.fsf@mocca.josefsson.org> <871wbm2cze.fsf@mocca.josefsson.org> <87fy00vn1l.fsf@mocca.josefsson.org> <471FB60B.3070304@gmail.com> <20071024214601.28e866ce@cs.columbia.edu> <00d801c81689$f64c5f30$6401a8c0@LROSENTOSHIBA> <4720FCFA.7080009@cs.utk.edu> <020d01c81a62$8a7d6510$6401a8c0@LROSENTOSHIBA> <47263C98! .6080703@cs.utk.edu> <022d01c81a7f$bd063ad0$6401a8c0@LROSENTOSHIBA> <20071029234911.0f1e8d80@cs.columbia.edu> <023701c81a8f$4f180980$6401a8c0@LR! OSENTOSHI BA> <77F3A8A0C26D068BE6DB457B@B50854F0A9192E8EC6CDA126> <2788466ED3E31C418E9ACC5C31661557084F23@mou1wnexmb09.vcorp.ad.vrsn.com> Organization: Columbia University X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.0; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Harald Tveit Alvestrand , ietf@ietf.org Subject: Re: Patents can be for good, not only evil X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On Wed, 31 Oct 2007 08:38:45 -0700 "Hallam-Baker, Phillip" wrote: > How many Working Group participants who vent on patent issues have > read RFC 3669? > Of those who have read it, how many consider it to be binding? > It's not binding because it's Informational. However, the topic is frequently covered in WG Chair training sessions. There's a prominent link to IPR issues on the WG Chair's page, including a separate Wiki just on IPR (and the introduction page there explicitly cites 3669). That's not a substitute for all WG participants knowing it, but I'd guess that most chairs do, and can bring it up as appropriate. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 31 15:05:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InIdW-00053T-KT; Wed, 31 Oct 2007 14:49:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InIdU-0004ss-M4 for ietf@ietf.org; Wed, 31 Oct 2007 14:49:52 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InIdF-0004pn-Kq for ietf@ietf.org; Wed, 31 Oct 2007 14:49:43 -0400 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l9VIjI7a020052; Wed, 31 Oct 2007 11:45:18 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Oct 2007 18:48:28 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 31 Oct 2007 11:45:05 -0700 Message-ID: <2788466ED3E31C418E9ACC5C3166155707A81D@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <20071029234911.0f1e8d80@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Patents can be for good, not only evil Thread-Index: AcgaiDbplVaU8X/1QB+bbGFe8Gda4QBZYPBA From: "Hallam-Baker, Phillip" To: "Steven M. Bellovin" , X-OriginalArrivalTime: 31 Oct 2007 18:48:28.0970 (UTC) FILETIME=[A08B28A0:01C81BEE] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ietf@ietf.org Subject: RE: Patents can be for good, not only evil X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Looking at the final office actions from some of my own applications I = absolutely agree with Steve here. It is pretty clear that the only = database that the USPTO can search effectively is its own. One of the reasons I file patents is to smoke out patent claims filed by = others. The USPTO is the most effective method available. Compared to = the expense of a patent lawsuit the cost is negligible. > -----Original Message----- > From: Steven M. Bellovin [mailto:smb@cs.columbia.edu]=20 > Sent: Monday, October 29, 2007 7:49 PM > To: lrosen@rosenlaw.com > Cc: ietf@ietf.org > Subject: Re: Patents can be for good, not only evil >=20 > On Mon, 29 Oct 2007 16:02:10 -0700 > "Lawrence Rosen" wrote: >=20 > > Eric Burger wrote: > > > I specifically applied for patents underlying the=20 > technology behind=20 > > > RFC 4722/RFC 5022 and RFC 4730 specifically to prevent third=20 > > > parties, who are not part of the IETF process, from extracting=20 > > > royalties from someone who implements MSCML or KPML. > >=20 > > That was a waste of your time and money. Publication of those=20 > > inventions by you, at zero cost to you and others, would have been=20 > > sufficient to prevent someone else from trying to patent them. Next=20 > > time, get good advice from a patent lawyer on how to achieve your=20 > > goals without paying for a patent. > >=20 >=20 > You're obviously right in theory on this point. I wonder=20 > whether you're right in practice. We've all seen far too=20 > many really bad patents issued, ones where prior art is=20 > legion. The (U.S.) patent office seems to do a far better=20 > job of searching its own databases than it does the technical=20 > literature. >=20 > I know there are many philosophical reasons why many people=20 > oppose software patents. But for others, there are very=20 > practical reasons: > there are too many bad patents issued. I think we can all=20 > agree that stopping bad patents is a worthwhile goal, even if=20 > for some it's just an intermediate goal. >=20 >=20 > --Steve Bellovin, http://www.cs.columbia.edu/~smb >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 31 17:45:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InL4y-0000S3-1p; Wed, 31 Oct 2007 17:26:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InL4w-0000Lw-Fn for ietf@ietf.org; Wed, 31 Oct 2007 17:26:22 -0400 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InL4s-00015a-31 for ietf@ietf.org; Wed, 31 Oct 2007 17:26:18 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l9VLQ4HE011417; Wed, 31 Oct 2007 17:26:15 -0400 (EDT) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l9VLQ3wj009569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Oct 2007 17:26:03 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id l9VLQ2S9029741; Wed, 31 Oct 2007 17:26:02 -0400 (EDT) To: lconroy References: <917D43E5-30EF-49A9-9DD3-02DC87A35AD4@insensate.co.uk> From: Tom Yu Date: Wed, 31 Oct 2007 17:26:02 -0400 In-Reply-To: <917D43E5-30EF-49A9-9DD3-02DC87A35AD4@insensate.co.uk> (lconroy@insensate.co.uk's message of "Mon, 29 Oct 2007 00:02:09 +0000") Message-ID: Lines: 20 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: IETF Discussion Subject: Re: About referenced documents... X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>>>> "lconroy" == lconroy writes: lconroy> Hi Folks, lconroy> in the process of re-writing the ENUM Experiences draft, I wanted to lconroy> check that its statement on the characters that can be found in POSIX lconroy> Extended Regular Expressions (as called up in RFC 3402) is lconroy> correct. However, the referenced standard is an IEEE document that lconroy> those fine chaps want money to purchase. lconroy> I had thought that the IETF didn't like normative references that lconroy> were not available to all (without paying for them). I believe the POSIX standards are now combined with the Single Unix Specification, maintained by the Open Group, which provides an HTML version free of charge on its website. http://www.opengroup.org/ There may be a free registration procedure required to obtain access. ---Tom _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 31 18:30:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InLtg-00027B-As; Wed, 31 Oct 2007 18:18:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InLtf-00022F-1Y for ietf@ietf.org; Wed, 31 Oct 2007 18:18:47 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InLtY-0007Xy-Tg for ietf@ietf.org; Wed, 31 Oct 2007 18:18:47 -0400 Received: by py-out-1112.google.com with SMTP id d32so1081104pye for ; Wed, 31 Oct 2007 15:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=eSEpOJuTCWxNcHp6E0g2i3VDbdDfiMcHWs+EkNIjChU=; b=ic3quh0FlZ/Qj/ptC99LGmXS4OChVRzBS7t7+vaNNoJUTwwtQs2NCdxtd3TMdP6PNYAloMXWClzlgI/FZe+ob4buLroN05HgQkcHpjrN9eOETAO1yUQajoMQ8rOsZpdyrwmJaiu3OU5vU6Q41aFnfvFrrhjhPfdWZuCO1Yi9+I0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dbSnfgJtbzxkBvUezYh0+auXeGaIiQHisGZxP5sFS+lHbtfl0dg9zgZ3ItNXrRmf0pzbTYI+7eJOfPADD+HRXC6lYHnmuwoFO0Lo/6NxDELl2soZNgOECOGdXd6TeY+gta/z6omAhkHfrcKFeAUPE1apSk2DonCcsJif10EXjBc= Received: by 10.64.181.12 with SMTP id d12mr2244768qbf.1193869087531; Wed, 31 Oct 2007 15:18:07 -0700 (PDT) Received: by 10.65.234.18 with HTTP; Wed, 31 Oct 2007 15:18:07 -0700 (PDT) Message-ID: <8c99930d0710311518m3639810ameecbe11283f102f5@mail.gmail.com> Date: Wed, 31 Oct 2007 18:18:07 -0400 From: "Andrew G. Malis" To: "Randy Presuhn" In-Reply-To: <000401c819cf$982d7620$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <917D43E5-30EF-49A9-9DD3-02DC87A35AD4@insensate.co.uk> <000401c819cf$982d7620$6801a8c0@oemcomputer> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: IETF Discussion Subject: Re: About referenced documents... X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org We've been referencing ITU-T specifications for a very long time, even though until this year you had to pay for them. The key is publicly available, not publicly free. Cheers, Andy On Oct 28, 2007 10:01 PM, Randy Presuhn wrote: > Hi - > > > From: "lconroy" > > To: "IETF Discussion" > > Sent: Sunday, October 28, 2007 4:02 PM > > Subject: About referenced documents... > ... > > I had thought that the IETF didn't like normative references that > > were not available to all (without paying for them). > > > > Am I misunderstanding the situation? > ... > > Many participants in the IETF have a preference for freely available > specifications, but nothing prohibits a normative reference to a > specification that needs to be purchased. Factors to consider > include how widely implemented the specification in question is, > and whether that specification is clearer than or technically superior > to its "competition." > > Randy > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 31 19:16:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMfX-0004bS-8v; Wed, 31 Oct 2007 19:08:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMfT-0004TC-Rv for ietf@ietf.org; Wed, 31 Oct 2007 19:08:11 -0400 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InMfP-0005pk-6i for ietf@ietf.org; Wed, 31 Oct 2007 19:08:11 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id AA6885D208; Wed, 31 Oct 2007 23:08:05 +0000 (GMT) In-Reply-To: References: <917D43E5-30EF-49A9-9DD3-02DC87A35AD4@insensate.co.uk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Date: Wed, 31 Oct 2007 23:08:05 +0000 To: Tom Yu , "Andrew G. Malis" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: IETF Discussion Subject: Re: About referenced documents... X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi Tom, folks, Many thanks for that. This is exactly what I wanted to know. I understand that this is a distraction from the wider IPR crusade, but I wonder if people should consider ensuring that our standards refer to just this kind of open document (e.g. refer to SUS/opengroup standards rather than the original POSIX/IEEE standards). That, ISTM, would be a worthwhile campaign that would not require the whole world to change - if one can't READ the specs, then it is hard to base an implementation on more than Internet rumour and guesswork. ---- As to whether these should be available for free or just be available - it matters to me. Most people who are active in the IETF do so because they have support from whoever is paying them (me too). My company can afford for me to gain access to the referenced standards as needed. Fine. However, Not everyone is in that position - have you seen how much a full (non-academic) IEEE (or full ITU-T/R, or full...) sub costs? Are we really willing to restrict those who can implement IETF standards to those who are supported by a (well funded) company? I hope not. I am fed up with folk just looking at the examples given in an RFC and assuming that these are always correct/sufficient/complete. It's dumb. If they can't read the references specs because they can't afford them, then it's our bad, not theirs. ...and with that, we return you to your regular scheduled IPR crusade. all the best, Lawrence On 31 Oct 2007, at 21:26, Tom Yu wrote: >>>>>> "lconroy" == lconroy writes: > > lconroy> Hi Folks, > lconroy> in the process of re-writing the ENUM Experiences draft, > I wanted to > lconroy> check that its statement on the characters that can be > found in POSIX > lconroy> Extended Regular Expressions (as called up in RFC 3402) is > lconroy> correct. However, the referenced standard is an IEEE > document that > lconroy> those fine chaps want money to purchase. > lconroy> I had thought that the IETF didn't like normative > references that > lconroy> were not available to all (without paying for them). > > I believe the POSIX standardFrom ietf-bounces@ietf.org Wed Oct 31 19:16:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMfX-0004bS-8v; Wed, 31 Oct 2007 19:08:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMfT-0004TC-Rv for ietf@ietf.org; Wed, 31 Oct 2007 19:08:11 -0400 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InMfP-0005pk-6i for ietf@ietf.org; Wed, 31 Oct 2007 19:08:11 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id AA6885D208; Wed, 31 Oct 2007 23:08:05 +0000 (GMT) In-Reply-To: References: <917D43E5-30EF-49A9-9DD3-02DC87A35AD4@insensate.co.uk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Date: Wed, 31 Oct 2007 23:08:05 +0000 To: Tom Yu , "Andrew G. Malis" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: IETF Discussion Subject: Re: About referenced documents... X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi Tom, folks, Many thanks for that. This is exactly what I wanted to know. I understand that this is a distraction from the wider IPR crusade, but I wonder if people should consider ensuring that our standards refer to just this kind of open document (e.g. refer to SUS/opengroup standards rather than the original POSIX/IEEE standards). That, ISTM, would be a worthwhile campaign that would not require the whole world to change - if one can't READ the specs, then it is hard to base an implementation on more than Internet rumour and guesswork. ---- As to whether these should be available for free or just be available - it matters to me. Most people who are active in the IETF do so because they have support from whoever is paying them (me too). My company can afford for me to gain access to the referenced standards as needed. Fine. However, Not everyone is in that position - have you seen how much a full (non-academic) IEEE (or full ITU-T/R, or full...) sub costs? Are we really willing to restrict those who can implement IETF standards to those who are supported by a (well funded) company? I hope not. I am fed up with folk just looking at the examples given in an RFC and assuming that these are always correct/sufficient/complete. It's dumb. If they can't read the references specs because they can't afford them, then it's our bad, not theirs. ...and with that, we return you to your regular scheduled IPR crusade. all the best, Lawrence On 31 Oct 2007, at 21:26, Tom Yu wrote: >>>>>> "lconroy" == lconroy writes: > > lconroy> Hi Folks, > lconroy> in the process of re-writing the ENUM Experiences draft, > I wanted to > lconroy> check that its statement on the characters that can be > found in POSIX > lconroy> Extended Regular Expressions (as called up in RFC 3402) is > lconroy> correct. However, the referenced standard is an IEEE > document that > lconroy> those fine chaps want money to purchase. > lconroy> I had thought that the IETF didn't like normative > references that > lconroy> were not available to all (without paying for them). > > I believe the POSIX standards are now combined with the Single Unix > Specification, maintained by the Open Group, which provides an HTML > version free of charge on its website. > > http://www.opengroup.org/ > > There may be a free registration procedure required to obtain access. > > ---Tom _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 31 19:16:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMlY-0007yL-5C; Wed, 31 Oct 2007 19:14:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMlW-0007xu-PB for ietf@ietf.org; Wed, 31 Oct 2007 19:14:26 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1InMlR-0002gE-Gi for ietf@ietf.org; Wed, 31 Oct 2007 19:14:26 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa19249; 31 Oct 2007 19:13 EDT Date: Wed, 31 Oct 2007 19:13:35 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: , , , , Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: jhutz+@cmu.edu Subject: secdir review of draft-ietf-v6ops-scanning-implications-03 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document discusses implications of IPv6's larger address space and larger typical subnet size for traditional network address range scanning techniques often used to identify nodes. It discusses other methods which may be used by attackers to discover IPv6 notes, approaches that can be used by network administrators to counter them, and techniques by which adminstrators can take advantage of IPv6's large address apace to make it harder to identify potential targets for attack. This document provides a lot of good advice on how to make node addresses on an IPv6 network difficult to discover. That is, it discusses ways to obscure addresses. According to traditional wisdom, "security through obscurity is worse than no security at all". Put another way, obscuring addresses can be a useful tool in building a defense-in-depth, but relying solely on obscurity of node addresses is asking for trouble. I would like this point stressed in the security considerations for this document, possibly including references to other sources on techniques that can be used to secure hosts, communication between hosts, and/or network access. -- Jeff _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf s are now combined with the Single Unix > Specification, maintained by the Open Group, which provides an HTML > version free of charge on its website. > > http://www.opengroup.org/ > > There may be a free registration procedure required to obtain access. > > ---Tom _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 31 19:16:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMlY-0007yL-5C; Wed, 31 Oct 2007 19:14:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMlW-0007xu-PB for ietf@ietf.org; Wed, 31 Oct 2007 19:14:26 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1InMlR-0002gE-Gi for ietf@ietf.org; Wed, 31 Oct 2007 19:14:26 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa19249; 31 Oct 2007 19:13 EDT Date: Wed, 31 Oct 2007 19:13:35 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: , , , , Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: jhutz+@cmu.edu Subject: secdir review of draft-ietf-v6ops-scanning-implications-03 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document discusses implications of IPv6's larger address space and larger typical subnet size for traditional network address range scanning techniques often used to identify nodes. It discusses other methods which may be used by attackers to discover IPv6 notes, approaches that can be used by network administrators to counter them, and techniques by which adminstrators can take advantage of IPv6's large address apace to make it harder to identify potential targets for attack. This document provides a lot of good advice on how to make node addresses on an IPv6 network difficult to discover. That is, it discusses ways to obscure addresses. According to traditional wisdom, "security through obscurity is worse than no security at all". Put another way, obscuring addresses can be a useful tool in building a defense-in-depth, but relying solely on obscurity of node addresses is asking for trouble. I would like this point stressed in the security considerations for this document, possibly including references to other sources on techniques that can be used to secure hosts, communication between hosts, and/or network access. -- Jeff _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 31 21:04:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InO9a-0002jt-CZ; Wed, 31 Oct 2007 20:43:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InO9Y-0002Xd-Q0 for ietf@ietf.org; Wed, 31 Oct 2007 20:43:20 -0400 Received: from rv-out-0910.google.com ([209.85.198.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InO9J-0005VW-Rv for ietf@ietf.org; Wed, 31 Oct 2007 20:43:12 -0400 Received: by rv-out-0910.google.com with SMTP id l15so274394rvb for ; Wed, 31 Oct 2007 17:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=xmFX7aRODwMQg/RZqRu6JpsswV1s/FJFhdbaqNCmf7w=; b=CFzZRzlCIIkowlRnhz4o/FyXjkC01YLH4AtLNHVtJtIkcNwvBtWGTbRZ4pvnuIBWLjuETgAVoxryEwAHCJiOjoaLR74wML2oXjj3dX8mQsSIYrbgKfEFOUV8dcjWVJb47FW4nSnbXrvRnB7jrRPKZ+DP3MmmLGVZpIqTKpS9XoE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=iCmTvPrqYtwCvDwew5oQmXc+YFmZqVExBDrsPZV/x+7LL4WxIyymMq8TK5uv3iGsrT5HXG1Fqzd0GLwBIJrUU2DX6QtZ0nB0vJ1GTPGiCZwNnf1wTOOrqToX8Ws1E+dtLoKMja+vfxN6C1pNvzExnHYiCDs6YbjTpHsYd15puYw= Received: by 10.141.90.17 with SMTP id s17mr7543rvl.1193877740128; Wed, 31 Oct 2007 17:42:20 -0700 (PDT) Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id g1sm2413533rvb.2007.10.31.17.42.17 (version=SSLv3 cipher=RC4-MD5); Wed, 31 Oct 2007 17:42:19 -0700 (PDT) Message-ID: <472920E7.5090905@gmail.com> Date: Thu, 01 Nov 2007 13:42:15 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: lconroy References: <917D43E5-30EF-49A9-9DD3-02DC87A35AD4@insensate.co.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: "Andrew G. Malis" , IETF Discussion , Tom Yu Subject: Re: About referenced documents... X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org On 2007-11-01 12:08, lconroy wrote: > Hi Tom, folks, > Many thanks for that. This is exactly what I wanted to know. > I understand that this is a distraction from the wider IPR crusade, > but I wonder if people should consider ensuring that our standards > refer to just this kind of open document (e.g. refer to SUS/opengroup > standards rather than the original POSIX/IEEE standards). But what if the freely available document is slightly out of date or slightly different compared to the official one? That isn't a sound basis for a normative reference. In such a case, I would consider a normative reference to the official (paid) standard and an informative reference to the free one, with a warning. Brian > > That, ISTM, would be a worthwhile campaign that would not require the > whole world to change - if one can't READ the specs, then it is hard > to base an implementation on more than Internet rumour and guesswork. > > ---- > > As to whether these should be available for free or just be available > - it matters to me. Most people who are active in the IETF do so because > they have support from whoever is paying them (me too). My company can > afford for me to gain access to the referenced standards as needed. > Fine. > > However, Not everyone is in that position - have you seen how much > a full (non-academic) IEEE (or full ITU-T/R, or full...) sub costs? > Are we really willing to restrict those who can implement IETF > standards to those who are supported by a (well funded) company? > I hope not. > > I am fed up with folk just looking at the examples given in an RFC and > assuming that these are always correct/sufficient/complete. It's dumb. > If they can't read the references specs because they can't afford them, > then it's our bad, not theirs. > > ...and with that, we return you to your regular scheduled IPR crusade. > > all the best, > Lawrence > > On 31 Oct 2007, at 21:26, Tom Yu wrote: >>>>>>> "lconroy" == lconroy writes: >> >> lconroy> Hi Folks, >> lconroy> in the process of re-writing the ENUM Experiences draft, I >> wanted to >> lconroy> check that its statement on the characters that can be found >> in POSIX >> lconroy> Extended Regular Expressions (as called up in RFC 3402) is >> lconroy> correct. However, the referenced standard is an IEEE document >> that >> lconroy> those fine chaps want money to purchase. >> lconroy> I had thought that the IETF didn't like normative references >> that >> lconroy> were not available to all (without paying for them). >> >> I believe the POSIX standards are now combined with the Single Unix >> Specification, maintained by the Open Group, which provides an HTML >> version free of charge on its website. >> >> http://www.opengroup.org/ >> >> There may be a free registration procedure required to obtain access. >> >> ---Tom > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 31 22:26:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InPPw-0004Ul-3g; Wed, 31 Oct 2007 22:04:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InPPt-0004PD-QD for ietf@ietf.org; Wed, 31 Oct 2007 22:04:17 -0400 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InPPj-000840-Hr for ietf@ietf.org; Wed, 31 Oct 2007 22:04:12 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id lA123bh7014361; Wed, 31 Oct 2007 22:03:38 -0400 (EDT) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id lA123aI9009772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Oct 2007 22:03:37 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id lA123aOC004001; Wed, 31 Oct 2007 22:03:36 -0400 (EDT) To: Brian E Carpenter References: <917D43E5-30EF-49A9-9DD3-02DC87A35AD4@insensate.co.uk> <472920E7.5090905@gmail.com> From: Tom Yu Date: Wed, 31 Oct 2007 22:03:36 -0400 In-Reply-To: <472920E7.5090905@gmail.com> (Brian E. Carpenter's message of "Thu, 01 Nov 2007 13:42:15 +1300") Message-ID: Lines: 22 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: lconroy , "Andrew G. Malis" , IETF Discussion Subject: Re: About referenced documents... X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org >>>>> "Brian" == Brian E Carpenter writes: Brian> On 2007-11-01 12:08, lconroy wrote: >> Hi Tom, folks, >> Many thanks for that. This is exactly what I wanted to know. >> I understand that this is a distraction from the wider IPR crusade, >> but I wonder if people should consider ensuring that our standards >> refer to just this kind of open document (e.g. refer to SUS/opengroup >> standards rather than the original POSIX/IEEE standards). Brian> But what if the freely available document is slightly out of date Brian> or slightly different compared to the official one? That isn't a sound Brian> basis for a normative reference. In such a case, I would consider Brian> a normative reference to the official (paid) standard and an informative Brian> reference to the free one, with a warning. My understanding is that the Open Group / SUS standards are supposed to be technically and textually identical to the IEEE 1003.x standards, or at least, a strict superset thereof. If someone has evidence to the contrary, I would like to know about it. ---Tom _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Wed Oct 31 23:58:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InQtt-0003r4-HJ; Wed, 31 Oct 2007 23:39:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InQts-0003qf-5V for ietf@ietf.org; Wed, 31 Oct 2007 23:39:20 -0400 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InQtm-0002V2-1U for ietf@ietf.org; Wed, 31 Oct 2007 23:39:20 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=P1o+XmGC+4HBIXa881YfJEnc/roMoyVfwRACjofwPll4L2f/IkNrdTN5aE2XzLeF; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.80.146] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1InQtb-0005f3-Ia for ietf@ietf.org; Wed, 31 Oct 2007 23:39:03 -0400 Message-ID: <000101c81c41$19e8d380$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <917D43E5-30EF-49A9-9DD3-02DC87A35AD4@insensate.co.uk><472920E7.5090905@gmail.com> Date: Wed, 31 Oct 2007 20:18:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31a8073ca4543ccdccd7c8712d46fb598dc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.146 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: Re: About referenced documents... X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Hi - > From: "Tom Yu" > To: "Brian E Carpenter" > Cc: "lconroy" ; "Andrew G. Malis" ; "IETF Discussion" > Sent: Wednesday, October 31, 2007 6:03 PM > Subject: Re: About referenced documents... ... > My understanding is that the Open Group / SUS standards are supposed > to be technically and textually identical to the IEEE 1003.x > standards, or at least, a strict superset thereof. If someone has > evidence to the contrary, I would like to know about it. ... Speculating... A strict subset might be palatable. A superset (strict or not) probably would not, since that would entail requirements beyond those in the intended specification. Randy _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf