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

From: Andrew Sullivan <[email-masked]>
Date: Fri, 3 Mar 2006 14:00:48 -0500

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
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

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

---

From: Andrew Newton <[email-masked]>
Date: Mon, 6 Mar 2006 13:59:08 -0500

On Mar 3, 2006, at 2:00 PM, Andrew Sullivan wrote:
> 	<element
>                name="registeredHost"
>                minOccurs="0"
>                maxOccurs="unbounded">
>
> I'm not sure whether this needs a type;

type="iris:entityType"

This is a good idea.

> about this, though, and it might be more work than it's worth.

The disposition attribute is a modifier of a status type, such as  
<update>.  To include "dispute" as a disposition would seem to  
indicate if an update is in dispute.  Were you thinking more along  
the lines of disputed transfers?  I think that makes sense.  And I  
guess it is possible to have a general status of "this domain is in  
dispute" and still allow describing certain statuses as under dispute.

> approach of the -bis drafts, anyway.

I think the granular approach is better.  Still, it wouldn't hurt if  
we all took a look at that EPP draft.  What is the name and the  
status of the document?

-andy

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 6 Mar 2006 14:15:53 -0500

> the lines of disputed transfers?  I think that makes sense.  And I  

Yes, exactly.  It'd be nice to be able to tag such disputes, because
there's now at least one policy around tracking them, &c. (and it
seems to me that it'd be great to be able to capture as much state as
possible through these queries).  I don't feel strongly about it, but
if it isn't too much work to do, it seems worthwhile.

> we all took a look at that EPP draft.  What is the name and the  

http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-rfc3730bis-01.txt

I believe there's one for 3730, 3731, 3732, 3733, and 3734 (that's
all the I-D tracker turns up for me, anyway), so just substitute the
target RFC number in the URL above.

There are also two current I-Ds from the .br operators for extensions
to the domain and contact objects.  These are extensions that I
_think_ are compatible with the dreg2 draft, but maybe someone who is
better versed than I in both should have a look:

http://www.ietf.org/internet-drafts/draft-neves-epp-brdomain-01.txt
http://www.ietf.org/internet-drafts/draft-neves-epp-brorg-01.txt

A