[Ietf-not43] off-list comments on requirements

[Eric Brunner-Williams in Portland Maine]

Andy,

I'm trying to "stay out" of the !43 design space, so ignore anything
that is predicated upon profound ignorance.

> 1) The internationalization considerations section should
> state that names of attributes or tags (or whatever you wish
> to call them, and this will probably vary depending on the
> final set of technologies used) should be displayed according
> to a users locale and the values must be able to support
> internationalized content.  (why start with an easy one :) )

This is posing i18n as a presentation probem. You may. I prefer to ask
"what does this mean if the encoding is EBCDIC?" to help me through to
the perfection of blindness. Characters can be distracting. If you are
going down the UNICODE path, don't indicate it by design indirection.
Locale has a specific meaning (see XPG 3 where we defined it, for better
or worse, in a world pre-UNICODE).

> 2) The text restricting the scope of domain registries in
> section 2.1.4 is too vague.  Language is needed to stipulate
> the association of a domain registry with a gTLD or ccTLD.

Your call, not mine, but why wouldn't the implementor(s) of the server
and clients using same at the delegation "whois-not43.wabenaki.net" be
interested in using "TLD tech" for an SLD? Ask Scott about this one, I
recall we (provreg) got an IESG hit on overspecification on just this
point.

> 7) As a general note, the draft does not specify what should
> be in contact data or operation data... or in other words, help
> specify what will eventually be the contents of the schemas.
> I don't know if the requirements draft is the right place for
> this information.

If not-43 provides no necessary operational service to network operators
(and similar), then perhaps no technical contact is needed. FYI, in the
:43 list I've suggested that no registrant contact is needed, as :43 is
for the necessary operational service to network operators (and similar).

We discussed the "thick vs thin" (where's authoritative state) registry
model when on this point in provreg (social vs technical data), see the
attempt by Ross Raeder at the problem in the provreg definitions doc.

Eric