Re: [IPsec] New criteria draft
Yaron Sheffer <yaronf@checkpoint.com> Thu, 11 March 2010 18:59 UTC
Return-Path: <yaronf@checkpoint.com>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 292253A6988 for <ipsec@core3.amsl.com>; Thu, 11 Mar 2010 10:59:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.475
X-Spam-Level:
X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdhZD1Kw3e0j for <ipsec@core3.amsl.com>; Thu, 11 Mar 2010 10:58:59 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id EEF683A6ACD for <ipsec@ietf.org>; Thu, 11 Mar 2010 10:33:13 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o2BIXHsd012411; Thu, 11 Mar 2010 20:33:17 +0200 (IST)
X-CheckPoint: {4B9935D1-0-1B201DC2-2FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 11 Mar 2010 20:33:38 +0200
From: Yaron Sheffer <yaronf@checkpoint.com>
To: Dan Harkins <dharkins@lounge.org>
Date: Thu, 11 Mar 2010 20:33:37 +0200
Thread-Topic: [IPsec] New criteria draft
Thread-Index: AcrBQVVtzbfQ9T6/TJSE5bqhCbzq/AABYQyc
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C89C@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C889@il-ex01.ad.checkpoint.com>, <39fb97c8009b2eefcbed01b9f77d9cea.squirrel@www.trepanning.net>
In-Reply-To: <39fb97c8009b2eefcbed01b9f77d9cea.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: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C89Cilex01adche_"
MIME-Version: 1.0
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [IPsec] New criteria draft
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Mar 2010 18:59:01 -0000
Hi Dan, thanks for your comments. Please see my response inline. Yaron ________________________________________ From: Dan Harkins [dharkins@lounge.org] Sent: Thursday, March 11, 2010 7:35 PM To: Yaron Sheffer Cc: ipsec@ietf.org Subject: Re: [IPsec] New criteria draft Hi Yaron, One comment you might've missed was this: Also, the table in section 5 should include IEEE 802.11s under the "standards" column for SPSK. And the phrase "may or may not infringe on existing patents" applies to all candidates, and frankly, to almost everything in the IETF. It is a meaningless phrase and it would be better to just remove it from the "IPR" column. That comment also received a "+1" from another commenter on the list. <YS> In fact, I did not miss these two comments. I did not list 802.11s because I prefer to list only standards that are primarily vetted by the security community. Hence the "Securty Standards" column in -01. Regarding the second comment, while in principle I agree that it could apply to anything done at the IETF, unfortunately in our case it does apply. It applies because of two reasons: - Spurious (whether legitimate or not, I cannot say) IPR statements made agaist SRP. - The sheer amount of patents in this area that must be analysed to ensure, with a high level of confidence, that you will not be sued for implementing X. And I disagree with your statement below, "It is not our job to prove that no patents apply to some technology." As individuals, and for many of us, as employees, it is our job to ensure ourselves that we (or our company) will not be getting into legal/financial trouble by making this choice. And I don't think this is "proving a negative". We can think of a process to get this level of confidence. But just shouting at one another will not get us there. Please see http://tools.ietf.org/html/draft-mcgrew-fundamental-ecc-01 for a creative approach to deal with IPR in another, somewhat related, contentious area. Having said that, if you read -01 carefully, you will see that I'd rather focus our energies on discussing the security aspects rather than endlessly discussing IPR. And by the way, which protocol are you referring to in the last paragraph? </YS> Also, I think this takes us down a particularly bad path: o Ideally, the proposal should be unencumbered. This property is very difficult to prove, and each WG participant should attempt to review the applicable patents and determine whether in fact they do not apply to the proposal. Remember that independently invented technology might still infringe a patent. o In some cases the IPR situation is clear: if the protocol relies on a specific patent, and believed to not require the use of any other. This is mostly useful if the patent's licensing terms (whether free or not) are known, and/or the patent's expiration date is near. So while we start off our criteria grandly with "it should be unencumbered" we immediately then dismiss that by saying we can't forget it might still be patented by some unknown patent. So "ideally" is just one of those states we cannot achieve because even if it's "unencumbered" it might not be. So that's off, what's next? If the IPR situation is clear, it relies on a specific patent and the patent's expiration date is near. So I guess we're just supposed to stop here, right? It is unwise for anyone to say what another IP holder will say with respect to his or her IPR. And there might be a patent that covers everything done in the IETF, we just don't know and it's not our job to prove a negative. So I think it would be very unfortunate if the discussion of candidates jumped down this rathole. We would have "I'm not a lawyer but..." followed by a contentious statement and 8 people jumping up to the queue on the mic to precede their comments with "I'm not a lawyer but..." and then make other contentious statements. I think the IPR content in this draft should be as simple as possible: o We live in a litigious world and patents are used as both a club and a shield. o Patents might or might not exist on every technology we discuss. o We should not attempt to prove or disprove whether this or that patent might or might not cover some technology. o It is not our job to prove that no patents apply to some technology. It would be great to choose a technology that does not require any licensing but as we've seen in the last couple days even the most straightforward and innocent of protocols that we choose to adopt can still be encumbered. regards, Dan. On Thu, March 11, 2010 1:17 am, Yaron Sheffer wrote: > Hi, > > Based on mailing list comments, I have posted a revision of > draft-sheffer-ipsecme-pake-criteria here: > http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/TempDocs. I will submit it > as usual when the submission window reopens. > > Thanks, > Yaron > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > Scanned by Check Point Total Security Gateway.
- [IPsec] New criteria draft Yaron Sheffer
- Re: [IPsec] New criteria draft Dan Harkins
- Re: [IPsec] New criteria draft Yaron Sheffer
- Re: [IPsec] New criteria draft thomwu
- Re: [IPsec] New criteria draft Dan Harkins