[Ietf-not43] revised charter

[Ted Hardie]

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







On Wed, May 29, 2002 at 01:08:51PM -0500, Eric A. Hall wrote:
> 
> Where do we stand on this?
> 
> 
> Ted Hardie wrote:
> > 
> > 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 <ted.hardie@nominum.com>
> > 
> > Applications Area Directors:
> > 
> > Patrik Falstrom <paf@cisco.com>
> > Ned Freed <ned.freed@mrochek.com>
> > 
> > Mailing list:
> > 
> > ietf-not43@lists.verisignlabs.com
> > 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
> > 
> > _______________________________________________
> > Ietf-not43 mailing list
> > Ietf-not43@lists.verisignlabs.com
> > http://lists.verisignlabs.com/mailman/listinfo/ietf-not43
> 
> -- 
> Eric A. Hall                                        http://www.ehsco.com/
> Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/