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

tjw ietf <tjw.ietf@gmail.com> Fri, 06 January 2017 19:00 UTC

Return-Path: <tjw.ietf@gmail.com>
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 21C2D129BB0 for <dnsop@ietfa.amsl.com>; Fri, 6 Jan 2017 11:00:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 qKtRlXKG4b-9 for <dnsop@ietfa.amsl.com>; Fri, 6 Jan 2017 11:00:40 -0800 (PST)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA2E129BAE for <dnsop@ietf.org>; Fri, 6 Jan 2017 11:00:40 -0800 (PST)
Received: by mail-it0-x22b.google.com with SMTP id 192so22294238itl.0 for <dnsop@ietf.org>; Fri, 06 Jan 2017 11:00:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TUwUELqvkNOOM76v0ou+SQOX6zXUAfuemMJADiYbqKg=; b=NtDT4pQwMZf3iqfdoVlk1BtHGE1KyyxX52YkBmDrxg3iXSMjXjmR2JIF85e1fmF+iD q4ORIzbwZPcl3hyqcPPBXdbumeZDRLN5fCdIakHm7duxopOjal2pEkYDLHOCXuDJiIfU w/qVEHjL4liAn0bH5xQdYDPmfmWVxBYpB5ix1hdSLrfnEz73U/bJDxlI+g5z4aviJrcC VRlGCVmhSQcSngUfkWcfsEyj/S2MsDym1jJy1CTYuVEsKgOMKxrB/GhkBuVnsZ4bsMjs quQDZoYU7bBzYlflrtQQlp9qNK8lZppyf3epjB82akH4FqVuTtHwELaFEhe2GStDN/wv 7Pww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TUwUELqvkNOOM76v0ou+SQOX6zXUAfuemMJADiYbqKg=; b=s/Xn87Y3fGiImOQcsAOOMvLC+qrD7bSmS91YVC474DPI+iD57SZ0PjVvxuKbBTOIuo wY7Krco1haaD8pqaDnAGzE5Gx3GwnHtG6KrwvkfHzut+1KLRT4Dj/LYhCGL9bMvHMQ68 JUtWWZjWDdEAgiyGUKe6jrLX9VNRN4u3mR9UemMKnDyYV+LRYr236OnGSEqy3/7Fdksa 7wzFiKLPSNpkplzYaoQ/6KHTn2T7Ar3Bgj3G1FPcshCUZHBDBfLVxxxF2EvHa+uKZN99 ynIwhTgX+8MZgx+VMXI6YfkUsoZRrJ2C0ql3u3EBH7FcdYhCB7IGB62Q37n3bBs0270t LsaA==
X-Gm-Message-State: AIkVDXJ8enUNu8jx72PXVE97vJRlhNgfHHJs5xG41AgFmehUpRpP/T+pIc0HMa8mvkHOLZjYBQkdgMtCluql0Q==
X-Received: by 10.36.58.198 with SMTP id m189mr54752itm.105.1483729239809; Fri, 06 Jan 2017 11:00:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.79.163.19 with HTTP; Fri, 6 Jan 2017 11:00:39 -0800 (PST)
In-Reply-To: <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> <20170106182542.GA10310@jurassic>
From: tjw ietf <tjw.ietf@gmail.com>
Date: Fri, 06 Jan 2017 14:00:39 -0500
Message-ID: <CADyWQ+H3O0V5i6K_K-VQA=dp6=C9APPVuaEpst-dY90PFeG-Bg@mail.gmail.com>
To: Mukund Sivaraman <muks@isc.org>
Content-Type: multipart/alternative; boundary="001a11441658482d7a054571a24d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Co6M8oy4cE89mjcYWS7ZbFqbknc>
Cc: joel jaeggli <joelja@bogus.com>, 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 19:00:42 -0000

Mukund,

While I agree with you, Joel has the right guidance on this; but also
knowing the authors fairly well,
I feel they would not send us down a road that will box the work into a
corner.

On Fri, Jan 6, 2017 at 1:25 PM, Mukund Sivaraman <muks@isc.org> wrote:

> 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
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>