Subject: [Crisp] Thinking of DREG2

From: Andrew Newton <[email-masked]>
Date: Wed, 3 Aug 2005 12:28:24 -0400

Since DREG is now starting to see some implementations, I've been  
keeping a list of things people have asked about that DREG1 does not  
seem to cover.  Some of what I have are based on lessons learned from  
AREG and EREG (being done in the ENUM working group). We all knew  
that the schema would not be right the first time around, that's why  
there is versioning not just at the IRIS layer but at the registry  
type layer.  Here is what I have so far:

Multiple Registrants
- some registries have more than one registrant
Improved Status
- the names of some of the status values imply a certain combining of  
two different types of status.  These values should be separated into  
separate values and given individually as they apply.
- a lesson learned from EREG
Contacts on RegistrationAuthority
- some registries have contacts associated with registrars specifically
SeeAlso on RegistrationAuthority
- this was probably an oversight
Normalize contacts
- a lesson learned from AREG
Created DateTime
- this was probably an oversight and was probably not caught because  
of "initial delegation" being similar
"trading-as"
- I've still not asked Nominet what this means, perhaps I should quit  
being so lazy.

-andy

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

---

From: Geoffrey Sisson <[email-masked]>
Date: Wed, 3 Aug 2005 18:18:10 +0100 (BST)

> - I've still not asked Nominet what this means, perhaps I should quit  

UK companies can trade under names different than their registered
names, e.g. "Associated Newspapers Ltd t/a Daily Mail" ("t/a" ==
"trading as").  I think this is true in at least also Australia, New
Zealand and South Africa.

Geoff

---

From: Robert Martin-Legene <[email-masked]>
Date: Thu, 4 Aug 2005 00:20:23 +0200

So, you are saying I shouldn't do my perl version yet?

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Thu, 4 Aug 2005 00:44:42 +0200

> So, you are saying I shouldn't do my perl version yet?

I don't believe that changing maxOccurs="1" against maxOccurs="n" is a 
showstopper...

---

From: William Leibzon <[email-masked]>
Date: Thu, 4 Aug 2005 05:37:45 -0700 (PDT)

y

> - this was probably an oversight

There are several levels of hierarchy (at least as far as I identify)
in the domain registration world:

  1. Namespace (controls the root), for our purposes this is ICANN
     and its not relevant to CRISP
  2. Registry - organization that controls registrations done at
     particular TLD and can either run registrations (whois) database
     directly or delegate it and run only service that says if
     domain is registered and where to look at its info further.
      Example of Registry: Verisign (.com/.net,), NeuStar (.biz, .us)
  3. Registrar - organization that provides actual registration service
     and typically communicates with end-user. This maybe same as
     registry for some country TLDs but is typically separate entity
     and same registrar may do registrations for many TLDs. For some
     TLDs whois data is provided directly by registrar while for
     others they do not run this service. Registrar name is almost
     always listed in whois.
      Example of Registrar: Enom, GoDaddy, Tucows/OpenSRS
  4. RSP (Registration Service Provider) - organization that is directly
     communicating with end-user. This is either registrar or reseller
     of the registrar. For many registrars (all where most of the
     registrations come from resellers and where tech support is
     provided by resellers) the RSP name appears as one of the contacts
     (as with opensrs.org) or in some other way in whois (enom puts it
     as first few lines in whois data). In very rare case registrars
     let the RSP run whois database and point to it or likely mirror it.

If we assume that whois (IRIS DREG) data is provided at level of registry
(#2) question is if the "Registration Authority" contact is registrar or
if its RSP and should more then one be allowed and identified. If whois
service is provided by registrar, I'm guessing that Registration Authority
is RSP.

It is likely that if you expect CRISP/IRIS to be used to replace whois
the above scenarios should be taken into account. Personally I think that
providing 2nd level registration contact (RSP at registry level) might not
be the best and what should be done is that DREG database can provide
"Registration Authority" as information about one level below it with
optionally redirection to CRISP service run by that authority. That way
you leave policy question about what is "Registration Authority" out
of the protocol spec and only specify that its registration information
provider that submitted data into currently accessed IRIS database.

---
William Leibzon
   mailto: [email-masked]
Anti-Spam and Email Security Research Worksite:
   http://www.elan.net/~william/emailsecurity/
Whois & DNS Network Investigation Tools:
   http://www.completewhois.com

---

From: Frederico A C Neves <[email-masked]>
Date: Mon, 8 Aug 2005 12:58:32 -0300

Andy,

As we gathered some experience trying to achieve the same whois service
functionality we have today with DREG, I would like to propose some
additions to what you have listed:

- Registrant type Organization, including the ability to reference
another one. This is a generic mechanism that could support most of
the registries out there that have organizations as registrants and
support attorney in law as legal representatives in the country.

- Ticket #. Some registries work in a strict queue processing rule and
need to show this information as a property of a domain name.

- LastModificationDateTime. This is a generic date that represents the
last modification of any information of the domain name.

- DNS Delegation status. This is a child element of host result that
would contain the last time this delegation was checked on this host,
the status of this check and the last time the delegation was
considered correct. This is a generic mechanism to support lame
delegation policy.

- "Contains". Includes a child element on namePart on
findDomainsByName to support generic queries of domain names or
completely modify findDomainByName to support a wildcard like syntax
for queries.

With these changes we would end with a more generic schema that could
fit most of the registries models we known.

I`m willing to contribute text,

Fred

---

From: Andrew Newton <[email-masked]>
Date: Mon, 8 Aug 2005 17:18:48 -0400

Fred,

My comments are in-line.

> support attorney in law as legal representatives in the country.

This sounds very much like the Organization object in AREG.  It  
should be no problem as far as I can see.

> need to show this information as a property of a domain name.

This doesn't sound difficult.  But some more descriptive text would  
be helpful.

> considered correct. This is a generic mechanism to support lame

Sounds good to me.

> completely modify findDomainByName to support a wildcard like syntax

Perhaps we can change the way things are currently done to be a  
little more like the status mechanism, an <all> group with  
maxOccurs="1" for <beginsWith>, <endsWith>, and <contains>.

> I`m willing to contribute text,

Excellent!

-andy

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Tue, 9 Aug 2005 13:01:20 +0200

Frederico,

> completely modify findDomainByName to support a wildcard like syntax

My question: You are talking about findDomainsByName. Do you allow such 
search mechanisms for your IDNs, too?

Best regards,
Marcos

---

From: Shane Kerr <[email-masked]>
Date: Wed, 10 Aug 2005 11:08:39 +0200

> This doesn't sound difficult.  But some more descriptive text would 

In AREG we had a field, "status", which has different meaning depending
on the registry. IIRC, we added a URL to this so that clients could
present a human with some information about the meaning of the field for
the specific registry.

--
Shane

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 10 Aug 2005 10:31:15 -0300

On Mon, Aug 08, 2005 at 05:18:48PM -0400, Andrew Newton wrote:
...
> This doesn't sound difficult.  But some more descriptive text would  

This is normally the public unique sequential number to "prof/audit"
the First-Come-First-Served registration policy.

...
> maxOccurs="1" for <beginsWith>, <endsWith>, and <contains>.

Yes that's the simplest option and works for me.

Fred

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 10 Aug 2005 11:42:22 -0300

> search mechanisms for your IDNs, too?

Not today but we plan to do it. In our case, and of course this is
implementation specific, our domain equivalence rule doesn't permit
registration of "equivalent" names by different organizations. This
brings to an implementation simplification and all of our queries
processing is done using only ASCII characters. Strictly speaking in
our case we don't need this on findDomainsByIDN because the ByName
mechanism if used with the equivalent characters will achieve the
desired go.

Our motivation is to provide this service to authorized users,
normally trademark offices, that today doesn't have this hability
using the current whois service.

In our case I don't see the need for change on the restriction for
exactMatch on findDomainsByIDN but this could be a poised view and
maybe someone could find use for this generic mechanism on IDNs and
this could be handy to.

Fred

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 10 Aug 2005 17:47:16 -0400

My experience is somewhat dated, but random substring searches
tend to be expensive and slooooooooooowwwww.  You might actually
want to try it first.  IDN matching is going to be even more
entertaining, because it basically requires more processing than
is typically available in database matches.

I certainly wouldn't want it to be a required, or even recommended,
search type...

Leslie.

---

From: David Blacka <[email-masked]>
Date: Wed, 10 Aug 2005 18:28:21 -0400

> is typically available in database matches.

Well, they are at least expensive in some way.  In database  
terminology, if you do a substring search without doing anything  
special, this translates into a table scan.  If your table is short  
this is no big deal.  However, I expect that the table to not be  
short, thus the search is sloooow.

If you do something special (I remember using a wacky Oracle doohick  
to do this), you can certainly create a substring index, and then the  
search isn't really slow, but that substring index turns out to be  
very large.

> I certainly wouldn't want it to be a required, or even recommended,

Agreed.

--
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 10 Aug 2005 20:55:33 -0300

On Wed, Aug 10, 2005 at 05:47:16PM -0400, Leslie Daigle wrote:
> want to try it first.  

I think this is implementation specific, but you are mostly correct.
Besides the proprietary stuff David cited, today with some tricks like
full-text index/search and replication available on some free
databases we could bring this kind of queries to sub-second
performance.

For the sake of providing the service to a restricted set of
authenticated users this is a facility that solves the problem of
having to provide this information OOB, as we and others do it today.

> IDN matching is going to be even more entertaining, because it
> basically requires more processing than is typically available in
> database matches.
>

Agreed too. A server operator is always allowed to return a
<permissionDenied> or <queryNotSupported>

Fred

---

From: Andrew Newton <[email-masked]>
Date: Wed, 10 Aug 2005 21:44:48 -0400

> having to provide this information OOB, as we and others do it today.

I am sensing a little hesitation about including this feature because  
it can be expensive relative to other operations.

The hesitation may come from somebody not knowing this little detail  
and reading the spec and insisting upon its open availability.  So  
maybe we should have a "Deployment Considerations" section that says  
something like: this operation can consume more relative resources  
than other queries, and it is RECOMMENDED that operators supporting  
this query allow its execution only for authenticated users or employ  
other measures that would make its invocation more predictable or  
accountable.

-andy

---

From: David Blacka <[email-masked]>
Date: Thu, 11 Aug 2005 09:02:24 -0400

On Aug 10, 2005, at 9:44 PM, Andrew Newton wrote:

> I am sensing a little hesitation about including this feature  
> because it can be expensive relative to other operations.

Actually, no hesitation from me.  I am far more concerned that dreg2  
still allow compound match parameters -- i.e., <beginsWith> and  
<endsWith>, or <contains> and <endsWith> -- so that operators have  
the opportunity to choose a more efficient path if the requester  
allows them to.

> The hesitation may come from somebody not knowing this little  
> detail and reading the spec and insisting upon its open  
> availability.  So maybe we should have a "Deployment  
> Considerations" section that says something like: this operation  
> can consume more relative resources than other queries, and it is  
> RECOMMENDED that operators supporting this query allow its  
> execution only for authenticated users or employ other measures  
> that would make its invocation more predictable or accountable.

This seems paternalistic and unnecessary.  I think that it will  
become extremely obvious during any testing if the <contains> match  
argument presents a problem.

The most that I would suggest is to make it clear (if it isn't  
already) that operators are allowed and generally expected to return  
<searchTooWide> or <queryNotSupported> for operations that they are  
unwilling or unable to support.

That is, my only fear would be that operators would incorrectly feel  
that they MUST support <contains>.

---

From: Andrew Newton <[email-masked]>
Date: Thu, 11 Aug 2005 09:43:52 -0400

On Aug 11, 2005, at 9:02 AM, David Blacka wrote:
> Actually, no hesitation from me.  I am far more concerned that  
> dreg2 still allow compound match parameters -- i.e., <beginsWith>  
> and <endsWith>, or <contains> and <endsWith> -- so that operators  
> have the opportunity to choose a more efficient path if the  
> requester allows them to.

Again, I think we can do this with an <all> and minOccurs='0' and  
maxOccurs='1' on <beginsWith>, <endsWith>, and <contains>.

> argument presents a problem.

When I was alluding to "somebody not knowing this little detail", I  
was NOT making a reference to people on this mailing list, people  
implementing this protocol, people in QA doing testing, or technical  
folks in general.

> already) that operators are allowed and generally expected to  
> return <searchTooWide> or <queryNotSupported> for operations that  
> they are unwilling or unable to support.
>
> That is, my only fear would be that operators would incorrectly  
> feel that they MUST support <contains>.

And we should probably restate this as well.

-andy

---

From: Leslie Daigle <[email-masked]>
Date: Thu, 11 Aug 2005 21:25:30 -0400

Andrew Newton wrote:

> When I was alluding to "somebody not knowing this little detail", I  was 
> NOT making a reference to people on this mailing list, people  

Bingo.  I'd be worried about people, say, writing requirements
and RFPs.  ("Tastes great! Less filling!").

Leslie.