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

[Andrew Newton]

Eric,

These are all interesting points.  My comments are in-line:

Eric A. Hall wrote:
> 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.

The intent was to have a structured syntax of tagging the data so that 
the tags themselves could be localized.  You are right that it doesn't 
read correctly.  The last sentence should probably be: "The schemas MUST 
be able to express data elements with identifying tags such that the 
identifying tags may be localized."  In other words, the OID or tag name 
or whatever for "telephone" or "city" can be localized to English, 
German, Japanese, or whatever.

> 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."

I find this to be too broad.

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

I disagree.  First, I don't think 3.2.3 goes as far to be that broad. 
Second, I don't think such a thing is implementable in a meaningful, 
interoperable fashion that would be agreeable to a significant amount of 
registrants or registries.

While I agree it would be interesting, I don't think it is possible.

> 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."

Now I do agree with this.  Good idea.

-andy