[Crisp] Questions re adoption and future of IRIS protocol and IRIS dependent services

["Carl Taswell" <[e-mail]>]

Thanks to all of you who responded to my previous email. I hope that all
interested will continue the discussion. 

In essence, my questions relate to the future of IRIS and the rate of
adoption expected by its original creators and developers. This email is
intended to provide a summary of current status together with my questions
which follow.

OPEN SOURCE IMPLEMENTATIONS: No currently active projects. The initial pilot
project led by David Blacka at Verisign has information at

http://www.verisign.com/research/Internet_Registry_Information_Service/index
.html

with code available at

http://svn.verisignlabs.com/main/iris/

Another pilot project reported by Andrei Robachevsky has information at

http://www.ripe.net/db/iris-pilot/

Both David and Andrei have indicated that there is little if any interest in
maintaining these projects. Further searches at codeplex.com and
sourceforge.net return, respectively, two and seventeen different projects
all with the name IRIS but none of them are related to the IRIS of IETF
CRISP.

COMMERCIAL IMPLEMENTATIONS: Marcos Sanz reports that DENIC will make
available DCHK-type service as soon as it reaches RFC status. DENIC provides
information on IRIS at

http://www.denic.de/en/faqs/detail_152.html

Implementation of DCHK-type service implies use of IRIS Core (RFC 3981) and
DREG (RFC 3982). Also, Sven-Holger Wabnitz reports that DomiNIC plans to
offer IRIS service, but apparently, there is not yet any public announcement
at their web site at

http://www.dominic.de/

since a search there returned no results, and standards implemented in the
product description do not yet mention any of the IRIS protocols (unless I
missed something).

GENERAL QUESTIONS:

1) For those of you who have been active in the CRISP Working Group, do you
remain optimistic, pessimistic, or neutral about the future of the IRIS
protocol and services?

2) For those of you who are active at registrars, do you expect the rate of
adoption of the IRIS-dependent services to accelerate or continue at the
current pace?

SPECIFIC QUESTIONS:

3) Marcos and Sven-Holger, could you please make more explicit the complete
list of IRIS related RFC standards that your companies will be supporting
with products or services?

4) Andy Newton explains that the lack of code modularity for common content
such as contacts was purposeful in order to prevent dependence of different
developments and thereby delays. While I understand the rationale in the
past, I also see the need for revisions in the future. Yet April Marine
reports that the Working Group will conclude its work with DCHK. So how will
any necessary revisions be pursued? From my perspective with my goal of
building new and different registry types as extensions of the existing
foundation of IRIS protocol and services, it does NOT make sense for all of
the registry types to each have individual and separate declarations for
contacts because it risks loss of interoperability for exchange of contact
information. Presumably interoperability is a major goal of any standards
effort. So how can revisions with a re-factoring of the contact information
into a separate module be pursued if the Working Group is terminating its
work? Is it necessary to create a new Working Group? Or can the current
Working Group be continued?

5) Since I have not been an active contributing member of the Working Group
in the past, I am not familiar with how it does its work. Stephane
Bortzmeyer rightly points out that my question about DREG2 has not yet been
answered. If somebody familiar with the story of why DREG2 "went dead" could
please offer a few words of explanation that might also shed some light on
the matter in a way that would give me a better understanding of how to
promote the revisions discussed in the previous question. So what did happen
to DREG2 and why?

Thanks in advance to all of you,

CT

-------------------------
Carl Taswell
Cel: 916-616-4939
Tel: [phone]






_______________________________________________
Crisp mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/crisp