grrp-reqs-06, 3.2 Object Registration [2]

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

The temporal properties of domain name object registration needs clarification.
The -06 text in [2] originates from a proposal by Geva Patz [1] who sought to
remove arbitrary restrictions, as domain names then (circa -03) had fixed time
associations. I believe the problem Geva was concerned with was the upper-bound
for domain name object registration.

A difficulty arises from this very lack of arbitrary restriction as no lower
bound requirement is available to the protocol designers, and we clearly do
not, in the case of fee-for-service regimes, want to move from existing forms
of fee recovery (credit card based is a common, though not universal model)
to "micro-payment" regimes.

The issues which need to be addressed by this requirment are accounting,
granularity of the units used to measure validity periods (where definite
temporal properties exist), etc.

  Current -06 text:
                                       ...  Registries SHOULD be allowed
  to accept indefinitely valid registrations if the policy that they are
  implementing permits, and to specify a default validity period if one
  is not selected by a registrar. ...

  Proposed text:

                                       ...  Registries SHOULD be allowed
  to accept indefinitely valid registrations if the policy that they are
  implementing permits, and to specify a default validity period if one
  is not selected by a registrar. Registries MUST be allowed to specify
  minimal validity periods consistent with the prevailing or preferred
  practice for fee-for-service recovery. ...

If anyone cares to observe that this is policy (micro-payment depricating,
macro-payment preferential), they are of course correct, and I don't want
to even think of importation of the requirement expressed in [2] into the
provreg system.

Comments on the backs of $5 bills (larger is OK, but a minimum granularity
is required). Thanks.

Cheers,
Eric

[1] http://www.cafax.se/ietf-provreg/maillist/2000-12/msg00026.html
[2] rfc2870, Root Name Server Operational Requirements, Section 3.2.5.