[dnssec-key-tf] Proposed Mesage to IANA

Typos corrected, colloquial wording formalised, easy comments folded in.
Only thing missing is Joao's comment re verification/secure channel.
Looking for guidance there. Did I miss anything else?

Diff only this time, but with context:

------

*** iana-keyrep.txt	2008/04/16 12:34:16	1.3
--- iana-keyrep.txt	2008/04/16 12:42:37
***************
*** 2,8 ****
  Dear Barbara,
  
  thank you for your note about the proposed DS key registry for TLDs. 
! The RIPE DNS working group (DNS WG) force welcomes this
  development. We would like to see IANA providing such a registry as
  soon as possible. As you know we have developed a set of requirements
  for such a repository. As these may be useful for you when implementing
--- 2,8 ----
  Dear Barbara,
  
  thank you for your note about the proposed DS key registry for TLDs. 
! The RIPE DNS working group (DNS WG) welcomes this
  development. We would like to see IANA providing such a registry as
  soon as possible. As you know we have developed a set of requirements
  for such a repository. As these may be useful for you when implementing
***************
*** 10,31 ****
  
  
  [1] The registry should be technology neutral. It should not exclude or  
! prevent different flavours of trust anchors to be published, provided
! provided those trust anchors conform to the relevant standards.
  
! [2] The TAR should be OS/DNS implementation neutral. Tools and  
! documentation should be provided for the common platforms: "here's how  
! to transform this crypto gunk into stuff to plug into your  
! resolver/server configuration".
  
! Comment: IANA should publish such docmentation and tools, or pointers to 
  them. Once we know details of repository, we can help putting together 
  this documentation.
  
! [3] The TAR should verify that the keying material it receives comes 
! from authorised source, verify it is correctly formatted and verify
! it is consisten with what is published in the TLD zone before publishing it. 
! There should also be a secure channel  for authenticating the TAR and any 
  data it is publishing.
  
  Comment: Using the same channels IANA uses to receive update requests to the 
--- 10,30 ----
  
  
  [1] The registry should be technology neutral. It should not exclude or  
! prevent different flavors of trust anchors to be published, provided
! those trust anchors conform to the relevant standards.
  
! [2] The registry should be OS/DNS implementation neutral. Tools and  
! documentation should be provided for use of the repository with common 
! DNS resolver and name server platforms.
  
! Comment: IANA should publish such documentation and tools, or pointers to 
  them. Once we know details of repository, we can help putting together 
  this documentation.
  
! [3] The registry should verify that the keying material it receives comes 
! from an authorised source, verify it is correctly formatted and verify
! it is consistent with what is published in the TLD zone before publishing it. 
! There should also be a secure channel  for authenticating the registry and any 
  data it is publishing.
  
  Comment: Using the same channels IANA uses to receive update requests to the 
***************
*** 38,55 ****
  Comment: An opt-in mailing list for operational news should be sufficient
  to satisfy this.
  
! [5] The TAR should be clear what support, if any, is available.
  
! [6] The TAR must have exit strategy.
  
  Comment: The proposal includes that.
  
! [7] The TAR should only publish keying material with the consent of
       the respective key manager.
  
  Please let us know any the details of the repository as well as the time-line 
  for implementation as soon as they become available. Please feel free to make
! our supoort for this repository known to anyone in the ICANN govenance structure
  if it helps to push this along.
  
  Kind Regards
--- 37,54 ----
  Comment: An opt-in mailing list for operational news should be sufficient
  to satisfy this.
  
! [5] The registry should be clear what support, if any, is available.
  
! [6] The registry must have a published exit strategy.
  
  Comment: The proposal includes that.
  
! [7] The registry should only publish keying material with the consent of
       the respective key manager.
  
  Please let us know any the details of the repository as well as the time-line 
  for implementation as soon as they become available. Please feel free to make
! our support for this repository known to anyone in the ICANN governance structure
  if it helps to push this along.
  
  Kind Regards