Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt
Hi Tim On Fri, Jan 06, 2017 at 02:00:39PM -0500, tjw ietf wrote: > 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. 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 signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt
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 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 +, 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 > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt
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 +, 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 signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt
On 1/6/17 9:25 AM, Mukund Sivaraman wrote: > On Fri, Jan 06, 2017 at 01:48:59AM +, 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. > Consequently, if the patented method is strictly adopted, please include > an explanation of why it could not be circumvented. > > Mukund > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt
On Fri, Jan 06, 2017 at 01:48:59AM +, 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. Consequently, if the patented method is strictly adopted, please include an explanation of why it could not be circumvented. Mukund signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt
On Sun, Nov 27, 2016 at 6:10 AM Mukund Sivaraman 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 > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt
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. (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. Mukund signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt
On Mon, Nov 14, 2016 at 12:05 AM, 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. > > > 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). > > W > > -- Forwarded message -- > From: > Date: Mon, Nov 14, 2016 at 1:55 PM > Subject: New Version Notification for draft-wkumari-dnsop-ttl- > stretching-00.txt > To: Warren Kumari > > > > A new version of I-D, draft-wkumari-dnsop-ttl-stretching-00.txt > has been successfully submitted by Warren Kumari and posted to the > IETF repository. > > Name: draft-wkumari-dnsop-ttl-stretching > Revision: 00 > Title: Stretching DNS TTLs > Document date: 2016-11-14 > Group: Individual Submission > Pages: 4 > URL: > https://www.ietf.org/internet-drafts/draft-wkumari-dnsop- > ttl-stretching-00.txt > Status: > https://datatracker.ietf.org/doc/draft-wkumari-dnsop-ttl-stretching/ > Htmlized: > https://tools.ietf.org/html/draft-wkumari-dnsop-ttl-stretching-00 > > > Abstract: >The TTL of a DNS Resource Record expresses how long a record may be >cached before it should be discarded. This document discusses the >possibility of "stretching TTLS" (using them past their expiration) >if they cannot be refreshed. This works on the assumption that stale >data may be better than no data. > >PLEASE NOTE: This document is a strawman to drive discussion. It may >or may not be a good idea; this document documents the idea so that >there is something concrete to throw tomatoes at. > I really like this idea. I would suggest that the resolver should go back up the tree (toward the root) until some level responds, to verify that the zone has not been removed, to avoid 'ghost zones'. So if looking up "host.subdomain.domain.tld" and the servers for "subdomain.domain.tld" are all non-responsive, then query the "domain.tld" servers to see if: 1. The delegation has not changed, in which case extend the ttl 2. The delegation has changed, then go query the new servers 3. The delegation has been removed, then drop the record from the cache. There could be more than one non-responsive level, so the resolver should repeat this at each level back toward the root until there is a response. If the root does not respond, then the resolver should extend the ttl. Separately, since TTL's can vary widely, I would suggest setting a minimum and maximum extension time. If a record has a very short ttl (like 1 second), I would like the option to tell the resolver to extend it by 10 or 30 seconds, to avoid a lot of retries. And if N is 10, do I want a 1 day ttl extended by a day, but a 1 sec ttl extends only to 10 seconds? Or perhaps there is a better algorithm. -- Bob Harold ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt
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. 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). W -- Forwarded message -- From: Date: Mon, Nov 14, 2016 at 1:55 PM Subject: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt To: Warren Kumari A new version of I-D, draft-wkumari-dnsop-ttl-stretching-00.txt has been successfully submitted by Warren Kumari and posted to the IETF repository. Name: draft-wkumari-dnsop-ttl-stretching Revision: 00 Title: Stretching DNS TTLs Document date: 2016-11-14 Group: Individual Submission Pages: 4 URL: https://www.ietf.org/internet-drafts/draft-wkumari-dnsop-ttl-stretching-00.txt Status: https://datatracker.ietf.org/doc/draft-wkumari-dnsop-ttl-stretching/ Htmlized: https://tools.ietf.org/html/draft-wkumari-dnsop-ttl-stretching-00 Abstract: The TTL of a DNS Resource Record expresses how long a record may be cached before it should be discarded. This document discusses the possibility of "stretching TTLS" (using them past their expiration) if they cannot be refreshed. This works on the assumption that stale data may be better than no data. PLEASE NOTE: This document is a strawman to drive discussion. It may or may not be a good idea; this document documents the idea so that there is something concrete to throw tomatoes at. [ Ed note: Text inside square brackets ([]) is additional background information, answers to frequently asked questions, general musings, etc. They will be removed before publication. This document is being collaborated on in Github at: https://github.com/wkumari/draft- wkumari-dnsop-ttl-stretching. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests ] Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
