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

From: Warren Kumari <[email-masked]>
Date: Fri, 06 Jan 2017 01:48:59 +0000

On Sun, Nov 27, 2016 at 6:10 AM Mukund Sivaraman <[email-masked]> wrote:

> Hi Warren
>
> On Mon, Nov 14, 2016 at 02:05:31PM +0900, Warren Kumari wrote:
> > Hi all,
> >
> > I have just submitted "Stretching DNS TTLs"
> > (draft-wkumari-dnsop-ttl-stretching-00).
> >
> > The very high level overview is:
> > If you are doing something like HAMMER / pre-fetch, and cannot reach
> > the authoritative server when trying to refresh a record, you may
> > continue to use a record past the TTL.
> > This is working on the theory that stale bread is better than no bread.
> > This is a strawman doc / idea, I'm expecting much discussion on if the
> > above is true.
>
> Apparently, there are a couple of approaches that implementations have
> taken:
>
> (1) In a proprietary patch for BIND:
>
- named as resolver first checks cache for a non-stale/unexpired answer
>
> - If no answer is found, named performs resolution, and it has to send
>   one or more fetches (query to an authoritative server)
>
> - If the fetch takes more than a threshold time (but not as long as the
>   timeout duration), named then serves any stale answer in the
>   cache. But named keeps the fetch going until it times out. If the
>   fetch eventually succeeds, the cache is updated.
>
> - A stale cache entry is not used beyond a particular maximum time.
>

Dear all,

I'd like to apologize for not having responded (onlist) until now - this
was not me ignoring you, rather we were getting our ducks in a row...

David Lawrence and I have been chatting since Seoul - he is the author of
the above patch; I'm planning on abandoning
draft-wkumari-dnsop-ttl-stretching and he and I will (soon) be releasing a
joint document which describes the behavior in his patch. This will be
describing running code, and so will / should be closer to ready for
publication.

> (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.

 W

>                 Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Fri, 6 Jan 2017 22:55:45 +0530

> acquired by Akamai in March 2015. I believe that David will discuss the IPR

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.

Consequently, if the patented method is strictly adopted, please include
an explanation of why it could not be circumvented.

		Mukund

---

From: joel jaeggli <[email-masked]>
Date: Fri, 6 Jan 2017 09:47:41 -0800

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

---

From: Mukund Sivaraman <[email-masked]>
Date: Fri, 6 Jan 2017 23:55:42 +0530

> 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

---

From: tjw ietf <[email-masked]>
Date: Fri, 6 Jan 2017 14:00:39 -0500

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.

---

From: Mukund Sivaraman <[email-masked]>
Date: Sat, 7 Jan 2017 01:11:59 +0530

Hi Tim

> I feel they would not send us down a road that will box the work into a

Yes, it was not in any way a statement about these particular authors.
I know the two authors are trying to work together to document something
which will be beneficial for DNS. Having spoken to DCL about this in
Seoul (I told DCL that Warren wanted to make a draft for this and they
should get in touch), I don't think he has any specific interest to
incorporate a patented idea.  Their interest is in having the details of
TTL stretching worked out.

However, when there is any person X introducing a specificiation which
incorporates a patent he/she owns, it could appear self-serving. In this
case, isn't it due process to question if any other approaches are
possible? (I say this in general terms - not specifically about this
author or his company.)

TTL stretching is a simple problem (it isn't a complicated area such as
a media codec). Exploring whether the method can be implemented without
being encumbered by the known patent wouldn't take a lot of time or
discussion.

This isn't even a published draft yet, so we don't know what the authors
may come up with.

There have been some noises from the nethers that the patent could be
avoided with minor modifications. I'm encouraging the authors again to
do some exploring. :P

		Mukund

---

From: Brian Hartvigsen <[email-masked]>
Date: Mon, 9 Jan 2017 15:19:11 -0700

> 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.

Thought I should point out that Cisco (previously OpenDNS) also has IPR in this area (tmk predates Xerocole.)  Not sure if there is anything to be done at this time, but just thought I should put that out there.

.:|:.:|:.
Brian Hartvigsen
Manager, Site Reliability Engineering
Cisco Umbrella