[Ietf-not43] revised charter

[Eric A. Hall]

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/