To: ICANN
From: NeuLevel (formerly JVTeam)Comments on Report on New TLD Applications
– Appendix B, Summary of JVTeam .per Application
NeuLevel (previously known as
JVTeam) commends ICANN for the thorough evaluation performed by the ICANN staff and
review team of the new gTLD Applications provided in its November 9th Report on New
TLD Applications. In the interest of providing ICANN and the Internet community
with information related to areas in which the reports suggests clarification or
elaboration is required, we would like to offer the following comments to the summary
of NeuLevel’s .per Application authored by the review team and found in Appendix
B of the Report. Consistent with the open and transparent manner in which the
selection process is being conducted, we are posting these comments to the ICANN
Public New gTLD Comment Forum.
The following comments are prefixed by the section
heading of the Summary to which they refer.
B.1 Use of SLD in lieu of multiple
sub-domains for family and surname: We are open to alternative structures for a personal
name space, such as .per. Our reference to structuring it as an SLD is simply
the initial proposed default structure. A number of interesting concepts exist
to provide structure and increased access to desirable names while also providing
uniqueness to a personal name space. These include the use of multiple levels
as name separators, geographic or cultural SLD specifiers, and use of certificate
identifiers or postal codes as uniqueness numbers. We propose to work with
ICANN and the internet community to finalize a suitable structure for a personal
name space. We think that developing a personal name space meeting community
needs would be of significant value in the long run and also requires some flexibility
in the ultimate structure in order to achieve that goal.
B.2.d Co-active SRS Data
Centers: The databases in each of the two SRS data centers (existing
NeuStar owned and operated facilities in Chicago, IL., and Sterling, VA.) are both
active for updates. Commits to the logical database from an SRS application
process are simultaneously posted to both physical database servers using a distributed
two-phase commit protocol that guarantees that the update is posted to both copies
in a synchronous real-time fashion. Please see Section III.2.13.1 of our Application
for more information.
B.2.e Security: The billing and collection system, consistent
with the rest of the SRS, utilizes advanced security measures including digital certificates
for strong session authentication, and object-level signatures for strong authentication
and non-repudiation of critical transactions requiring multi-entity authentication
(e.g. transfers). Please see Section III.2.6.2 of our Application.
In addition, individual userids and passwords are employed to identify individual
registrar personnel in transaction logs. NeuLevel will generally employ extensive
military-grade-style security technologies, including biometric systems for physical
data center access, and physical security token authentication (e.g. smartcard) for
remote administration access, consistent with existing practices of its parent companies
(NeuStar and Melbourne IT). But more important than the technology, we subject
ourselves to regular Code of Conduct audits which include an audit of system/data
security measures to ensure not only consistent security policy implementation but
openness and transparency of our adherence to these measures.
B.6 XRP Protocol:
The new proposed registry-registrar protocol in our Application is called extensible
registry protocol (XRP).
B.6 gTLD structure and impact on caching: As mentioned
in our comment to B.1 (above), some further development and trailing of structures
for a personal name space such as .per are appropriate. We agree that one of
the many considerations in addition those mentioned in B.1 is scalability.
Caching behavior has a significant impact in DNS scalability. However, we believe
that many of the potential .per structures, as well as the default SLD structure
proposed, can be established to not adversely impact caching behavior and therefore
ultimate scalability. The statistical behavior of caching of to a personal
name space is comparable to that associated with queries to other individual identifiers,
like telephone numbers, with which we have extensive familiarity.
B.7 Availability
of names and uniqueness suggestions: As commented in reference to B.1 (above), providing
access to an adequate number of convenient names is a key requirement for the ultimate
structure of a personal name space. The proposed default structure of .per
as an SLD provides a uniqueness mechanism to allow users to employ their own names,
and a standardized way for SRS client systems (registrars) to utilize information
provided in XRP responses to present to the user alternative options or variants
where required. We believe that the complete development of these algorithms
should be done collectively with the community of interest (and/or ICANN at its option)
and propose to do so as part of the launch plan for the gTLD in the Application.
NeuLevel
hopes the above comments and clarifications will be of assistance to ICANN in facilitating
a complete assessment. We appreciate the opportunity to respond, and as always, are
available to provide further clarification where needed.
Ken Hansen
NeuLevel