On Apr 10, 2012, at 8:11 PM, Wes Hardaker wrote: >>>>>> On Mon, 26 Mar 2012 07:57:59 +0000, "Livingood, Jason" >>>>>> <[email protected]> said: > > LJ> http://www.ietf.org/id/draft-livingood-negative-trust-anchors-00.txt > > LJ> Feel free to share any other questions or feedback. > > I too like the idea behind it, and have the following suggestions to > support it: > > 1) In addition to the following statement: > > Furthermore, a Negative Trust Anchor should > be used only for a short duration, perhaps for a day or less. > > I'd go ahead and insert MUST/SHOULD/MAY language as well (realizing > that if there is a document people will ignore it in, this is likely > to be one). And then add some timing constraints too [reading the > rest of the thread after typing this, I note that Shane also > suggested an end time, but the proposal below also imposes a maximum > end-time allowable].
Perhaps a TTL equivalent as previously suggested, I agree we should look to add the MUST/SHOUD/MAY language for this. > Suggested rewrite: > > Furthermore, a Negative Trust Anchor MUST only be used for a > short duration, perhaps for a day or less. Implementations MUST > require an end-time configuration associated with any negative > trust anchor. Implementations SHOULD limit the maximum time into > the future to one day. In other words, the configuration > directive will be invalid if it is missing an end-time or if the > end time is greater than "now" plus 86400 seconds. Agreed. Maximum time supported makes sense to me. > > 2) I also suggest you rename the concept to "Negative Anchors of Trust" > and then sprinkle the document with statements like the following: > > NATs are not an appropriate long-term solution and if they need to be > used, they MUST be used only for short periods of time. > > (it's the two-birds-with-one-stone theory of RFC writing) I got a good chuckle on this one. We will have to think hard about this :-) Thanks Chris _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
