Hi Steve, I've reviewed the document and made a bunch of comments in the attached copy. I'm really concerned about one thing however. It seems to be a foregone conclusion that the priming response data must be fully DNSSEC-validatable. Every proposed naming scheme other than "current" talks about fully signed data. The document makes vague references to DNSSEC protecting resolvers from "various name-based attacks" but does not say what these attacks are. There might be legitimate attacks but I don't think they are data integrity attacks. I'd like to see more discussion on the tradeoffs of a validatable vs unvalidatable priming response. For some naming schemes adding DNSSEC increases complexity. I think it would be useful to know how current recursive name server implementations behave with respect to setting DO=1 in their priming queries, if they do any validation of the response, and if so, how they handle a bogus response. The document devotes a lot to concerns about the size of a priming response. Perhaps RSSAC should recommend a specific upper limit on priming response size, which could then be used to evaluate the various naming schemes.