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
