Subject: [Ietf-not43] off-list comments on draft-ietf-crisp-requirements-01.txt

From: [email-masked] (Andrew Newton)
Date: Wed, 16 Oct 2002 13:19:07 -0400

I have been involved in a small off-list conversation concerning the 
requirements document, and Ted has asked that I post the outcome of the 
conversation as it was beneficial and will probably yield two changes 
pending other comments.

It has been suggested that the following language be used to clarify the 
difference between what the requirements specify the protocol must be 
capable of and what registries will have to do in regards to their 
policy.  So it was suggested that the language regarding this be 
appended with an example and read:

   These requirements are for the purpose of designing a technical
   specification. The words used in this section are for compliance
   with RFC2119[8], do not reference or specify policy, and speak only
   to the capabilities in the derived technology. For instance, this
   document may say that the protocol MUST support such feature. An
   actual registry is always free to disable it (and then to return an
   error such as "permission denied").

I agree with this proposed change.

In addition, it was also suggested that the language around the partial 
name search functionality be appended/changed to more clearly articulate 
that a registry might not want to provide this ability.  The following 
language was given:

   The service MUST allow searching for domains by exact name match or
   a reasonable subset of a domain name. The service SHOULD allow
   disabling these "partial match" searches (see the beginning of
   section 3).

My preference is to specify this for all searches, not just the partial 
name search.  So I propose the following additional item to the base 
functions section.

   The service MUST be capable of returning the following types of
   non-result or error responses to all lookups and searches:

   o Permission Denied - a response indicating that the search or
     lookup has failed due to insufficient authorization.
   o Not Found - the desired results do not exist.
   o Insufficient Resources - the search or lookup requires
     resources that cannot be allocated.

Looking at both the LW and IRIS proposals, there could actually be more, 
but I think these are the basic necessary ones.

-andy

---

From: [email-masked] (Rick Wesson)
Date: Wed, 16 Oct 2002 11:39:33 -0700 (PDT)

Andrew,

could you replace registry with "registry/registrar" or find a more
appropiate term so that it it clear that any entity serving data has the
option to determine which fuctionality will be supported.

-rick

On Wed, 16 Oct 2002, Andrew Newton wrote:

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

---

From: [email-masked] (Andrew Newton)
Date: Wed, 16 Oct 2002 14:35:42 -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-27931-1034794254-0001-2
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Very good point.  Should probably be "service operator", meaning anybody 
running a CRISP server or service.

-andy

> option to determine which fuctionality will be supported.

--=_zark-27931-1034794254-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-27931-1034794254-0001-2--