[Ietf-not43] I-D ACTION:draft-ietf-crisp-requirements-02.txt

[Eric A. Hall]

A couple of additional comments on the requirements draft

1) slight rewording of 3.1.3

 | 3.1.3 Standard and Extensible Schemas
 |
 |  The service MUST define standard schemas for the exchange of data
 |  needed to implement the functionality in this document.  In addition,
 |  there MUST be a means to allow the use of schemas not defined by the
 |  needs of this document.  Both types of schemas MUST use the same
 |  schema language.  The schemas MUST be able to express data elements
 |  with identifying tags for the purpose of localization of
 |  internationalized data element labels

The last sentence seems to imply that i18n data is to be expressly
identified when the only real concern is that the service be able to
accomodate this data, whether tagged or not. Localization tagging is
another issue, and that kind of tagging should be provided when the
untagged form would cause corruption.

I would therefore suggest that the sentence be rewritten as "The schemas
MUST be able to accomodate internationalized data elements, and MUST be
able to denote any localized forms of any data which would otherwise cause
interoperability problems."

2) Does section 3.2.3 define a requirement for an organizational lookup,
similar to but different (larger) than the contact lookup as defined in
section 3.2.1? For example, does it mean that rather than finding all of
the domains I may have registered over the years, I need to be able to
find all of the domains that were registered under the name of my company
or one of my clients?

This would involve defining something that could be used as an org-handle
and then finding something to map this onto, which isn't as simple as just
mapping an email address (and even that isn't easy).

I think this is a good idea and an interesting feature which would give
clear benefit over legacy WHOIS. I just want to make sure I'm reading it
as what I think it is?

Can we change this to a SHOULD? I note for effect that section 3.2.5 only
calls for a MAY requirement, and that is existing functionality.

3) I'd like to see a requirement for versioning. In those cases where the
nature of the protocol, schema or data elements need to be adjusted, there
will be a need for end-stations to negotiate or identify the version(s) in
use. I guarantee this will happen. For example, in the case of LDAP-WHOIS,
it may be that the core schema has to be extended, or that a specific
schema associated with a specific resource has to be redefined.

I feel sufficiently strongly about this that I think it should be a MUST
requirement. EG, "Service proposals MUST provide mechanisms for
identifying and/or negotiating the version of the protocol, schema, or
data elements which constitute the service to an extent that any or all of
these may be changed and the service will continue to function."

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