Subject: [Ietf-not43] Proposed charter

From: [email-masked] (Ted Hardie)
Date: Thu, 25 Apr 2002 15:24:59 -0700

Howdy,
	Based on the discussions we've had since the last IETF, I
believe that the scope of the CRISP work has been narrowed to a focus
on DNS-related registries, registrars, and registrants.  Though I
believe that there is value from a user perspective for a more general
approach, I believe that deployment of such services is unlikely among
other infrastructure registries using similar administrative directory
services.  Given that, I have put together the following straw
charter, which is narrower in focus than those discussed at previous
BoF sessions.  Comments to the list are welcome.
				regards,
					Ted Hardie

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
  standard service.

Goals and Milestones:

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

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

---

From: [email-masked] (Eric A. Hall)
Date: Fri, 26 Apr 2002 10:08:39 -0500

[note to list, not43 comes from lists.verisignlabs.com now, in case you
need to update your filters]

Ted Hardie wrote:

> selection.

As stated earlier, there are considerations with the core schema which
make an isolated design impossible, or unusable to the point of not
bothering to try.

What I would propose is that the WG separate the core protocol and core
schema into a standards-track document, and that we publish whatever
supporting schema we think will be needed as secondary specs, with those
schema being on a standards-track or informational as appropriate. If the
interest picks up, the informational specs can be edited/replaced by the
external parties and the core won't be affected. This approach will also
help as we introduce more schema later. I am noodling with a user-locator
schema to address one of Leslie's concerns, for example.

Using the LDAP-WHOIS model as an example, this would mean a core spec
which defined the service (top-down vs bottom-up searches, namespace
delegation, etc) and the main scheme (inetResources), while the other
object classes (inetDnsDomain, inetIpv4Network, inetIpv6Network, and
inetAsNumber, plus whatever new ones) would be defined in separate specs.
The core and inetDnsDomain schema would be standards-track, while the
others would be informational.

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

---

From: [email-masked] (Andrew Newton)
Date: Fri, 26 Apr 2002 13:01:27 -0400

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zark.ecotroph.net-21259-1019835201-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> need to update your filters]

Sorry about that.  It would seem a certain sys admin made some
modifications to the list server without notifying us (not the least of
which was taking me off the list inadvertently).  If anyone is
experiencing any other problems, please let me know off-list.

> schema to address one of Leslie's concerns, for example.

I don't think anybody is suggesting we don't take a layered approach. 
However, a charter for a general framework will not fly with the IESG
(so I'm told).  We need to charter for solving a problem.  A general
framework does not solve a problem, it is merely a smart approach to a
solution.

Given the following from the charter:

> While the framework created will

I think this strikes the right balance between we have an immediate
problem we want to solve (domains) while saying "we aren't going to be
so narrow that we come up with something that cannot even solve related
matters" and at the same time say "we aren't going to be so broad as to
be considered fixing the entire universe."

There has to be balance.  And we cannot propose a charter for a solution
looking for a problem to solve.

-andy
--=_zark.ecotroph.net-21259-1019835201-0001-2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--=_zark.ecotroph.net-21259-1019835201-0001-2--

---

From: [email-masked] (Eric A. Hall)
Date: Fri, 26 Apr 2002 12:21:54 -0500

Andrew Newton wrote:

> > What I would propose is that the WG separate the core protocol and
> > core schema into a standards-track document, and that we publish
> > whatever supporting schema we think will be needed as secondary
> > specs, with those schema being on a standards-track or informational
> > as appropriate.

> framework does not solve a problem, it is merely a smart approach to a

I'm not suggesting that the additional schema or that a framework be
specified as a charter. I'm suggesting that we define two deliverables,
one of which is the core proto/schema, and another of which is the
inetDnsDomain schema. Furthermore, I'm suggesting that we (or me, if
that's the politically expedient method) publish the ancillary schema as
informational so that the core schema can reference the data-types when it
needs to do so.

Is that workable?

---

From: [email-masked] (Andrew Newton)
Date: Fri, 26 Apr 2002 13:48:15 -0400

--=_zark.ecotroph.net-21851-1019838009-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> informational so that the core schema can reference the data-types when it

Sorry for the misinterpretation.  I think the two deliverables is
workable.

-andy
--=_zark.ecotroph.net-21851-1019838009-0001-2

--=_zark.ecotroph.net-21851-1019838009-0001-2--