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

Hi David,

This is my personal opinion. As Stephane Bortzmeyer already noted in another message, I would say doing things the IETF way is quite a different matter. If you believe you have the same time frame available to do the KSK rollover design project as it takes to put together and agree upon any protocol within the IETF, fine, but in my opinion you don't have that time. 

Regarding the financial issues, I clearly know what the criteria was, but it is still a fact that it is hard for some people (self-employed, far distant, other reasons) to raise the funding to contribute. I am sure Elise and Kim can brief you on that.

Even if it is of the best interest for the best of the best people to be willing to contribute to a  "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" as you state it, I don't know how I shall interpret that. The biggest benefits will nevertheless be  ICANN's, getting this important work done without having to spend money on designing one of the most important functions that ICANN have, a very important change that will potentially affect the entire Internet, should it go wrong. 
 
I am also disappointed, but for other reasons. Surely, you must be aware that .SE already contributes to ICANN in a number of different ways - including my contribution as a TCR. This has nothing to do with that.

Merry Christmas!

Anne-Marie



-----Ursprungligt meddelande-----
Från: David Conrad [mailto:drc at virtualized.org] 
Skickat: den 16 december 2014 22:17
Till: Anne-Marie Eklund-Löwinder
Kopia: KSK Rollover SOI; dns-wg at ripe.net; <dnssec-deployment at dnssec-deployment.org>
Ämne: Re: [dns-wg] Solicitation for Statements of Interest regarding Root KSK Rollover

* PGP Signed by an unknown key

[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)

* Unknown Key
* 0xF4FF8AD7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 182 bytes
Desc: not available
URL: </ripe/mail/archives/dns-wg/attachments/20141219/6349fda6/attachment.sig>