ICANN/DNSO
DNSO Mailling lists archives

[registrars]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [registrars] Inter-registrar Domain Name Transfer (IRDX) Proposal


Thanks Bhavin - comments below denoted by "RR:"


*** retreiving Whois record is one thing, parsing it for the appropriate
information is the issue. I beleive this  should be sorted if/when we have a
common whois format, until then the only foolproof way is manual parsing. A
large number of registrars have automated this process to a large extent,
TUCOWS included I believe, by parsing through the varied text forms to
derive the email id o registrant or admin contact. Gandi has an opensource
whoisextract perl modulke available for the same too. however fundamentally
there is a possibility of this auto-parsing not yielding correct results. By
incorrect results I mean two kinds of possibilities -

1. no results obtained.... ie the parsing did not return a valid email id.
This is not a problem, since the admin/registrant will never get any email
and will therefore not reply to this

2. getting the wrong email id. This is the issue. I have seen discussions
where some registrars maybe basing their auto parsing function on an
assumption that the whois is always in the following order - Registrant,
Admin, Tech, Billing. I believe the assumption may be correct to the degree
that it probably holds true for all of us, however nothing precludes a
registrar from changing their whois format and displaying the billing
contact first, or nothing stops a domain owner from putting an email address
in the postal address field. An automated program that parses this whois may
come up with a wrong email id resulting in the authorisation request being
sent to the wrong contact point. I dont really know a possible solution to
this since manually verifying wach whois output would be a costly affair,
but there are certain principles that we as a community could adopt to make
it easy to parse whois data for everyone.

RR: It's important that we focus first on the framework and then start work
on individual implementations. While I agree with the points you raise here,
they are not process oriented, but rather specifically deal with the
implementation details...great points still...

"STEP: 11 Transfer authorization record stored with transaction by Gaining
Registrar - ICANN requires that authorization records must be stored for a
period of time to ensure the validity of transactions on a historical basis.
Data that should be stored as part of this process include;
- Name and email address of original requestor

*** The name and email address of orignal requestor when the request is made
on the web would not  have any legal validity

RR: Agreed - but it's still important to store it for reference sake in the
future. Or is it? Hmm...

- Registrant of record as declared by losing registrar Whois
- Administrative contact of record as declared by losing registrar Whois

*** Easier to store the entire Whois output instead of just the
Registrant/Admin contact details. The whois record is being fetched
anyways...

RR: Agreed - also an implementation detail tho'....

- Originating IP address of the individual undertaking the authorization of
the request (where appropriate)
- Time and date filed with registry for processing (if appropriate)"

"STEP: 13 Inspection"

*** I applaud the idea of an automated inspection. How does TUCOWS determine
however the list of domains that go in your blacklist. Also does TUCOWS do
ANY MANUAL inspection for EVERY domain at this stage? Except for a match
against blacklisted names I dont see much that could be done at this stage.
And then again if that is the only inspection that your inspection step
consists of then those could actually be carried out BEFORE sending an
authorisation request and before parsing the whois record of the losing
registrar. Though that means more work for the registrar.

RR: Our black list is simply a compendium of highly trafficked website
addresses. It's not a perfect solution, but it spits out enough matches to
justify its existence...not every domain goes for manual inspection, just
the sample that hits the blacklist...let me see how the ordering fits the
flow for your other point...

-rwr



<<< Chronological Index >>>    <<< Thread Index >>>