<<<
Chronological Index
>>> <<<
Thread Index
>>>
FW: FW: [ga] FYI: .org applicant comments (long)
- To: "Ross Wm. Rader" <ross@tucows.com>
- Subject: FW: FW: [ga] FYI: .org applicant comments (long)
- From: "Karen Elizaga" <karen@elizaga.name>
- Date: Thu, 12 Sep 2002 21:10:56 +0100
- Cc: "DNSO General Assembly" <ga@dnso.org>
- Sender: owner-ga@dnso.org
- Thread-Index: AcJaUJewB+Nt4d5lTj29A/rFnkjoGQAFQPnw
- Thread-Topic: FW: [ga] FYI: .org applicant comments (long)
Dear Ross,
Thank you again for your follow up. I think there has been a bit of a misunderstanding here, which I hope this email clarifies. We stated that we developed only the C++ version of the EPP toolkit and extensions to the Java version in response to specific questions posed by ICANN that required us to support our technical capabilities. We made this statement with good conscience because our developers, in fact, did develop those specific codes. While we might have been able to state our accomplishments in a different way to recognize the efforts of others (which we do), in an effort to highlight our technical capabilities (the purpose of the response to ICANN), we thought it appropriate to indicate that, in fact, our developers have contributed significantly to new and important protocols. In light of ICANN's examination of our technical capabilities, this was essential. In another context, there is no ego - together with others, GNR's development team contributes to progress on Internet standards and demands neither "ownership" or "rights" to its work product, as evidenced by its various postings on SourceForge.
It must be understood, furthermore, that there is actually a very small group of technical developers who have been continually committed to the EPP standardization effort. We did not intend to, and I do not think the comment we made, diminish the efforts of those others involved in this process. We, like you, envision a new protocol that is universal, rather than proprietary to each separate registry.
> The epp-rtk project finds its roots in the broad agreement that it didn't
> and doesn't make a ton of sense to have 7 new registries running 7 new
> policy sets with 7 new protocols and 7 new interface toolkits. There are a
> number of people and corporations that set out to address this from a
> technical perspective. Verisign, GNR, Afilias, Tucows, Rick Wesson, Eric
> Brunner-Wiiliams, Marshall Rose, Bruce Minor and dozens more have left their
> mark on various aspects of this loosely defined effort.
In the effort to create an EPP client standard, there were disagreements amongst the participants of the project, which resulted in GNR and Liberty (now Afilias) continuing almost exclusively on the development of the APIs that had been discussed up to that point. Consequently, GNR and Liberty agreed that they would publish their respective work on SourceForge in the hope that their efforts would actually be implemented as the EPP standard across registries.
What you perceive as a "loosely defined effort" in this regard is actually very clear from our point of view:
1. Liberty contributed a Java toolkit.
2. GNR contributed a C++ toolkit and Java extensions to enhance its universal applicability.
3. Both parties continue to work with others, update the respective parts of the toolkit and coordinate changes so that new aspects of the solutions function as similarly as possible.
4. We continue to support the idea that the standard should be made available universally but understand that we are not in a position to foist such a standard unto other organizations.
> My point is not to
> diminish GNR's contribution to the EPP R/RTK initiative, but simply to point
> out that "...concerns about "rights" and "ownership" ... are inappropriate.
> It is appropriate to be concerned about "responsibilities" and "service" to
> the community." (apologies to Postel). Or perhaps more succinctly, as Eric
> Raymond points out[1], "according to the standard open-source licenses, all
> parties are equals in the evolutionary game."
>
> Given the time that Neulevel, Afilias, Verisign, GNR and others have devoted
> to the development of the protocol, the resources that Afilias continues to
> invest in the public EPP sandbox and the numerous developers (including GNR
> staffers) that make the Universal R/RTK actual living, breathing community
> code, I would simply request that GNR reconsider its public use of language
> like ""We alone have designed, developed and operated most of the SRS
> solutions internally, ranging from the EPP toolkit, protocol independent
> business logic and near-real time updates on DNS..."
Regarding your admonition/request in the last part of your second paragraph, we certainly appreciate all of the thought and contributions made by others on EPP both prior to and during GNR's involvement. However, we also recognize the work of our developers with pride and think that the highlighting development of our internal SRS solutions, our business logic, updates and even their contributions to "community" projects is appropriate in the context in which they were made. As for recognizing the work of others as equals in the evolution of EPP, you are right; we could have done so. However, since two people wrote all of the code for the C++ version (GNR senior developers, Vidar Hokstad and Asbjorn Steira), and recognizing our need to respond to ICANN in as meaningful a way as possible, we perhaps may have made the following statement:
"We have independently designed, developed and operate most of our SRS solutions internally, ranging from the protocol independent business logic and near-real time updates on DNS; moreover, while we recognize the efforts of all of those involved in EPP development, our internal developers independently developed the code for the EPP C++ toolkit and extensions that allow the Java version to work for .info, .name, and even .biz and .us."
Again, in an evaluation context, we believe that this is appropriate. To pick a few words out of our submission of 10 pages and to impugn a negative motive seems inappropriate and actually, I think, does diminish GNR's contributions. It also undermines the commitment of our developers who have never asked for that recognition and instead have offered up their talents (and continue to do so) without demanding "ownership," "rights," or anything else for that matter, in return.
I also would point out that "the numerous developers" you cite actually consist of seven people, of which three (Dan Manley, Lee Yin and Asbjorn Steira) continue to make significant contributions to the current codebase. We also note that the SourceForge mailing list illustrates fantastic participation by individuals like Rick Wesson and Scott Hollenbeck, who have provided, and continue to provide, very significant and insightful input.
> As with dotORG, the epp-rtk work also finds its roots in a community - some
> of the same sensitivities must be kept in mind.
We agree with you on the ideal of community, and our developers have worked hard with others who have shown willingness to participate in this effort. Unfortunately, the original concept of "community" around the epp-rtk fell apart in the summer of 2001 due to the disagreement I cited above, but which I will not get into here. Our team will continue to contribute to this effort. While I agree that the EPP project should find its roots in community, we should nonetheless recognize the individuals like Rick Wesson, Scott Hollenbeck, Dan Manley and the GNR developers who actually have continued to make significant and meaningful contributions to this project and to the development of new standards.
Regards.
KE
Information contained herein is Global Name Registry Proprietary Information and is made available to you because of your interest in our company. This information is submitted in confidence and its disclosure to you is not intended to constitute public disclosure or authorization for disclosure to other parties.
*****************
What's your .name?
Get one at www.name
*****************
--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|