Re: Epp - Contacts

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

Ross,

I appreciate that there are registrars, and there are registrars. Some will
insist upon a unique end-point identifier for <insert communication layer>,
for <insert reason>, some will not. The same applies to registries. It is
a business, not a protocol design, decision, which entities will or won't
proffer or accept multiple instances of contact data.

How difficult is multiple, ordered, instances of end-point identifiers for
<insert communication layer> operationally? That depends on the operational
requirement, neh?

	- if for "validation" (lowest cost to assert opt-in to some policy,
	  or discard), then unique beats non-unique, though none has some
	  advantages over unique,

	- if for "contact" (discard avoidance communication set-up), then
	  unique constrains registrants to "address transparency" [1], and
	  violates the principle of informed consent to bind registrants
	  to registry policy.

If the point isn't to "contact" the registrant, but to "validate", then the
change required is renaming the draft from "contact" to "validate", and to
make the corresponding changes to the text of the draft.

If it is contact, then it is a business decision how sloppy anyone in the
provreg chain gets, and who deals with marginal or simply bizarre middlemen
or the odd registry.

It is commic that ISP failures, or area code renumbering, or "forwarding"
offered by postal system, should have MANDITORY TO IMPLEMENT contact data
invalidation semantics.

The handwaving was nice, and I especially enjoyed the bit about subtle thin
lines and etiquette, but try to address the protocol problem:

	is there a case for uniqueness? (clearly there is for finiteness)
	if so, offer it. if not, then the upper limit on multiple instances
	of foo is tbd, by working group process.

The issue I see as controlling is the use case -- upon policy condition,
e.g., legal requirement in some jusrisdiction, operator must perform bulk
contact. For every thousand {s-mail,e-mail,voice,fax} items sent there are
returns. A brain-dead "protocol" requirement that no alternate address can
exist means the operator must terminate or otherwise modify service to the
registrant, pursuant to the original policy condition.

This imports all the marginal service already available to data and postal
carrier customers into the DNS, making name resolution less reliable, for
reasons entirely external to the catanet model.

The second controlling use case is a truely authenticating end-point
identifier, which may have little semblance to the ordinary contact
end-point identifier, resembling more the legally required agent for
a corporation. In this case the (brain-dead "protocol") uniqueness
requirement prevents registrants from providing authenticating contact
addresses, similar to the pgp public key servers, or other means to
authenticate, though not necessarily to directly communicate with, a
registrant.

Eric

[1]	a "service" offered by carriers, also a form of denial of service.

P.S.	NeuLevel may drop Tucows tickets in the bit-bucket for reasons other
	than marginal quality, which would solve your problem, neh?