[dns-wg] Solicitation for Statements of Interest regarding Root KSK Rollover

[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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/dns-wg/attachments/20141216/ee1b5ddd/attachment.sig>