Subject: [Ietf-not43] revised charter

From: [email-masked] (Ted Hardie)
Date: Wed, 8 May 2002 10:16:14 -0700

Based on the discussion of the proposed charter, I've
updated the text to reflect splitting the deliverable
into a protocol framework document and a schema document.
I'd like to send it up to the ADs on Monday, so I'd
appreciate comments by the end of the week.
			thanks,
				Ted

Cross-Registry Information Service Protocol (CRISP)

Chair:  

Ted Hardie <[email-masked]>

Applications Area Directors:

Patrik Falstrom <[email-masked]>
Ned Freed <[email-masked]>

Mailing list:

[email-masked]
Archive/Subscription:
   https://lists.verisignlabs.com/mailman/listinfo/ietf-not43

Description of Working Group:

The expansion and growth of the Internet Domain Name System has seen
the functions of a traditionally centralized and managed registry
become the responsibility of various autonomous, functionally
disparate, and globally distributed Internet registries and
registrars.  With that expansion, the uses of administrative directory
services has also expanded from the original use of the WHOIS protocol
to include: the use of whois outside the scope its specification;
formal and informal definitions of syntax; undocumented security
mechanisms; the use of non-standard protocols, etc.  The existing
situation seriously hinders interoperability from a registrant
perspective, as multiple systems and procedures must be used for
different registrars or registries.

This working group will define a new standard service to meet the
administrative directory needs requirements of DNS registrants,
registrars, and registries.  While the framework created will
hopefully be sufficiently flexible to allow re-use by other services
with related design criteria, those uses will not constrain protocol
selection.  Backwards compatibility with existing administrative
directory services such as WHOIS is not a goal of this effort.
Provisioning of data into registry or registrar systems is likewise
out of scope.

The CRISP service definition will define: 

o specific data types and queries to be supported in the global service

o standard process for naming or locating authoritative servers 

o expression of input query 

o expression of result sets 

o standard expression of error conditions 

o authentication and verification of data integrity

Deliverables: 

o Finalized requirements document for the CRISP service

o Document specifying (the use of) a protocol for providing CRISP
  service.

o Document specifying required schema elements for domain registration
  administrative directory services.

Goals and Milestones:

 Oct 02    Submit requirements document as an Informational RFC 
           
 Nov 02    Submit first draft of protocol (use) specification

 Nov 02    Submit first draft of domain registration administrative 
           directory services required schema element specification.

 Apr 03    Submit revised protocol (use) specification document
           as Proposed Standard.

 Apr 02    Submit revised draft of domain registration administrative
           directory services required schema element specification
           as Proposed Standard.

 Apr 03    Enter FIN_WAIT

---

From: [email-masked] (Eric A. Hall)
Date: Wed, 29 May 2002 13:08:51 -0500

Where do we stand on this?

Ted Hardie wrote:
> _______________________________________________
> Ietf-not43 mailing list
> [email-masked]
> http://lists.verisignlabs.com/mailman/listinfo/ietf-not43

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: [email-masked] (Ted Hardie)
Date: Wed, 29 May 2002 12:51:25 -0700

Eric,
	Patrik has seen the draft and sent it around
for informal review.  As far as I know, he has not
asked the secretariat for an IETF-wide call for comments.
	Patrik has had some questions on the draft,
most of which seem to our language around the protocol.
In particular:

1) our language does not make it clear to him that there will be a
mandatory-to-implement protocol.

2) the relationship of the protocol and the schema is not
quite clear enough.

	Other questions are:

3) whether the requirements are registrant-registry only as a
protocol or would also includ registry-registry communications.

4) how reusable this will be and when the best time would be to get
other uses scoped.

	Based on the discussion we had on the mailing list,
I have sent some replies to him clarifying things as best
I can.  I have so far not seen objections that objected
to the work in and of itself, but the scope of the
work is, of course, a main part of any IESG discussion
of a working group's charter.
			regards,
				Ted Hardie