[Crisp] Review of draft-ietf-crisp-iris-dreg2-00

[Andrew Sullivan <[e-mail]>]

Greetings,

I have reviewed the document draft-ietf-crisp-iris-dreg2-00.txt.  I
have some comments, below.

In general, this looks like a useful update to RFC 3982.

I note that there appears to be an effort in this document to align
with functionality offered by the Extensible Provisioning Protocol,
which I think is a good thing.  One additional item that might be
added, therefore, is an element in the response to a
<findDomainsByName> query.

EPP (or more precisely, the EPP domain and host mappings, RFCs 3731
and 3732) distinguishes between hosts that are "external" and
"internal" (that is, hosts inside the namespace of the repository,
and hosts outside the namespace).  For an internal host to be
created, its superordinate domain MUST already exist in the
repository.  Similarly, for a domain to be deleted from the
repository, no subordinate host may exist in the repository (you can
rename the hosts, to remove the subordination, though).  In order to
provide an indication that such hosts exist in relation to a domain,
an EPP <domain:info> command returns zero or more optional
<domain:host> elements indicating subordinate hosts in the namespace. 
These aren't the same as the <domain:ns> elements (they might refer
to the same objects, of course, but they need not).

I think this could be represented in dreg2 with an addition something
like the following to the domainType result type:

	<element
               name="registeredHost"
               minOccurs="0"
               maxOccurs="unbounded">

I'm not sure whether this needs a type; I think it might, but I'm not
enough of an XML expert to be able to say with any confidence.  I
don't think the queries need to be modified: you can already infer
that a superordinate domain must exist by knowing what the repository
is authority for, and knowing a hostname (which would tell you
whether it was subordinate or not), so no query is needed for that
purpose, I think.

I also wondered a little about why all the "disputed" values aren't
subsumed under a "disposition" value.  I haven't thought very hard
about this, though, and it might be more work than it's worth.

Finally, it might be worth noting that there are updates to EPP that
are making their way through the I-D process right now.  One of the
things they attempt to do, I believe, is to disambiguate the status
values (so, for instance, pendingDelete will not entail
serverUpdateProhibited).  I think that should make no difference to
this document, which (AFAICT) is compatible with the more granular
approach of the -bis drafts, anyway.

Best regards,
Andrew

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[e-mail]>                              M2P 2A8
                                        [phone] x4110


_______________________________________________
Crisp mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/crisp