>>>>> On Mon, 26 Mar 2012 07:57:59 +0000, "Livingood, Jason" >>>>> <jason_living...@cable.comcast.com> 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]. 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. 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) -- Wes Hardaker SPARTA, Inc. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
