Subject: last-verified-date

From: Rick Wesson <[email-masked]>
Date: Thu, 14 Nov 2002 13:05:00 -0800 (PST)

One of the items on the agenda for tuesday is a proposal for an element of
contacts objects. I'd like to get some discussion going on this so we can
stay in the 10 minutes allocated to the topic in our session.

2.9 Last Verified Date

The date the contact had the opportunity to affirm that the information
associated with the contact is correct. Registries MAY set policy on how
checking is preformed and what if any procedure a registrar MUST apply to
ensure correct Registrant data.

The concept is to add some quality assurance mechanism to the registrant
data and to make available for the publishing of the data in WHOIS or a
CRISP protocol so that end-users can have an indicator as to the last date
the information was verified.

I appreciate any thoughts the group has on this proposal.

thanks,

-rick

---

From: "James M Woods" <[email-masked]>
Date: Thu, 14 Nov 2002 16:29:48 -0500

Rick,

I think this is an excellent inclusion to the specs. I support it, so
long as its adopted as being optional at the registry level. As an aside
I also see some third party business applications opportunities by
including this..but I digress.

To stir the pot a bit... are contacts the only objects we'd care to have
optionally last verified?

Thoughts?

James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Rick Wesson
Sent: November 14, 2002 4:05 PM
To: [email-masked]'
Subject: last-verified-date

One of the items on the agenda for tuesday is a proposal for an element
of contacts objects. I'd like to get some discussion going on this so we
can stay in the 10 minutes allocated to the topic in our session.

2.9 Last Verified Date

The date the contact had the opportunity to affirm that the information
associated with the contact is correct. Registries MAY set policy on how
checking is preformed and what if any procedure a registrar MUST apply
to ensure correct Registrant data.

The concept is to add some quality assurance mechanism to the registrant
data and to make available for the publishing of the data in WHOIS or a
CRISP protocol so that end-users can have an indicator as to the last
date the information was verified.

thanks,

-rick

---

From: Rick Wesson <[email-masked]>
Date: Thu, 14 Nov 2002 13:49:56 -0800 (PST)

> optionally last verified?

contact objects for domain registries are the only objects that the
registry does not authortatively manage. The domain registration and in
zone name servers all have constraints which prevent invalid registration.

The data in contact objects also change over time as postal codes and area
codes change over time.

as to the optional bit, are you requesting last-verified-date be optional
for the protocol or optional that registries preform some verification? If
the language isn't clear enought I'd like to make it clear that the
responsibility is on the registrar not the registry to give the contact
the oppertunity to confirm the data.

the only registry responsibility MUST be to allow the registrar to twiddle
the bits.

best,

-rick

---

From: "James M Woods" <[email-masked]>
Date: Thu, 14 Nov 2002 17:02:13 -0500

>contact objects for domain registries are the only objects that the
registry does not authortatively manage. The domain   >registration and
in zone name servers all have constraints which prevent invalid
registration.

>The data in contact objects also change over time as postal codes and
area codes change over time.

I stand corrected, Im nine months removed from my last EPP work so the
cob webs are still being cleared ;)

>as to the optional bit, are you requesting last-verified-date be
optional for the protocol or optional that registries    >preform some
verification?

Thanks for the clarity on this one...my objection was only from a
business process level (see what happens when you stay away from your
bit-head friends too long ;)

So I support with no conditions!

Cheers,

James

-----Original Message-----
From: Rick Wesson [mailto:[email-masked]] 
Sent: November 14, 2002 4:50 PM
To: James M Woods
Cc: [email-masked]
Subject: RE: last-verified-date

On Thu, 14 Nov 2002, James M Woods wrote:

> long as its adopted as being optional at the registry level. As an 
> aside I also see some third party business applications opportunities 
> by including this..but I digress.
>
> To stir the pot a bit... are contacts the only objects we'd care to 
> have optionally last verified?

contact objects for domain registries are the only objects that the
registry does not authortatively manage. The domain registration and in
zone name servers all have constraints which prevent invalid
registration.

The data in contact objects also change over time as postal codes and
area codes change over time.

as to the optional bit, are you requesting last-verified-date be
optional for the protocol or optional that registries preform some
verification? If the language isn't clear enought I'd like to make it
clear that the responsibility is on the registrar not the registry to
give the contact the oppertunity to confirm the data.

the only registry responsibility MUST be to allow the registrar to
twiddle the bits.

best,

-rick

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 15 Nov 2002 00:05:02 +0100

Rick Wesson wrote:

Hi Rick,

> zone name servers all have constraints which prevent invalid registration.

Just for clarity: The registry does not manage the in-zone name servers 
authoritatively neither. I still can go into a domain's zone file and 
change the IP addresses of the name servers contained in this zone, 
similar to the moving of a person from one city to another. The host 
entries are quite comparable to the contacts in this aspect. This makes 
some efforts in EPP rediculous.

> -rick

regards,

Klaus

___________________________________________________________________________
      |       |
      | knipp |                   Knipp  Medien und Kommunikation GmbH
       -------                           Technologiepark
                                         Martin-Schmeißer-Weg 9
      Dipl. Inf. Klaus Malorny           44227 Dortmund
      [email-masked]             Tel. +49 231 9703 0

---

From: Olivier Guillard / AFNIC <[email-masked]>
Date: Fri, 15 Nov 2002 11:13:36 +0100

Hello Klaus,

> authoritatively neither.

it depend which registry, the world is not only a question of EPP.

In principle, as clients can be anyware in the world if you want a protocol
which is usable under national legislations (like the german one for example:)
you want to be sure that EPP servers are configurable so that those *political*
and surely not *technical* matters can be dealt appropriatly by any registry.

Cheers,

Olivier

> > zone name servers all have constraints which prevent invalid registration.
 I still can go into a domain's zone file and 

-- 
Olivier

---

From: Daniel Manley <[email-masked]>
Date: Fri, 15 Nov 2002 09:08:55 -0500

In terms of other objects, the practical example of .us comes to mind -- 
they restrict domain delegation to nameservers physically located in the 
US, right?

Dan

-- 
Daniel Manley
Tucows, Inc.
Toronto, Canada
[email-masked]

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 15 Nov 2002 08:21:55 -0600

From: "Daniel Manley" <[email-masked]>
> they restrict domain delegation to nameservers physically located in the

http://www.dnso.org/clubpublic/registrars/Arc01/msg03547.html
From: "Michael D. Palage" <[email-masked]>
.US Update
====

As an attorney, you seem to miss the technical implications of what you propose.
If one looks at the operational aspects of real servers, the realities of DNS, etc.
then the simple string ".US" takes on a different shape. This is not an http://Toys.R.US
debate, but rather heads in the other direction to the bits and the messages the servers
have to send to each other to play well together.

You, like most people likely assume that .US will remain in the legacy root servers.
That is likely a valid assumption for the "toy" 32-bit DNS. That may not scale to the
Next Generation Internet. You might want to learn more about how the Next Generation
Internet is architected. .US is a good TLD to use for examples. For years it was artificially
restricted and manipulated by the late Jon Postel. It is now less so. That is progress.
It should be noted that this progress did not happen in ICANN, it was handled directly
by the U.S. Department of Commerce.

Fortunately, or unfortunately .US has to live in a much larger name-space and play well
with all of the various software solutions "toy" and otherwise. Since the .US Registry contract
from the U.S. Government is only for a few years, it would be prudent at this point to look
down the road to make sure that .US not only leads but also plays well with the likely
changes that are here and coming. Unfortunately, people can not predict the future, but it
is possible to make a good guess, now that the various factions are lined up and clearly will
not change.

Stepping back, one might approach this as if .US was *not* in the aging legacy root servers
controlled by the U.S. Government. How would it get in ? Over the years, there have been
several ways that people have found to route around the blockades and to get in somewhere
into the name-space. One way has been the DLD (Dash-Level-Domain) path. In that approach
the .COM and .NET TLDs are used as hooks to add an unlimited number of extensions to
the left, via dash-based names. -ONLINE.com is a good example and one of the most popular.
When faced with not being able to get .ONLINE into the legacy root, one alternative is to
use the .ONLINE DLD.
http://www.icann.org/comments-mail/icann-current/msg00342.html
9264 ONLINE - 45,049 matches for -ONLINE
http://www.domainsurfer.com/ssearch.cgi?dom=-online.com
If .US had been forced to use this approach, it would have been popular, but not as popular
as .USA. Some could argue that is because people are now in the more open .US, but that has
not always been the case. The previous dictatorship only ended in 1998. .USA was never given
a chance and still has not been given a fair chance. It is an embarassment to all Americans. The
Whitehouse will surely try to do something before the next elections.
=======
13,465 matches for -USA
http://www.domainsurfer.com/ssearch.cgi?dom=-usa.com
6,087 matches for -US
http://www.domainsurfer.com/ssearch.cgi?dom=-us.com

Looking beyond the DLD approach, we now see that a few new TLDs have been tested in
the legacy roots with no operational impact. The people making money from them will of course
cook up whatever claims they want about being under attack and under load. That type of FUD
of course plays well in the post-9/11 climate. The usual-suspects will of course now try to figure
out how to profit from the unfortunate events of the past years, which they helped to create.
http://www.markletaskforce.org/

Because of the operational claims about load, etc. and because of the clear agenda to cleanse
the legacy roots of all TLDs that do not fit the "image" of the I* society, it becomes clear that
many of the so-called ccTLDs will fall by the wayside. Other so-called ccTLDs have become
gTLDs with solid commercial marketing plans to sustain them. That gives people confidence in
using them. No matter what happens, change is coming and the result will be a smaller, more-
controlled, legacy root-server approach. That makes the DLD approach look better and better.
Unfortunately, some people do not like building out from the .COM and .NET nodes as roots.
They feel that monopoly situation is not healthy to use. They want the control spread around.

Another approach to growing the name-space would be to place 26 TLDs in the legacy roots
and anyone that wants to start a TLD would pick it, and apply for a name under the first letter
of the TLD. That might be a nice approach if people had open minds and thought it was possible
to get 26 new TLDs added. In the current climate, open minds and willingness to test 26 new TLDs
is obviously not an option. Instead, one sees that they can use some simple ranges of letters
AE...FM...NR...SZ to use as nodes to build out from the root. This of course opens the debates
about why 4 nodes ?....some then want only 2 nodes....AM...NZ....then the NZ people decide
they are not going to let people in....then the OZ people next door pop up...and want AN...OZ
in concert with their European friends. No matter how it all shakes out, .US begins with the letter
U and would fall under SZ, or NZ or OZ.

Given all of the above, software has to be written which does not know a .US from a .SU,
or maybe one should say it knows the difference, but it does not care about the nexus, lexus, or
the brand of server in the car. In summary, .US will have to ultimately be treated like all of the
other TLDs. Given an [SLD].US name, that may mean that the software first looks under the
.US TLD, and then to the -US.com DLD and then to the -US.net DLD and finally to the
US.OZ zone or the US.SZ zone or the US.NZ zone. It will find the servers for the [SLD].US
and that search may not take the simple approach you seem to assume.

Whitehouse Ready to Release Next Generation Internet Plan
http://news.com.com/2100-1023-958159.html?tag=politech
http://www.politechbot.com/p-03994.html
http://www.uscryptomail.org/cybersecurity/
Note: The new plan calls for the same architecture used with IPv8 and IPv16,
whereby, users do not have direct access to the (out-of-band) IPv16 network.

Jim Fleming
128-bit DNS is closer than you think...
COM...DE...NET...ORG...INFO...BIZ...US...ONLINE
http://ipv8.dyndns.tv
http://ipv8.dyns.cx
http://ipv8.no-ip.com
http://ipv8.no-ip.biz
http://ipv8.no-ip.info
http://ipv8.myip.us
http://ipv8.dyn.ee
http://ipv8.community.net.au

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 15 Nov 2002 16:11:42 +0100

> and surely not *technical* matters can be dealt appropriatly by any registry.

Hi Olivier,

I meant this purely technically. The A/AAAA/A6 record of the name server in the 
innermost zone is the only authoritative source of the IP address of a name 
server. Therefore, the linkage of the name server to its superordinated domain 
is a bad design, as they do not necessarily need to be defined in the same zone 
(due to the feature of subdelegation) and therefore may be in different 
administration "spheres" (to use another term than "domain").

By the way: Following the discussions here in this list, I sometimes get the 
impression that the argument "this is a registry policy and therefore should not 
be part of EPP" and its complement are just used as needed to exclude/include 
certain parts from/into the specs.

regards,

Klaus

---

From: Olivier Guillard <[email-masked]>
Date: Fri, 15 Nov 2002 16:58:12 +0100

> certain parts from/into the specs.

DNS as every bottlenecks is a point of meetings for many different
interest and make many poeple nervous :)

Anyway, we must admit that we need law and legislations sometimes,
particulary when it is question of maintaining common ressources.

> The A/AAAA/A6 record of the name server in the 
> server.

-> agree, this is normally not the registry business to announce it

Olivier

-- 
Olivier Guillard
---
|| AFNIC - Immeuble International
|| 2 rue Stephenson - Montigny-le-Bretonneux
|| 78181, Saint-Quentin-en-Yvelines CEDEX, France
|| http://www.nic.fr/
|| mailto:[email-masked]
|| tel: +33 1 39 30 83 31

---

From: Hong Liu <[email-masked]>
Date: Sun, 17 Nov 2002 08:38:16 -0800 (PST)

Hi, Rick,

Do you have the new text for your proposal given the
list discussion? I would like to comment but think it
may be more appropriate to see the new text first.
Thanks!

--Hong

> I appreciate any thoughts the group has on this

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com

---

From: Hong Liu <[email-masked]>
Date: Mon, 18 Nov 2002 06:19:31 -0800 (PST)

Rick,

Per your suggestion, I am sending my comments to the
list. Here is the modified text I would suggest:

"2.9 Last Verified Date

The date the contact information was last verified as
valid by the entity who at the time of validation was
the sponsoring registrar of the contact object. This
parameter is OPTIONAL for a contact object. When used,
it is the registrar's sole responsibility to perform
the validation duty."

There are three key points I would like to make:

(1) The current sponsoring registrar is not
necessarily the registrar who last checked the
contact. To complete the proposal, it may be better to
include a <verID> to store the verifying registrar
identity. I will leave the WG to decide.
(2) The parameter should be optional, i.e., not all
contact objects are required to be verified.
(3) The registry should play no role, except for
storing the field when presented, in performing the
validity checking.

Hope you and other guys have a good discussion in
Atlanta on this and other topics. 

--Hong

---

From: Klaus Malorny <[email-masked]>
Date: Mon, 18 Nov 2002 17:21:44 +0100

> Atlanta on this and other topics. 

Hi,

after thinking a bit about this, I believe that this information

   a) is part of the registry policy
   b) does not belong the minimum set of necessary contact
      information.

Therefore I suggest that if a registry wants to support this information, it 
should use the extension mechanisms in EPP, i.e. by supplying an own contact 
object or by using the <extension> element.

A general problem with the field is that it does not say anthing about the 
thoroughness of the verification and may mislead the recipient - it may create 
trust that it isn't worth. If one wants to avoid this, one have to back this 
with detailed registry policy that delegates the responsibilities to the 
registrars, or, much better, to perform the verification in the registry itself. 
In this case the data would not appear in the create/update requests, but only 
in the info request.

regards,

Klaus

---

From: Hong Liu <[email-masked]>
Date: Tue, 19 Nov 2002 19:22:47 -0800 (PST)

Klaus,

After some careful thinking, I agree with most of your
comments. Specifically, I agree with you that: This
feature SHOULD be an EPP extension, other than an
OPTIONAL element in core EPP spec. 

There are a number of reasons for it to be an EPP
extension:

(1) As you correctly pointed out, this feature is of
little use without the detailed policy support. AFAIK,
there is no established policy in this regard. 

(2) Even if specific policy is established, it is
likely that such policy does not apply to all
registries, and hence does not warrant it to be
included in the core EPP spec. We already had a
precedence on this: the <restore> command for delete
redemption grace period. In that case, the policy
picture is far more clearer than this one. The WG made
the decision to support it as an EPP extension since
the policy may not apply to ccTLDs.

(3) As you correctly pointed out, the technical
advantage of doing it as an EPP extension is that core
EPP commands will not be affected. I would further add
that doing so eliminates the need to modify existing
EPP registry data.

In short, I feel uncomfortable to put the cart before
the horses. Supporting this feature through EPP
extension seems to be the _only_ sensible trade-off in
dealing with this potential "policy hell".

Cheers,

--Hong

--- Klaus Malorny <[email-masked]> wrote:
[snip...]
> thoroughness of the verification and may mislead the
> recipient - it may
> create 
> registrars, or, much better, to perform the
> verification in the registry
> itself. 
> In this case the data would not appear in the
> create/update requests, but
> only 
> in the info request.
> 
> regards,
> 
> Klaus
>