Re: [sfc] Call for adoption https://datatracker.ietf.org/doc/draft-kumar-sfc-offloads/

"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 23 March 2017 16:29 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D816112997E for <sfc@ietfa.amsl.com>; Thu, 23 Mar 2017 09:29:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vp6S1tDfwO_v for <sfc@ietfa.amsl.com>; Thu, 23 Mar 2017 09:29:03 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54701129865 for <sfc@ietf.org>; Thu, 23 Mar 2017 09:29:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id ED7DEAE012A; Thu, 23 Mar 2017 09:29:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1490286541; bh=uHQIBfyi3GC2fPKuZDgK7F+F+G1CpN59WKupOPPCvFI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=TWKxnOcIjiDTGVWCQP0eI6Uk5kEbp74DYdW6IY0Xal+WTjKPxC/N1lFXo4FCjXUeo P2947BuZpPy4+7WxyXoYqYG5/yYBlaRVkRp/PHNzehz3rfuItyNsuh0tMuP2EyRiuT t+HQnabEMxDgpOZllIlHKjU8ly9Hs619IwuNiO3g=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 48B7D24B481; Thu, 23 Mar 2017 09:29:01 -0700 (PDT)
To: Greg Mirsky <gregimirsky@gmail.com>, James N Guichard <james.n.guichard@huawei.com>
References: <BF1BE6D99B52F84AB9B48B7CF6F17DA3DC0171@SJCEML701-CHM.china.huawei.com> <CA+RyBmWyENuFGPhPAMS6oy9fQ0TugmjKhFm4Jwatxn7gA3iXWg@mail.gmail.com>
Cc: "sfc@ietf.org" <sfc@ietf.org>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <7cf3f074-ebda-2ffa-ae05-386f13a7048e@joelhalpern.com>
Date: Thu, 23 Mar 2017 12:29:00 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CA+RyBmWyENuFGPhPAMS6oy9fQ0TugmjKhFm4Jwatxn7gA3iXWg@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/FHd3IzX5MU8dIRV4MhXMjwAlIvU>
Subject: Re: [sfc] Call for adoption https://datatracker.ietf.org/doc/draft-kumar-sfc-offloads/
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2017 16:29:05 -0000

The IETF rules on IPR are quite explicit.
We must not (and will not) seek or get for the IETF expert opinion on 
the meaning or applicability of claimed IPR.  Individual participants 
are of course free to use their own resources to help them form an 
opinion, but the WG can not do that.

Also, the IETF policy is that we require disclosure.  Working group 
participants may have preferences for different solutions based on those 
disclosure, but the IETF does not have a formal policy to prefer one or 
another.  There are common preferences among within the community.

Net: calling attention to the IPR disclosures is reasonable and sensible.
Asking the WG to actually form an opinion on applicability is not permitted.
Whether the terms one or more IPR claims state affects our decisions on 
what to use is up to the WG as individual members.

Yours,
Joel

PS: The above statement applies without regard to the content of the IPR 
claims.  I have not looked at who is making the claims or what they are 
claiming.

On 3/23/17 12:17 PM, Greg Mirsky wrote:
> Dear Authors, WG Chairs, et. al,
> I've read the draft and think that it addresses practical scenario,
> offers viable solution and expresses it all in well-written form. Hence
> I support its adoption by SFC WG.
> But I find the draft to be in quite unusual, at least in my experience
> at IETF, situation in regard to IPR disclosures. It has two disclosures
> <https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-kumar-sfc-offloads>
> with different licencing clauses:
>
>   * a covenant not to assert or royalty bearing licensee;
>   * RAND with possible royalty/fee to implementers.
>
> I'm not, by far, an IPR expert but, as I recall, IETF is striving to
> advance solutions that do not bear imposition of royalty fee on an
> implementer. I think that it would be helpful to get clarification,
> expert opinion perhaps, on relationship of both IPR claims and the
> solution defined in the draft.
>
> Regards,
> Greg
>
> On Fri, Mar 10, 2017 at 7:08 PM, James N Guichard
> <james.n.guichard@huawei.com <mailto:james.n.guichard@huawei.com>> wrote:
>
>     Greetings WG,____
>
>     __ __
>
>     This message begins a two week call for WG adoption of the document
>     https://datatracker.ietf.org/doc/draft-kumar-sfc-offloads/
>     <https://datatracker.ietf.org/doc/draft-kumar-sfc-offloads/> ending
>     24^th March 2017.____
>
>     __ __
>
>     Please respond to the SFC mailing list with any statements of
>     approval or disapproval.____
>
>     __ __
>
>     Please note:____
>
>     __ __
>
>     __1.        __This is not WG last call. The document is not final
>     and the WG is expected to modify the content until there is WG
>     consensus that the content is solid. Therefore, please don’t oppose
>     adoption just because you want to see changes to its content.____
>
>     __2.        __If you have objections to adoption of the document,
>     please state your reasons why, and explain what it would take to
>     address your concerns.____
>
>     __3.        __If you have issues with the content, by all means
>     raise those issues and we can begin a dialog about how best to
>     address them.____
>
>     __ __
>
>     Yours,____
>
>     __ __
>
>     Jim & Joel____
>
>     __ __
>
>     __ __
>
>
>     _______________________________________________
>     sfc mailing list
>     sfc@ietf.org <mailto:sfc@ietf.org>
>     https://www.ietf.org/mailman/listinfo/sfc
>     <https://www.ietf.org/mailman/listinfo/sfc>
>
>
>
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>