[dnssec-key-tf] Agenda for Monday

On 18.10 08:56, Jim Reid wrote:
> We really should have an agenda for the meeting on Monday. Any  
> suggestions? My thoughts on this are:
> 
> [1] TAR - yes or no?
> 	The WG was split down the middle on this in Tallin and IMO our TF  
> has yet to consider this issue in detail. The TF discussions so far  
> have tended to work on the assumption that a TAR should exist, which  
> is not a representative view.
> 
> [2] What properties should a TAR have?
> 	Trusted, neutral, etc. I think we've got a rough consensus here.
> 
> [3] What format should the TAR data be provided?
> 
> [4] What processes are used for verifying new or updated trust anchors?
> 
> [5] What are the performance indicators/metrics for a TAR?
> 	ie When can it be judged a success or failure and when can it be  
> shut down
> 
> 
> Maybe we just decide to do the crossword and wait to see what Richard  
> Lamb has to say during the plenary? :-)

I suppose he is going to talk about the 'demo' service at
https://ns.iana.org/dnssec/status.html
and its associated port 53 service.

I have already sugested to invite Richar and anybody else from IANA
to our meeting. Shall I do this if in case Jim is too busy?

> We can of course discuss these topics on this list. And in some ways  
> I'm trying to provoke that discussion. But if we could give some  
> thought about how to productively use our time together on Monday...

To repeat:

IANA is alread offering a service that very much looks like what the SE
people asked for. 

IANA is the best place to do this because it is at the right place in
the DNS tree to do this without the danger of creating a separate trust
hierarchy. 

As to productively using time:

We should use our time to learn about this service and discuss the
questions 2-5 in the light of giving suggestions to the IANA. 

We should also draft a statement that (the) RIPE (DNS WG) could adopt
welcoming and endorsing this initiative by the IANA and re-inforcing it
by stating that we will not take our own initiativesin this area as long
as this service remains available while the root is not signed. 

Daniel