> A hard failure seems prudent, otherwise the server might publish an > unacceptable (to the child's policy) RRSIG.
This is inconsistent with the (wrong) "choice" forced on PROVREG by some process adverse person, for an optional (thank Dog) client policy bit to force a client policy on a server, independent of the server's manditory policy announcement, or the ability of the server to negotiate (albeit clunkily via session tear down and setup with one or more alternatives). Consistency is the hobgobblin of little minds, and I'm happier with the hard failure semantics than the child (or client) binds on the parent (or server) semantics we get (optionally) stuck with on data collection. <p3p_hat="on> We looked at the problem of putting a temporal guarantee on policies too, more to prevent the overhead of re-evaluation and to prevent silent revocation than any other reason. If I remember anything I think was useful, I'll post it. Eric . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
