[dnssec-key-tf] explaining the IANA requirement letter

Someone elsewhere asked for clarification about requirement 1, re: 
technology neutral.  Here's what I wrote in response (stealing briefly 
from a note from Peter).  Feel free to let me know if you disagree, 
and feel free to steal the text for other things:


I think the requirement re: technology neutrality means at least two 
things:

First, the TAR should not exclude trust anchors based on crypto 
algorithm, key length, status of the SEP bit, use of the keys (e.g. 
separation of ZSK & KSK functionality), or similar reasons, so long as 
the trust anchors reasonably conform to the specifications.  More 
requirements might be imposed by other parties or community consensus, 
but the TAR operator shouldn't be doing such on its own. The TAR 
operator might provide some helpful support ("er, are you sure you 
want to do that?"), but it shouldn't be making up rules.

Second, the publication mechanism(s) and format(s) should not favor or 
disfavor any particular use of the trust anchors, as much as possible. 
It would be unacceptable to have the only mechanism for accessing the 
TAR require particular code (e.g., rsync, which doesn't have 
_independent_ interoperable implementations, or a particular 
resolver).  And it would be unacceptable to use only an (uncommon) TA 
format that is not boardly supported (e.g., a configuration file for a 
resolver that, due to design, needs less information on each TA than 
other resolvers, meaning that it might not be trivially transformed 
into a config file for other resolvers). I think both IANA and most 
members of the task force are envisioning IANA's repository being 
formatted either as DS records or as config statements for common 
DNSSEC resolver(s) and published AT LEAST in some bulk distribution 
mechanism (e.g., a signed file or tarball, available over ftp or/and 
http), which easily meets this requirement.

-- Sam