Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt

Mukund Sivaraman <muks@isc.org> Fri, 06 January 2017 18:25 UTC

Return-Path: <muks@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77257129D74 for <dnsop@ietfa.amsl.com>; Fri, 6 Jan 2017 10:25:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
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 3M8XGTuwWBic for <dnsop@ietfa.amsl.com>; Fri, 6 Jan 2017 10:25:49 -0800 (PST)
Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 927DD129D73 for <dnsop@ietf.org>; Fri, 6 Jan 2017 10:25:49 -0800 (PST)
Received: from jurassic (unknown [115.118.213.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 4E3B92FA0225; Fri, 6 Jan 2017 18:25:47 +0000 (GMT)
Date: Fri, 06 Jan 2017 23:55:42 +0530
From: Mukund Sivaraman <muks@isc.org>
To: joel jaeggli <joelja@bogus.com>
Message-ID: <20170106182542.GA10310@jurassic>
References: <147909930902.10318.12934239778853597228.idtracker@ietfa.amsl.com> <CAHw9_iK2mrzjpew2-jH9HTxoxGQT2DESzFt2G_iPQDOjq2KAEw@mail.gmail.com> <20161127111037.GA10721@jurassic> <CAHw9_iJXOEFoXLM-8XspFQBiHKZtpP6djFr6YR-Zd+A7NG5P0A@mail.gmail.com> <20170106172545.GA2684@jurassic> <ad86d5d0-40d4-0470-a369-37ab7af2937b@bogus.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V"
Content-Disposition: inline
In-Reply-To: <ad86d5d0-40d4-0470-a369-37ab7af2937b@bogus.com>
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6hc6yH4WSe7pkbK2zyjS9JjT9z8>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jan 2017 18:25:50 -0000

On Fri, Jan 06, 2017 at 09:47:41AM -0800, joel jaeggli wrote:
> On 1/6/17 9:25 AM, Mukund Sivaraman wrote:
> > On Fri, Jan 06, 2017 at 01:48:59AM +0000, Warren Kumari wrote:
> >>> (2) In a feature implemented for Unbound:
> >>>
> >>> - Unbound first checks cache
> >>>
> >>> - If a stale answer is found, its TTL is set to 0, and the cache entry
> >>>   is served
> >>>
> >>> - If a stale answer is found, Unbound starts something similar to
> >>>   prefetch/HAMMER.
> >>>
> >>>> NOTE: I believe that there may be (non-Google) IP associated with
> >>>> this. A lawyer will be filing the IPR disclosure later today (time
> >>>> zone differences, etc).
> >>> The two approaches are somewhat different, and so at least one of them
> >>> may not be covered by this patent.
> >>>
> >> Yup. The IPR disclose was about IPR belonging to Xerocole. Xerocole was
> >> acquired by Akamai in March 2015. I believe that David will discuss the IPR
> >> with his employer.
> > Please explore if this patent can be circumvented without affecting the
> > goal of the draft, so that it does not apply. It would be better than
> > licensing it under some legal terms.
> IMHO this can be better expressed as a preference for unencumbered
> technology.
> 
> the working group should not as far as I am concerned get buried in how
> precisely to achieve that.

There's nothing wrong in exploring unencumbered technology. It isn't too
much of a diversion to check if the patent can be avoided.

IETF has had several drafts that avoid patented methods by documenting
something else (compress vs. deflate/gzip, gif vs png, MPEG video vs
vpx, MPEG audio vs vorbis, opus, etc.) that usually turned out to be
better.

One of the authors of this draft works at the company that owns the
patent. As he is introducing this draft and implementations such as mine
are concerned about the use of this patent, it would be good to attempt
to discover if the patented method can be avoided.

		Mukund