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