Re: domreg BOF Meeting Minutes

[Geva Patz <geva@bbn.com>]

On Tue, Dec 19, 2000 at 03:09:01PM -0500, Hollenbeck, Scott wrote:

> Comments from the floor were generally
> positive about the state of the requirements, though one speaker
> suggested some additional text at the beginning of the I-D to note
> that the requirements were defined for a specific operational model
> and that other models exist.  One speaker was not comfortable with
> the requirements, though he had not provided any specific concerns
> to the mailing list.  In the end it was agreed that a little more
> work is needed to finalize the requirements draft before it can
> be considered complete.

Speaking as at least one of the "one speakers" mentioned above,
let me restate my concern to clarify: As it currently stands,
the requirements capture the current model (multiple registrars,
single registry per repository) well. This isn't, however, the
only possible model. I'm aware of more than one ccTLD that wishes
to implement a replicated registry model, where the repository is
replicated amongst the registrars. It's entirely possible that
one or more of the gTLDs may move in that direction, too. As
technology evolves, it's possible to imagine even a distribued
repository model.

I'm not suggesting that it is the job of this group to design
a replicated registry database. I don't even believe that the
architecture for such a thing needs to be standardized. I do,
however, believe that in our requirements we should make it
explicitly clear that whatever we design should be flexible
enough to accommodate these different models. It would be a shame
to go through all the effort of developing a standard that only
has narrow relevance to one specific model.

Fortunately, relatively little needs to change in the
requirements to accommodate this, most of it early on. I'll have
a go at wording the changes shortly.

While I'm on the requirements, a couple of other comments:

The section on security could do with some expansion. In
particular, it would be a good idea to elaborate somewhat on
the trust assumptions that should underlie any protocol design.
One of the problems with the one protocol proposal that we've
seen so far (draft-hollenbeck-epp-00.txt) is that it assumes
trust between registrar and registry, and between registrant and
reigstrar (and hence, implicitly, registry).

I won't spend much time at this point going into the mechanics
of trust in the EPP proposal, because we're still in the
requirements phase, but the main point I'm trying to make is
that we should state in the requirements that any protocol
design should assume no trust between any pair in {registrant,
registrar, registry}. This implies, for instance, that any
authentication credentials given to the registrant by the
registry to confirm registration (and hence allow updates) should
not be passed in the clear through the registrar. It implies a
certain amount of care in the design of the query operation, to
prevent 'false positives' being given. Again, details such as
these are more protocol design issues than requirements issues,
but I do believe that the 'no trust' assumption (along with
some of its conceptual implications) should be written into
the requirements draft. Once more, I'll try and write up this
proposal into something concrete later.

Finally, we should probably go through the draft to make
sure that there aren't any small details in it that aren't
requirements per se. An example is this sort of thing:

>  The registration period for domain names MUST be measured in
>  years, with a minimum period of one year and a maximum period
>  defined by registry policy.

Although this captures the current situation in most gTLDs (and
many ccTLDs) accurately, there's absolutely no reason to make
the minimum period of a year a high-level requirement. In fact,
there's a good reason not to: a protocol designed literally
to this requirement might include a validity counter with a
resolution in years, making it impossible for registries to
implement a policy with finer resolution.

This is the only example that leapt out at me on my first few
passes, but a closer reading may yield other, similar situations
where current practice should not be reflected as a requirement.

Geva Patz
geva@bbn.com