[Apologies for any formatting weirdness -- having MUA issues]

Hi Anne-Marie,

> who do you expect to be able to participate in the design team ready to serve 
> and during what timeframe in 2015?

People with DNSSEC experience, particularly in areas related to rolling keys, 
who see it in their interests to help design the process by which the root zone 
KSK will be rolled in a safe, secure, stable, and resilient manner. Similarly 
to the IETF, W3C, other SDOs, etc., presumably those folks would either be 
supported by their organizations or they believe sufficiently strongly in the 
efforts to fund themselves.

> Some of the people with the right experience, involved in the root zone 
> signing (as for example TCR's) already today have trouble finding the money 
> to take part in the key ceremonies every 6th month.

As I've largely been away from this particular world since the root was signed, 
that is both unfortunate as well as surprising.  IIRC, one of the prerequisites 
to becoming a TCR was an explicit acceptance and written assurance that they 
had sufficient support/funding to serve as a TCR. Back when there were 
discussions in the community about the TCRs, one of the considerations was that 
the community felt it might pose a conflict of interest for ICANN to fund the 
TCRs. Since the whole point of the TCRs was to instill trust within the 
community about the way the root KSK was managed, there was (rough) consensus 
that ICANN should not cover the volunteers' travel expenses. As I understand 
it, there is an effort underway to revise the agreement by which the TCRs 
participate to address the issues you raise. It is reassuring to understand 
that the community now trusts ICANN sufficiently to allow them to pay for 
travel expenses to KSK management-related events.

> Expecting professional and experienced people with expert knowledge about 
> DNS, DNSSEC, key management among other things, to be able to spend about 15 
> per cent of their weekly working time without getting paid seems to me a bit 
> optimistic.

Perhaps -- I am widely known as an optimist (:)). An alternative view is that 
experienced people with expert knowledge about DNS, DNSSEC, key management 
among other things are precisely the folks who are likely to depend strongly on 
the root zone KSK rollover being performed correctly and without incident, thus 
it would be in their best interests (and their company's interests) to 
participate, despite not being paid to provide their services to the community.

In other areas of the global multi-stakeholder community, e.g., the various 
ACs, SOs, and their constituencies, and within the IETF, IAB, W3C, ISOC 
chapters, etc., I would note that people often volunteer far more than 15% of 
their time for the benefit of the Internet as a whole (at least as they see 
it). I'll admit some curiosity why you believe being on the design team for 
developing the plan to roll the root KSK is qualitatively different, but I 
imagine it's a matter of perspective.

> Furthermore the criteria states: "Applicants to the Design Team would be 
> representing themselves, not any organization or interest with which they may 
> be associated".

Yes. For sake of simplicity and to try to reduce fears that organizations were 
unfairly "stacking the deck", the decision was made to follow the IETF approach 
of asking people who are participating in this effort to be representative of 
themselves only.

> From my point of view, that should mean that if I don't get support from the 
> organization where I currently work, I will have to pay for my participation 
> from my own pockets, and apply for leave from my duties with .SE while doing 
> this. Even though I am very interested it is impossible financially.

I'm disappointed to hear that and will admit some surprise that IIS does not 
see participating in the development of the root KSK rollover plan which could 
potentially impact the operation of .SE (and every other part of the DNS) in 
their interests.  Again, I suspect it is a matter of perspective.

For clarity, the way in which the KSK design team is being formed is loosely 
modeled after the way the IETF creates design teams for the creation of 
protocols. However, in contrast to the IETF, ICANN has stated that reasonable 
travel expenses can be covered. For a variety of reasons, I do not believe it 
would be possible for ICANN to pay community members for their participation in 
the design team (unless, of course, ICANN were to hire them as contractors or 
some such, but that gets into a whole different set of legalities and 
agreements).

> ICANN did use an experienced design team defining the design for the first 
> root zone signing in 2010, I am a bit curious why ICANN aren't reusing the 
> same design team, given the fact that they already know all about the details 
> behind the choices made in 2010 and that the current design works well.

As I'm sure you're aware, the original design team for signing the root was 
formed from staff/contractors of ICANN, Verisign, and NTIA. Unlike the KSK 
rollover plan development, there was no direct community involvement in the 
design. In the intervening 5 years, a number of the individuals employed or 
contracted by the Root Management Partners have moved on to new positions/jobs 
and thus, the Root Management Partners are unable rebuild the previous team.  
For a number of reasons, including a desire to be more open and transparent, 
the decision was made to ask to have community volunteers participate in the 
design of the rollover plan. It is possible that the organization to which some 
of the original root signing design team now belong could permit those 
individuals to participate as volunteers in the development of the KSK rollover 
plan.  Of course, if none of the community believe it is in their interests to 
participate, then we can always fall back to the previous model.

I hope this clarifies.  Happy to answer any further questions you might have.

Regards,
-drc
(ICANN CTO - sending from my personal address as that's the one that's 
subscribed to the lists)

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to