Re: Call for agenda items for Minneapolis

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

> Nice to see you jump in on this. You are right, it IS an informational I-D
> as an individual submission to the WG. What do you think?

Registries have policies. Policies can be generalized until one or more
mechanism(s) are identified that allow a class or classes of policies.

We could see informationals from every registry, each full of specific
utility and gratifying some specific external audience -- Karen Rose in
the case at hand -- but not intended for implementors of interoperable
services.

An I-D could be useful, contain the grain of an idea that is generally
useful, and scoped policy is a generally useful idea. We are, as a group,
still working on policies that span scopes, e.g., data collection and the
multi-jurisdictional registration systems and the trans-jurisctional flow
of registrations within a single registration system. Scope tied to a
namespace is already in "our scope", so submission "to the WG" is either
late or redundant.

Turning to the specifics:

What NeuStar proposed in addressing the nexus requirement was:

	registrars obtain (from registrants) certification that
		o the US DoC's nexus requirement is met,
	and
		o the manner in which the requirement is met

There is no protocol requirement here. The provisioning of registrars by
registrants, however done, and consisting of whatever data, is outside
the scope of this registry provisioning protocol.

As Scott has pointed out many times, there are issues that are adequately
covered by contract, and need not have any articulation within a protocol.
This is just such a case.

In addition, NeuStar proposed to check selected data provided by the
candidate registrant, e.g., valid US ZIP code.

There is no _new_ protocol requirement in this statement either.

Finally, NeuStar proposed to check the information provided for the
primary and secondary nameservers identified by the (registrant|registrar).

There is no _new_ protocol requirement in this statement either.

As to a "Purpose" requirement, this appears to be outside of the scope of
SB1335-01-Q-0740, and therefore, an _operator_ specific feature.

As it happens, there are at least two efforts to provide label semantics
for UR*s, the W3C PICS effort, and the W3C P3P effort. As it happens, I've
worked on both. It is possible that a scoped vocabulary (like PICS attempted
in a historic US policy context, or P3P has established w.r.t. privacy in a
synthetic three-theories (EU/OEDC/US) context) could be a generally useful
extension to a registry provisioning protocol, and of interest to implementors
of interoperable systems. I missed something however in this draft.

I would have said the same thing six weeks ago.

As a personal comment, the idea of using the IETF to publish a national code
concerning the classes of persons authorized to use the Internet is not one
that comes naturally to me. Section 3.2

More minutia

Section 7. Internationalization considerations are about characters and text.
Just being "in" one nation state doesn't automatically remove the problem of
i18n considerations. 

Use:
	These parameters do not introduce any additional international
	considerations other than those specified for EPP contact object
	mapping [5].    
 
Section 8. Registry (implementor) private parameters can't require IANA
action. Use: "None."

Section 9. See 7 above. s/i18n/sec/

Eric