1 something. I also believe it should scale as to the size of the subscription base in some way. Basically, this should answer the question of “ given a set of subscribers of size N, a per request failure rate of f, a retry time of R, how long do you have to wait until P% of the subscribers have had a successful query?”
So with P == 99.99%, R being the fast retry time, f being 5%? And N being 10M, it should be possible to calculate how long to wait. Basically a cumulative distribution function. When I get back to my laptop, I’ll check in with excel and see if I can give you an idea of what this looks like. That gives you a reasonable lower bounds for the uptake AFTER dealing with expiring old records and reprents N resolvers doing their last query to validate the new trust anchor. I estimated it as a log function time retry time in an earlier email. Later, mike On Fri, Nov 17, 2017 at 13:27 Bob Harold <rharo...@umich.edu> wrote: > On Thu, Nov 16, 2017 at 8:33 AM, Matthijs Mekking <matth...@pletterpet.nl> > wrote: > >> Wes, >> >> My preference is to include safetyMargin and have text to explain it >> exists because of network delays etcetera, and also reference to RFC 5011's >> retryTime. So that's some mix of 1B 1C or 2B I guess :) >> >> Best regards, >> Matthijs >> >> >> On 15-11-17 02:49, Wes Hardaker wrote: >> >>> >>> The discussion has been long with respect to the safetyMargin in the >>> 5011 security considerations document. There hasn't been a huge >>> conclusion and many different ideas have been floated by, and we're now >>> at the point where we need to pick between them. Below, I try to lay >>> out the primary and sub-options available based on discussions so far. >>> Please provide your opinions on your preference so I can wrap up this >>> draft. >>> >>> Background: This document is not intended to provide operational >>> guidance on what you SHOULD do. It's intended to draw the timing line >>> below which you MUST NOT venture. The safetyMargin was introduced to >>> prevent race conditions based on network delays, eg, which can mean that >>> a RFC5011 Resolver operating at the same time as a PEP Publisher making >>> a change at exactly at the minimum addWaitTime or addWallClockTime >>> values would lead to a failure. So the primary question today is "how >>> do we want to deal with this issue of real-world speed-of-light and >>> other issues?". To complicate this a bit further, packets are never >>> guaranteed to be delivered and network losses can entirely prevent a >>> 5011 Resolver from succeeding at all for a given operation. >>> >>> Option 1. Include a safetyMargin of some value. >>> >>> 1A) safetyMargin = MAX(2*TTL, 1.5Hr) -- current draft >>> >>> 1B) safetyMargin = something based on the retryTime, >>> (an example solution was suggested by MSJ) >>> >>> 1C) Your value here >>> >>> Option 2. Don't include a safetyMargin >>> >>> 2A) Just ignore the issues entirely >>> >>> 2B) Explain that this document does not cover operational >>> complexities like retries (already in the -07 version), >>> network delays and other operational issues. >>> >>> >>> After thinking about this for far far too long, I've now switched my own >>> opinion to that of 2C for the principal reason that this is the >>> line-in-the-sand document, and to be honest people should be using >>> values much larger than this, per MSJ's guidance on how 5011 should be >>> used. Thus, it makes more sense to define this as the "MUST NOT go >>> below this line" without trying to be precise about a value that can >>> never be >>> perfectly accurate, by definition. >>> >>> But, forget my opinion. What's yours? If nothing else, pick one of the >>> [12][ABC] options above please, even without any text defining why you >>> think so (until someone pokes you). >>> >>> > I prefer 1A since the reasoning is well documented. > or MAX(1A,1B), but that is more complex for little gain. > > -- > Bob Harold > > _______________________________________________ > 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
