Subject: RE: Pending Update
From: Bruce Tonkin <[email-masked]>
To: "'Hollenbeck, Scott'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Date: Fri, 1 Mar 2002 09:55:11 +1100

Hello Scott,

This make sense to me.

We have the equivalent of this in the current ".au" registry, where a domain
name is listed as pending in the registry (thus preventing someone else
registering it), while policy compliance is checked.

In the new ".au" registry, the plan was for the registrars to manually check
the name before it gets to the registry.
However I could see that for some circumstances you might want a registry
staff member to manually check some information before a action is
completed.

Regards,
Bruce Tonkin

> -----Original Message-----
> From: Hollenbeck, Scott [mailto:[email-masked]]
> Sent: Friday, March 01, 2002 1:39 AM
> To: 'Liu, Hong'; [email-masked]'
> Subject: RE: Pending Update
> 
> 
> Hong,
> 
> There's a somewhat analogous situation related to creating 
> domain names in
> that sometimes the object really shouldn't be instantiated 
> until after some
> manual process determines that the domain is "valid".  Right 
> now the specs
> include a domain status of "pendingVerification" to note that a domain
> object create command has been processed, but the action 
> hasn't yet really
> be completed.
> 
> As for the discussion requested below, I think it might be 
> helpful to add a
> response code that says something like "Command completed 
> successfully;
> action pending".  We have to separate command completion from back-end
> processing such that we maintain the OLTP ACID properties 
> (basically that
> commands have no partial success or partial failure), so we 
> need to note
> that the command has been received and processed but that 
> something else
> needs to happen before some back-end stuff completes.  We 
> could also add a
> "pendingVerification" status to the host mapping to note the 
> situation in
> subsequent <info> command responses.
> 
> I'm not going to touch the documents again until we get some 
> feedback from
> the IESG, but adding a new response code and a new host 
> status could well be
> done when dealing with IESG comments.
> 
> -Scott- 
> 
> > -----Original Message-----
> > From: Liu, Hong [mailto:[email-masked]]
> > Sent: Wednesday, February 27, 2002 12:53 PM
> > To: [email-masked]'
> > Subject: Pending Update
> > 
> > 
> > The current update operation defined in EPP is basically a 
> > two step process:
> > First, an update request is made by the registrar to the 
> > registry. Second,
> > the registry either rejects the request or performs the 
> > operation; and a
> > response is sent back to the registrar.
> > 
> > A pending update refers to a four step process: First, an 
> > update request is
> > made by the registrar to the registry. Second, the registry 
> > acknowledges the
> > request to the registrar but does not take action for the 
> > moment, i.e., the
> > update is pending. Third, upon further authorization, the 
> > registry either
> > rejects the request or performs the operation; then posts the 
> > result to the
> > message queue. Fourth, the registrar polls the message queue 
> > to retrieve the
> > result of the operation.
> > 
> > Conceptually, pending update is very similar to the 
> transfer operation
> > currently defined in EPP.
> > 
> > I would like to hear from the list how such operation is 
> > supported by EPP.
> > If this topic has been discussed before on the mailing list, I would
> > appreciate pointers to the previous discussions.
> > 
> 

From: "Liu, Hong" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: "'Hollenbeck, Scott'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Pending Update 
Date: Thu, 28 Feb 2002 13:39:39 -0600
Sender: [email-masked]

Eric,

Thanks for the input. Please see my comments in line marked as <HL>.

Regards,

--Hong

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:[email-masked]]
Sent: Thursday, February 28, 2002 1:08 PM
To: Liu, Hong
Cc: 'Hollenbeck, Scott'; [email-masked]'; [email-masked]
Subject: Re: Pending Update 

> Another issue that arises in the context of asynchrony is the notification
> mechansim ...

push vs poll.

For some reason, and we are indifferent to which, the state of a datum in
the registrar-registry "shared data" is inconsistent, and the instance of
the datum in the registry is later than the instance of the datum in the
(sponsoring) registrar, and we believe that time goes forward most of the
time.

<HL>
Certainly, having a push in place will be of great help. However, my
previous email was based on the current EPP-06, where push is not avaialble.
In fact, what I implied in the email is that it would be nice to return the
snapshot of the object state (not status) for the asynchronous update right
after the operation is completed. Whether that information is put into the
queue (i.e., poll) or pushed to the requesting registrar, is a matter of
messaging. If we do it right, the information returned should be the same
one way or the other. Of course, push seems to be more natural in this
context if it is available.
<HL/>

> Is this an implementation issue or an EPP issue? I would like to hear from
> you and others on the list. Thanks!

push vs poll. Covered in _extensive_ detail in this list. 

[HL] I am aware of that. Again, I am working under the assumption that push
is not available, at least not yet. See above.

> ... multiple asynchronous update operations on the same object.

How does this condition non-trivially arise?

<HL> 
Depending on the how often updates are made,  how long the time interval is
between the request is received and the operation is performed, and how soon
the requesting registrar inquires the result of the operation. The registrar
may not serilize the update operations on an object, i.e., wait for the
first update to be completed before requesting another. At least we are not
making such an assumption.
<HL/> 

Is the registry providing synchronization services for a registrar that is
making multiple writes against an object it sponsors, or is this some form
of "dualing registrars" and non-sponsored objects? Please clarify.

<HL>
In this context, I am talking about the sponsoring registrar only. If by
registry synchronization service, you meant that the backend serilizes the
write operations against the same object, then my asnwer is yes as most
databases will do the same. I am not saying it is trivial, but it can be
done.

Do we need more information from EPP, such as time-stamp, to make it easier
for the registry? It certainly would help in the long run as we expand the
usage to EPP to areas other than registry-registrar. I leave it to the WG to
decide whether we want to do it now or later. 
Maybe the transaction ID can serve the purpose for now.
<HL/>

Eric

To: "Liu, Hong" <[email-masked]>
cc: "'Hollenbeck, Scott'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Pending Update 
Date: Thu, 28 Feb 2002 13:07:54 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> Another issue that arises in the context of asynchrony is the notification
> mechansim ...

push vs poll.

For some reason, and we are indifferent to which, the state of a datum in
the registrar-registry "shared data" is inconsistent, and the instance of
the datum in the registry is later than the instance of the datum in the
(sponsoring) registrar, and we believe that time goes forward most of the
time.

> Is this an implementation issue or an EPP issue? I would like to hear from
> you and others on the list. Thanks!

push vs poll. Covered in _extensive_ detail in this list. 

> ... multiple asynchronous update operations on the same object.

How does this condition non-trivially arise?

Is the registry providing synchronization services for a registrar that is
making multiple writes against an object it sponsors, or is this some form
of "dualing registrars" and non-sponsored objects? Please clarify.

Eric

From: "Liu, Hong" <[email-masked]>
To: "'Hollenbeck, Scott'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Pending Update
Date: Thu, 28 Feb 2002 11:03:49 -0600
Sender: [email-masked]

Scott,

Thanks for suggesting a solution to this problem. I like your proposal for
adding a new response code "Command completed successfully; action pending"
and adding a new status "pendingVerification" to the host object.

Just to push this a bit further. It would be nice that EPP provides generic
mechanisms for asynchronous operations for object creation/update/deletion.
(Whether such mechanisms will be used is a matter of registry policy, which
is outside of the scope of EPP.) For example, your proposal can also be
applied to the contact object. In this case, the new status code will have
to be defined in the contact object as well.

Another issue that arises in the context of asynchrony is the notification
mechansim after the operation is indeed completed by the registry backend.
For create and delete, a simple yes or no answer may suffice. For update,
the situation is a bit more complex. The registrar may want to know more
about whether the changes are made correctly according to the request. Of
course, it can use the <info> command. But doing so may generate unnecessary
traffics and place burden on the backend database. More importantly, it may
not get the correct snapshot of the object state in the database in the face
of multiple asynchronous update operations on the same object. 

Is this an implementation issue or an EPP issue? I would like to hear from
you and others on the list. Thanks!

Cheers,

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Thursday, February 28, 2002 9:39 AM
To: 'Liu, Hong'; [email-masked]'
Subject: RE: Pending Update

Hong,

There's a somewhat analogous situation related to creating domain names in
that sometimes the object really shouldn't be instantiated until after some
manual process determines that the domain is "valid".  Right now the specs
include a domain status of "pendingVerification" to note that a domain
object create command has been processed, but the action hasn't yet really
be completed.

As for the discussion requested below, I think it might be helpful to add a
response code that says something like "Command completed successfully;
action pending".  We have to separate command completion from back-end
processing such that we maintain the OLTP ACID properties (basically that
commands have no partial success or partial failure), so we need to note
that the command has been received and processed but that something else
needs to happen before some back-end stuff completes.  We could also add a
"pendingVerification" status to the host mapping to note the situation in
subsequent <info> command responses.

I'm not going to touch the documents again until we get some feedback from
the IESG, but adding a new response code and a new host status could well be
done when dealing with IESG comments.

-Scott- 

> -----Original Message-----
> From: Liu, Hong [mailto:[email-masked]]
> Sent: Wednesday, February 27, 2002 12:53 PM
> To: [email-masked]'
> Subject: Pending Update
> 
> 
> The current update operation defined in EPP is basically a 
> two step process:
> First, an update request is made by the registrar to the 
> registry. Second,
> the registry either rejects the request or performs the 
> operation; and a
> response is sent back to the registrar.
> 
> A pending update refers to a four step process: First, an 
> update request is
> made by the registrar to the registry. Second, the registry 
> acknowledges the
> request to the registrar but does not take action for the 
> moment, i.e., the
> update is pending. Third, upon further authorization, the 
> registry either
> rejects the request or performs the operation; then posts the 
> result to the
> message queue. Fourth, the registrar polls the message queue 
> to retrieve the
> result of the operation.
> 
> Conceptually, pending update is very similar to the transfer operation
> currently defined in EPP.
> 
> I would like to hear from the list how such operation is 
> supported by EPP.
> If this topic has been discussed before on the mailing list, I would
> appreciate pointers to the previous discussions.
> 

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Liu, Hong'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Pending Update
Date: Thu, 28 Feb 2002 09:38:48 -0500
Sender: [email-masked]

Hong,

There's a somewhat analogous situation related to creating domain names in
that sometimes the object really shouldn't be instantiated until after some
manual process determines that the domain is "valid".  Right now the specs
include a domain status of "pendingVerification" to note that a domain
object create command has been processed, but the action hasn't yet really
be completed.

As for the discussion requested below, I think it might be helpful to add a
response code that says something like "Command completed successfully;
action pending".  We have to separate command completion from back-end
processing such that we maintain the OLTP ACID properties (basically that
commands have no partial success or partial failure), so we need to note
that the command has been received and processed but that something else
needs to happen before some back-end stuff completes.  We could also add a
"pendingVerification" status to the host mapping to note the situation in
subsequent <info> command responses.

I'm not going to touch the documents again until we get some feedback from
the IESG, but adding a new response code and a new host status could well be
done when dealing with IESG comments.

-Scott- 

> -----Original Message-----
> From: Liu, Hong [mailto:[email-masked]]
> Sent: Wednesday, February 27, 2002 12:53 PM
> To: [email-masked]'
> Subject: Pending Update
> 
> 
> The current update operation defined in EPP is basically a 
> two step process:
> First, an update request is made by the registrar to the 
> registry. Second,
> the registry either rejects the request or performs the 
> operation; and a
> response is sent back to the registrar.
> 
> A pending update refers to a four step process: First, an 
> update request is
> made by the registrar to the registry. Second, the registry 
> acknowledges the
> request to the registrar but does not take action for the 
> moment, i.e., the
> update is pending. Third, upon further authorization, the 
> registry either
> rejects the request or performs the operation; then posts the 
> result to the
> message queue. Fourth, the registrar polls the message queue 
> to retrieve the
> result of the operation.
> 
> Conceptually, pending update is very similar to the transfer operation
> currently defined in EPP.
> 
> I would like to hear from the list how such operation is 
> supported by EPP.
> If this topic has been discussed before on the mailing list, I would
> appreciate pointers to the previous discussions.
> 

From: [email-masked]
To: [email-masked]
Date: Thu, 28 Feb 2002 07:04:02 +0700
Subject: Re: Mapping IP Addresses to Geographic Location 
Content-description: Mail message body
Sender: [email-masked]

On 27 Feb 2002 at 15:48, Eric Brunner-Williams in Portland Maine 
wrote:

> host-by-addr (an instance of object-by-attribute) raises two issues:
> 
> 	o existance and relevenacy of object-by-attribute mechanism, a
> 	  general question of specification scope, and data specification,
> and
> 	o reverse lookup, mapping ip addresses to geographic location, a
> 	  specific question of relevance where locality of reference is
> 	  not casual.

Not sure whether that's going to be popular.
I don't put exact geographical location (or info about
OS of our names servers) in our DNS record.
For security/privacy reasons. I suspect others would
do the same.

But there are times (actually numerous) that I want
to find the geographical location of an intruder
(for example). Frequently I use
   <http://visualroute.visualware.com>
to find out where the attacker/intruder came from.
Of course, it doesn't give the *exact* geographical
location. But close enough. And still preserves privacy.
(I think.)

my 2 cents.
-- budi

To: [email-masked]
Subject: Mapping IP Addresses to Geographic Location 
Date: Wed, 27 Feb 2002 15:48:17 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

host-by-addr (an instance of object-by-attribute) raises two issues:

	o existance and relevenacy of object-by-attribute mechanism, a
	  general question of specification scope, and data specification,
and
	o reverse lookup, mapping ip addresses to geographic location, a
	  specific question of relevance where locality of reference is
	  not casual.

Scott Hollenbeck has responded to the first issue, I agree with Scott.

About 18 months ago, the W3C's Technology and Society Domain's Privay
Activity's, P3P Project's Specification Working Group (P3P Spec WG) hit
on the problem of reverse lookup -- mapping addresses to locations.

I happen to know this fairly well as it came down to two positions: the
first, articulated by Martin Presler-Marshall of IBM, was that a /24 (old
Class C) mask on ip addresses captured by data collectors was sufficient
to provide a reasonable degree of privacy. The second was that RIR and
LIR masks were trivially accessible, that looking beyond the ISP to the
end-point (or /24 of theoretically simultanious active dhcp end-points)
was intrusive on the ISP's business model, in addition to the end-user
expectation of privacy (from provider/location/timeofday/demographic based
profiling). I articulated the second view, working at the tim to enable
statistical, not deterministic, profiling, and avoid "over-capture".

Martin's point of view prevailed, /24 is in the P3P spec, not /<bits>.

Other data points (pun intended)

Akamai's address space data base (EdgeScape db) provides, for an IP address 
(effectively a CIDR block):
	Country, State (US), City, Phone Area Code, Country,
	Latitude, Longitude, Time Zone, Network Type (Dialup/DSL/Cable)
	DMA: Designated Marketing Areas
	MSA: Metropolitan Statistical Areas
	PMSA: Primary Metropolitan Statistical Areas

see: http://www.akamai.com/en/html/services/ct_how_it_works.html

Quova's address space data base provides more or less the same thing.
see: http://www.quova.com/service.htm

They're not alone, I'm just not interested in calling an analyst for a
competitive analysis summary off of someone's SEC filings.

Having written portions of NeuStar's .US proposal, and having done all of
the research prior to November on the transition, I sympathize with the
incumbent operator. However, adding reverse lookup in any guise to EPP is
asking for trouble. There are registry operators who sell bulk registrant
data (to SPAMers). There are registrars who sell bulk registrant data (to
SPAMers). There are whois "miners" who sell bulk registrant data (to ...
SPAMers). This isn't a feature to add to the protocol core without due
reflection.

Inverting nameserver addresses (EPP hosts) to registrar and/or registrant
identities meets no obvious need, except in amazingly bad edge cases like
the .US TLD. It sets a precident for other forms of object-by-attribute,
which get bad really quick, and it is subject to misuse by design. This is
one of those places where locality of reference is not casual -- in fact,
the whole .US is currently laid out (and squatted upon) along locality lines.

Mechanism can not correct for a policy of laisse faire (par la lachete).

Eric

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Pending Update
Date: Wed, 27 Feb 2002 11:52:54 -0600
Sender: [email-masked]

The current update operation defined in EPP is basically a two step process:
First, an update request is made by the registrar to the registry. Second,
the registry either rejects the request or performs the operation; and a
response is sent back to the registrar.

A pending update refers to a four step process: First, an update request is
made by the registrar to the registry. Second, the registry acknowledges the
request to the registrar but does not take action for the moment, i.e., the
update is pending. Third, upon further authorization, the registry either
rejects the request or performs the operation; then posts the result to the
message queue. Fourth, the registrar polls the message queue to retrieve the
result of the operation.

Conceptually, pending update is very similar to the transfer operation
currently defined in EPP.

I would like to hear from the list how such operation is supported by EPP.
If this topic has been discussed before on the mailing list, I would
appreciate pointers to the previous discussions.

From: "Liu, Hong" <[email-masked]>
To: [email-masked]
Subject: RE: Reverse Lookup using IP Address in EPP? 
Date: Wed, 27 Feb 2002 09:56:37 -0600
Sender: [email-masked]

Asbjorn, Scott and Patrik,

Thanks for providing comments to this thread. To come to a closure on this
thread, I would like to summarize what I gathered from the list:

The question posted was: how can one find out the corresponding host
object(s) given an IP address, i.e., reverse lookup?

There are three methods suggested:

(1) Use whois query. This requires that all host objects be stored in the
whois database. It may or may not be the case depending on registry policy.

(2) Return the list of host objects currently using the IP address during
the creation of a new host object for the same IP address. This requires
extension to be defined in EPP for the response message of <host:create>
command.

(3) Extend <host:info> to allow query host objects based on an IP address.
This entails that the <host:info> command and response be modified.

(1) is out-of-band while (2) and (3) are in-band. Each has pros and cons. In
terms of the degree of changes required for EPP, (2) seems to be simpler and
less painful.

Comments?

--Hong

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: statusResultDataType
Date: Wed, 27 Feb 2002 09:22:42 -0500
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Wednesday, February 27, 2002 8:58 AM
> To: [email-masked]
> Subject: statusResultDataType
> 
> 
> Hi,
> 
> reading through the 05/06 drafts, I found the following:
> 
>   <complexType name="statusResultDataType">
>     <sequence>
>       <element name="clTRID" type="epp:trIDStatusType"
>        minOccurs="0"/>
>     </sequence>
>   </complexType>
> 
> In the 06-draft (Page 32) it states:
> 
> "Multiple elements MAY be returned if the server recognizes 
> the identifier and 
> the client does not enforce identifier uniqueness."
> 
> Am I missing something, or doesn't this mean that the element 
> should have a 
> maxOccurs="unbounded"?

Asbjorn,

Yes, someone else brought that error to my attention off-list.  It should
have a maxOccurs="unbounded" attribute, and it'll be added at the next
editing opportunity - most likely to deal with IESG or IETF last call
comments.

-Scott-

Date: 27 Feb 2002 13:58:14 -0000
From: [email-masked]
To: [email-masked]
Subject: statusResultDataType
Sender: [email-masked]

Hi,

reading through the 05/06 drafts, I found the following:

  <complexType name="statusResultDataType">
    <sequence>
      <element name="clTRID" type="epp:trIDStatusType"
       minOccurs="0"/>
    </sequence>
  </complexType>

In the 06-draft (Page 32) it states:

"Multiple elements MAY be returned if the server recognizes the identifier and 
the client does not enforce identifier uniqueness."

Am I missing something, or doesn't this mean that the element should have a 
maxOccurs="unbounded"?

Regards,

Asbjorn

-- 
 The information transmitted in this email is intended only for the person(s)
 or entity to which it is addressed and may contain proprietary, confidential
 and/or privileged material. If you have received this email in error, please
 contact the sender by replying and delete this email so that it is not
 recoverable. If you are not the intended recipient(s), any retention, review,
 disclosure, distribution, copying, printing, dissemination, or other use of,
 or taking of any action in reliance upon, this information is strictly
 prohibited and without liability on our part.

To: "Tomas Mackus" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Is this correct ? 
Date: Wed, 27 Feb 2002 08:19:40 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Tomas,

RRP questions can (should) be addressed directly to its authors, and to its
user community. This list is for collaborative specification of another
registry provisioning protocol, EPP.

Cheers,
Eric

From: "Tomas Mackus" <[email-masked]>
To: <[email-masked]>
Subject: Is this correct ?
Date: Wed, 27 Feb 2002 14:57:18 +0200
Sender: [email-masked]

Hello,

Just want to ask about domain name creation process in RRP.
For example registrar on behalf of registrant want to create:
domain: foo.tld
ns: ns1.foo.tld
ns: ns2.foo.tld

Then registrar have to make 4 actions ? Am I right ?
Create foo.tld with 0 ns associated (because ns1.foo.tld and ns2.foo.tld are
not registered and can't be registered without foo.tld)
Create ns1.foo.tld
Create ns2.foo.tld
Update foo.tld with registered name servers ns1 and ns2 ?

Best Regards,
Tomas

Date: 27 Feb 2002 09:54:05 -0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: Reverse Lookup using IP Address in EPP? 
Sender: [email-masked]

On Tue, 26 Feb 2002 16:49:43 -0600 "Liu, Hong" <[email-masked]> wrote:
>> The second question has to do with whois.
>
>[HL] I asked the question because whois was suggested by Scott and Patrik as
>out-of-band means to getting the job done. What I want to make sure is that
>whether ALL host objects created in the registry are available for query in
>the whois database.

As far as I can remember, nothing is mentioned in the EPP drafts about whois. 
Whereas you can be pretty sure that in-zone nameservers would always be in 
whois (due to the IP-information), I guess it would be Registry Policy whether 
or not to include non-nameserver hosts as well...

Asbjorn

-- 
 The information transmitted in this email is intended only for the person(s)
 or entity to which it is addressed and may contain proprietary, confidential
 and/or privileged material. If you have received this email in error, please
 contact the sender by replying and delete this email so that it is not
 recoverable. If you are not the intended recipient(s), any retention, review,
 disclosure, distribution, copying, printing, dissemination, or other use of,
 or taking of any action in reliance upon, this information is strictly
 prohibited and without liability on our part.

To: "Liu, Hong" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Reverse Lookup using IP Address in EPP? 
Date: Tue, 26 Feb 2002 22:00:47 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

>> Is "company Y" [and X] a registrar?
>
> Both X and Y are registrants.

I thought as much. Seng wanted to stretch the AAA envelope out to the edge
(registrants), cutting the registrars out of the AAA problem, and also out
of a constructive role in registry provisioning.

>>> ... how can the registry prevent IP address hijacking ...
>>
>> Let's clear up the first set of issues and identify who the actors are, then
>> see if this is an EPP issue, or a registry-on-the-brink-of-anarchy feature.
>
> I don't think the last part of the sentence is of relevance to this
> discussion.

OK. Then ".US"

It appears to me that you are trying to map EPP, which assumes some set of
boundary conditions, such as ICANN accredited, or similarly situated (read
"responsible") registrars, onto the .US booby hatch, where five fun lovin'
guys-n-gals "own" 40% of the metro areas.

You've got registrars (presumptive clue) bagging each other's registrants'
nameservers, and absent a pre-existing policy venue, you seem to be looking
for a technical mechanism to discover and/or cure bad acts. 

To stretch the authentication envelope out to the registrants, you may as
well revisit James' issues.

> If that was discussed before, I would like to know the result of the
> discussion. Any pointer would be appreciated.

   1  02/05 Patrick            Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Inter
   2  02/05 "Brian W. Spolari  RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Inter
   3  02/05 Patrick            Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Inter
   4  02/06 Sheer El-Showk     RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Inter
   5  02/07 "James Seng/Perso  Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Inter
   6  02/07 Urs Eppenberger    Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Inter
   7  02/07 Patrick            Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Inter

All dates are 2001. I suggest a look at the London notes as well.

>>> The second question has to do with whois.
>>
>> This isn't an EPP issue.
> 
> I asked the question because whois was suggested by Scott and Patrik as
> out-of-band means to getting the job done. What I want to make sure is that
> whether ALL host objects created in the registry are available for query in
> the whois database.

It is a reasonable question to ask a registry operator -- is the data stream
sunk by a protocol A server provably consistent with and exhaustive of some
subsequent access method of some possibly other protocol B server.

EPP is protocol A. It isn't protocol B.

I know the .US roll-out has to do better -- a lot better -- than the .biz
roll-out. The $20M figure has been public for ages, hence the 1M registrant
requirement just to make debt. But this isn't this WG's problem, it isn't a
protocol problem. If the .US cyber-squatters are converted into registrars,
they win the business proposition, and that's fine. If the gTLD registrars
peel 1M off of .com, they win the churn, and that's fine too. Either way
(assumptions being true by desire alone) and a operator avoids failure.

But your registry's business model validation isn't this WG's problem. The
US, and a company, aren't the controlling interests today, just as they
weren't the controlling interests when it was another DoC problem and another
company.

Feel free to ignore the following:

	o go back to the req draft, and _liberally_ wack out anything that
	  looks and feels "normal" (.com aka "gTLD" mindset), then
	o summarize the actual situation of your ccTLD, then
	o pretend its the Falkland Islands, not the US, and try to find the
	  bits that are common to both the .US zoo and the Falkland sheep,
and then
	o conservatively extend EPP (or vary from EPP/RRP/SRS/...) to the
	  core problem you are trying to solve (which may be very close to
	  the problem James was trying to solve).
	o drop this WG a note that explains most (maybe not #2) of the above.
or
	o go forth and specify the non-EPP registry-registrar protocol for
	  .US and/or the Falkland Islands or where ever.

Cheers,
Eric

From: "Liu, Hong" <[email-masked]>
To: [email-masked]
Subject: RE: Reverse Lookup using IP Address in EPP? 
Date: Tue, 26 Feb 2002 16:49:43 -0600
Sender: [email-masked]

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:[email-masked]]
Sent: Tuesday, February 26, 2002 4:34 PM
To: Liu, Hong
Cc: [email-masked]; [email-masked]
Subject: Re: Reverse Lookup using IP Address in EPP? 

> Suppose company X has created a host object ...

Is "company X" a registrar?

> Now company Y, who has the IP address ...

Is "company Y" a registrar?

[HL] Both X and Y are registrants. Their respective registrars act on their
behalf to create the host objects.

> ... how can the registry prevent IP address hijacking ...

Let's clear up the first set of issues and identify who the actors are, then
see if this is an EPP issue, or a registry-on-the-brink-of-anarchy feature.

[HL] I don't think the last part of the sentence is of relevance to this
discussion.

James Seng raised this issue a year ago (Feb 7), if I understand the problem
posed.

[HL] If that was discussed before, I would like to know the result of the
discussion. Any pointer would be appreciated.

> The second question has to do with whois.

This isn't an EPP issue.

[HL] I asked the question because whois was suggested by Scott and Patrik as
out-of-band means to getting the job done. What I want to make sure is that
whether ALL host objects created in the registry are available for query in
the whois database.

Eric

To: "Liu, Hong" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Reverse Lookup using IP Address in EPP? 
Date: Tue, 26 Feb 2002 16:34:12 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> Suppose company X has created a host object ...

Is "company X" a registrar?

> Now company Y, who has the IP address ...

Is "company Y" a registrar?

> ... how can the registry prevent IP address hijacking ...

Let's clear up the first set of issues and identify who the actors are, then
see if this is an EPP issue, or a registry-on-the-brink-of-anarchy feature.

James Seng raised this issue a year ago (Feb 7), if I understand the problem
posed.

> The second question has to do with whois.

This isn't an EPP issue.

Eric

From: "Liu, Hong" <[email-masked]>
To: [email-masked]
Subject: RE: Reverse Lookup using IP Address in EPP?
Date: Tue, 26 Feb 2002 14:52:33 -0600
Sender: [email-masked]

I would like to back off a bit to talk about the problems before jumping on
solutions. Specifically, I have two questions to the list:

The first question has to do with 1 IP address. Suppose company X has
created a host object fake.x.foo using IP address 1.2.3.4, which is NOT the
IP address that X is allocated to use. This host object is NOT being used as
a nameserver for x.foo. Now company Y, who has the IP address, is trying to
create a host object real.y.foo. 
- If the 1 IP address policy is imposed, then the creation of real.y.foo
will be rejected. Company Y wants to find out why this is the case. The
question is how.
- If no such policy is in place, how can the registry prevent IP address
hijacking from company X (intentionally or un-intentionally)?

The second question has to do with whois. Since not all host objects are
nameservers, they are not necessarily associated with registered domains.
Are those non-NS host objects also stored in the whois database?

Your comments are much appreciated.

--Hong

To: "Liu, Hong" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Reverse Lookup using IP Address in EPP? 
Date: Tue, 26 Feb 2002 13:45:36 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> ... an unique IP address be assigned
> to each name server ...

Is substance of this claimed to be a protocol issue or a registry practices
issue?

Scott observed:
> ... doing object lookup using an object attribute as a key,
> which is out of place in a provisioning protocol.  

Agreed.

And:

> I would also like to hear other alternatives for
> solving this problem.

There doesn't yet appear to be a problem statement.

Eric

Date: Tue, 26 Feb 2002 19:17:31 +0100
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: Reverse Lookup using IP Address in EPP?
Organization: Gandi
Sender: [email-masked]

On Tue, Feb 26, 2002 at 11:42:44AM -0600, Liu, Hong took time to write:
> The current registry practice requires that an unique IP address be assigned
> to each name server in the same name space. That is, if an IP address is

It seems not to be true anymore for Verisign.

> already used by an NS, it cannot be used for another NS. It is very
> difficult to find out which host has used the IP address, without looking at
> the zone file, or calling customer support. Even zone files may not contain
> the host if it is an orphan NS in the registry. This is the out-of-band
> method.

There is no need to. whois (Registry) is sufficient, as long as it
contains data about nameservers and that it can be queried by
nameserver's name or by IP.

This is the current case of whois.Verisign-grs.net

> One possible way to resolve this issue is to provide reverse lookup based on
> an IP address via the registrar-registry interface, i.e., in-band method.
> Based on the returned host name, the requesting party knows whether that
> host is still in use as an NS or not. In the case of an orphan NS, the
> requesting party can tell the registry to remove the A RR for the host.

I would suggest something simpler if you really want the
restriction of 1 IP :
when you create a nameserer and that fails because the IP is already
used, put the nameserver already registered with the given IP in the
error message of the creation.

Patrick.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Liu, Hong'" <[email-masked]>, [email-masked]
Subject: RE: Reverse Lookup using IP Address in EPP?
Date: Tue, 26 Feb 2002 13:04:42 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Liu, Hong [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 12:43 PM
> To: [email-masked]
> Subject: Reverse Lookup using IP Address in EPP?
> 
> 
> The current registry practice requires that an unique IP 
> address be assigned
> to each name server in the same name space. That is, if an IP 
> address is
> already used by an NS, it cannot be used for another NS. It is very
> difficult to find out which host has used the IP address, 
> without looking at
> the zone file, or calling customer support. Even zone files 
> may not contain
> the host if it is an orphan NS in the registry. This is the 
> out-of-band
> method.

FWIW our requirements draft specifically says (see 3.4.2-[3]) that an IP
address can be associated with multiple registered hosts.  EPP doesn't
include any restrictions in this regard.

> One possible way to resolve this issue is to provide reverse 
> lookup based on
> an IP address via the registrar-registry interface, i.e., 
> in-band method.
> Based on the returned host name, the requesting party knows 
> whether that
> host is still in use as an NS or not. In the case of an orphan NS, the
> requesting party can tell the registry to remove the A RR for 
> the host.
> 
> However, this requires that the current EPP protocol be 
> extended to include
> such capability in the host mapping part. I would like to 
> know how the WG
> feels about this issue. I would also like to hear other 
> alternatives for
> solving this problem.

We talked about this some time ago.  My argument against it at the time was
that it involves doing object lookup using an object attribute as a key,
which is out of place in a provisioning protocol.  As far as I know most
operators make it possible to use whois to find hosts by IP address.

-Scott-

Date: Tue, 26 Feb 2002 09:51:33 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: "Liu, Hong" <[email-masked]>
cc: <[email-masked]>
Subject: Re: Reverse Lookup using IP Address in EPP?
Sender: [email-masked]

good suggestion. I can see the benifit of leverse lookups of name servers
within the spec.

-rick

On Tue, 26 Feb 2002, Liu, Hong wrote:

> The current registry practice requires that an unique IP address be assigned
> to each name server in the same name space. That is, if an IP address is
> already used by an NS, it cannot be used for another NS. It is very
> difficult to find out which host has used the IP address, without looking at
> the zone file, or calling customer support. Even zone files may not contain
> the host if it is an orphan NS in the registry. This is the out-of-band
> method.
>
> One possible way to resolve this issue is to provide reverse lookup based on
> an IP address via the registrar-registry interface, i.e., in-band method.
> Based on the returned host name, the requesting party knows whether that
> host is still in use as an NS or not. In the case of an orphan NS, the
> requesting party can tell the registry to remove the A RR for the host.
>
> However, this requires that the current EPP protocol be extended to include
> such capability in the host mapping part. I would like to know how the WG
> feels about this issue. I would also like to hear other alternatives for
> solving this problem.
>
> Cheers,
>
> --Hong
>

From: "Liu, Hong" <[email-masked]>
To: [email-masked]
Subject: Reverse Lookup using IP Address in EPP?
Date: Tue, 26 Feb 2002 11:42:44 -0600
Sender: [email-masked]

The current registry practice requires that an unique IP address be assigned
to each name server in the same name space. That is, if an IP address is
already used by an NS, it cannot be used for another NS. It is very
difficult to find out which host has used the IP address, without looking at
the zone file, or calling customer support. Even zone files may not contain
the host if it is an orphan NS in the registry. This is the out-of-band
method.

One possible way to resolve this issue is to provide reverse lookup based on
an IP address via the registrar-registry interface, i.e., in-band method.
Based on the returned host name, the requesting party knows whether that
host is still in use as an NS or not. In the case of an orphan NS, the
requesting party can tell the registry to remove the A RR for the host.

However, this requires that the current EPP protocol be extended to include
such capability in the host mapping part. I would like to know how the WG
feels about this issue. I would also like to hear other alternatives for
solving this problem.

Cheers,

--Hong

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: test
Date: Tue, 26 Feb 2002 11:26:17 -0600
Sender: [email-masked]

This is a test. Please ignore.

To: Edward Lewis <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Call for agenda items for Minneapolis 
Date: Tue, 26 Feb 2002 11:50:43 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ed,

The WG has an interest, if only to prevent "end-runs" that the IESG may not
catch, in any draft that purports to be proximal to, or responsive to, the
requirements draft. The better interest is that the draft may be of general
interest to the implementors.

A long-winded "agree" to the point that "the WG is [not] limited to just
the core/standard documents".

The operation of a registry, in the abstract, isn't something that admits
"interoperation", unless the registy has more than one operator, either
concurrently or (proximally) consequetively. 

The policy of of a ccTLD delegation, in the abstract, isn't something that
admits "interoperation", unless delegation is multiply concurrently or
(proximally) consequetively instantiated.

In short, if we close our eyes to the fact that this is a specific operator
and a specific ccTLD, it is difficult to find where a second implementation
that could be interoperable, or not, is technically [1] feasible. If it makes
a difference that the delegation is ".US", or the operator favored as "second
after Verisign", then the WG is (temporarily) embarked on some national or
marketing detour.

We adopted XML. This is one of the distinguishing features of EPP.

There are alternatives:

	o RRP (versions 1.0 and version 1.1) uses name-value pairs,
	o SRS (versions 1.0, 1999 and version 2.0, 2001) uses name-value
	  pairs [2],
	o others, specifications not generally available

For reasons others can enquire into, the authors of this draft chose not to
use a schema, and opted out of XML as a design constraint. I noted earlier
that a name-value space similar to that proposed in this draft has been
investigated in the W3C PICS activity. It is hard to describe relationships
using this techniques [3], as most everyone involved, including the current
IAB chair, knows.

We could, without prejudice to the draft, consensus that name-value pairs
are out-of-scope for the PROVREG WG. I think we did this some (long) time
ago, but maybe not.

Well, I've got to go pick up kids.

Eric

[1] Any of these -- a partitioned .US registry (or a competitive registry),
multiple applicable policies for .US registries, registrars, and registrants,
and (to be sure) a non-unique delegation, would be interesting, and novel.
None is proposed.

[2] Elmar Knipp <[email-masked]> December 10, 2001.

[3] http://www.w3.org/2001/Talks/09xx-semwai/all

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-grrp-reqs-06.txt
Date: Tue, 26 Feb 2002 07:05:16 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Generic Registry-Registrar Protocol Requirements
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-grrp-reqs-06.txt
	Pages		: 24
	Date		: 25-Feb-02
	
This document describes high-level functional and interface
requirements for a client-server protocol for the registration and
management of Internet domain names in shared registries. Specific
technical requirements detailed for protocol design are not presented
here.  Instead, this document focuses on the basic functions and
interfaces required of a protocol to support multiple registry and
registrar operational models.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-grrp-reqs-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-grrp-reqs-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-grrp-reqs-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-grrp-reqs-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 26 Feb 2002 00:43:04 -0800
To: Edward Lewis <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: RE: Call for agenda items for Minneapolis
Cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Sender: [email-masked]

At 08:45 PM 2/25/2002 -0500, Edward Lewis wrote:
>Hmmmm.  I am unsure of this but I think the WG is permitted to review
>extenstions that benefit a minority of of users (in this case, specifically
>registries).  This would demontrate the "extensibility" of the base and
>encourage safe extenstions.

For a protocol expected to be used in many environments that will want 
local tailoring, there is quite a bit of benefit in considering specific, 
local efforts for just the reason you cite, namely to ensure that local 
extensions are not overly painful.

And as Eric notes, the WG should keep an eagle eye out, looking for kernels 
of generality to folk into the base protocol.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  (new)fax +1.408.850.1850

Date: Mon, 25 Feb 2002 20:33:38 -0500
To: "Hollenbeck, Scott" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: grrp - object deletion
Cc: "'Tomas Mackus'" <[email-masked]>, [email-masked]
Sender: [email-masked]

This is the kind of issue, if spurred by difficulties in generating
interoperable implementations, that would be addressed in a next round of
the specifications.  I.e., we are submitting the documents (should be in
the past tense now) for the first level of standardization.  (I believe
this is Proposed, I admit I keep forgetting the correct tag.)  If all goes
smoothly (and it never does), we need to have some time elapse and
implementations interoperate before submitting for the next level of
standard - Draft.

So, earmark issues encountered when implementing, more for input to the
next set of documents.  (Of course, if we need to recycle at Proposed or
resubmit, then we can consider refinements.)

None of what I have said addresses the data consistency comment by Scott, I
just wanted to address the last sentence.

At 10:16 AM -0500 2/20/02, Hollenbeck, Scott wrote:
>Thomas,
>
>I didn't write such text in the requirements document because I thought it
>crosses into being a data consistency issue rather than being a functional
>protocol requirement.  Plus, with the document now in the hands of the IESG
>I'm loath to make any changes that aren't directed by them as part of the
>last call process.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Do you have the time to listen to me whine
About nothing and everything all at once?
-- Green Day ("Basket Case")

Opinions expressed are property of my evil twin, not my employer.

Date: Mon, 25 Feb 2002 20:45:06 -0500
To: "Hollenbeck, Scott" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: Call for agenda items for Minneapolis
Cc: [email-masked]
Sender: [email-masked]

At 12:42 PM -0500 2/19/02, Hollenbeck, Scott wrote:
>> From: Eric Brunner-Williams in Portland Maine
>>
>> The authors have created a registry-private extension, as other registries
>> have for trademark data, and no doubt will continue to experiment with as
>> the registry experience matures. Such things are properly in operational
>> registry practices documents, or informational I-Ds, not requiring working
>> group change control and process.
>
>I have to agree with Eric.  I'd prefer that we spend meeting time on topics
>of concern to the WG as a whole.

Hmmmm.  I am unsure of this but I think the WG is permitted to review
extenstions that benefit a minority of of users (in this case, specifically
registries).  This would demontrate the "extensibility" of the base and
encourage safe extenstions.

Such a document may lead to a non-standards document, e.g., informational
or experimental.  I'm not giving the green-light for a full bore
consideration here, but I do want to point out that the WG is limited to
just the core/standard documents.

Also, being that we (the chairs) haven't see (m)any other agenda
suggestions and there was a request for 2 hours, we need to ask: What
topics are to be discussed in Minneapolis.  (The chairs want to hear from
the WG.)

(That is besides the obvious - core spec status, implementations...)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Do you have the time to listen to me whine
About nothing and everything all at once?
-- Green Day ("Basket Case")

Opinions expressed are property of my evil twin, not my employer.

From: "Hollenbeck, Scott" <[email-masked]>
To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <[email-masked]>, [email-masked], Jaap Akkerhuis <[email-masked]>, Ed Lewis <[email-masked]>
Cc: Ned Freed <[email-masked]>
Subject: RE: Comments from IESG on draft-ietf-provreg-grrp-reqs-05.txt
Date: Fri, 22 Feb 2002 09:25:41 -0500
Sender: [email-masked]

Thanks to Patrik for quickly pulling together some clarifying information I
needed to modify the requirements draft per IESG review comments.  I just
sent the updated document to the I-D administrator - hopefully for the last
time!

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <[email-masked]>, [email-masked], Jaap Akkerhuis <[email-masked]>, Ed Lewis <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
Cc: Ned Freed <[email-masked]>
Subject: RE: Comments from IESG on draft-ietf-provreg-grrp-reqs-05.txt
Date: Thu, 21 Feb 2002 13:59:09 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Patrik Fältström [mailto:[email-masked]]
> Sent: Thursday, February 21, 2002 1:31 PM
> To: [email-masked]; Jaap Akkerhuis; Ed Lewis;
> [email-masked]
> Cc: Ned Freed
> Subject: Comments from IESG on draft-ietf-provreg-grrp-reqs-05.txt
> 
> 
> (1) CORE used but not defined.

CORE _is_ defined in section 1.1.  It can be removed completely if the IANA
considerations section is rewritten.

> (2) Reference in appx to IANA ports only.

I don't understand this comment.

> (3) 3.1[7] refers to transactional security without defining it.

Actually, it's transactional _integrity_, not security.  I can add a
sentence to explain what that means.

> (4) 3.4.2[2] talks about validity without defining it - in particular,
> preemption not discussed.

Would it be adequate to simply change "validity period" to "registration
period"?

> (5) 3.4.3[2] has 1 IP address with multiple name servers. Is 
> that really
> what you want?

Yes, per WG discussion it sure is.

> (6) 3.4.3 does not require the association of info with 
> registrars, but
> assumes it in [4].

Hmm, OK, so I need to add an explicit requirement to note that objects are
managed by a particular registrar/client?

> (7) 3.4.5 does not require the ability to do unapproved 
> transfer (such as
> if registrar is dead).

Actually, I think it's covered in 3.4.5-[4].  A dead registrar can't do
anything.

> (8) Section 4 (MUST not introduce limitations) is not really possible.

Sure it's possible.  The whole idea of this section is to help ensure that
the protocol specification doesn't get into defining implementation
specifics.  It might be possible to collapse the entire section into a
"don't limit implementation" statement, but I'd really like more guidance on
what needs to be changed here.

> (9) Internationalization requirements are (surprisingly) 
> reasonably OK.

Good!

> (10) Searchability requirements are VERY weak (by ID only) - that is
> probably how it should be.

Yes -- we're talking about requirements for a provisioning protocol, not a
search or lookup protocol.

> (11) The ID has NSI-specific registrations in it even though 
> its a WG doc,
> i.e. if the registrations has to be done, they should be in a separate
> document

The text says that what's in there aren't registrations to be done, they are
registrations that have been done in the past - which includes more than
just NSI-specific stuff.  Like I said, though, I'll gladly rewrite this
section.

> (12) The IANA considerations says:
> These assignments should be preserved as long as the 
> corresponding systems
> are operational.  Additional IANA services might be required 
> to support
> testing and deployment of protocol implementations.
> 
> 1/ how whould the IANA know to zap registrations?
>    (this partcular problem is removed if the NSI 
> registrations are removed)
> 2/ how is the IANA to know what to do to do the additiopnal 
> registrations?

Any needed additional registrations will have to be documented in
appropriate documents.  Perhaps that's all the IANA considerations section
should say.

Patrik, can you provide more specific instructions on what needs to be
changed, or are my suggestions above adequate?  I'd really like to make sure
that the next edit addresses these comments, but I need more detail to be
able to do that.

-Scott-

Date: Thu, 21 Feb 2002 19:31:06 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: [email-masked], Jaap Akkerhuis <[email-masked]>, Ed Lewis <[email-masked]>, [email-masked]
cc: Ned Freed <[email-masked]>
Subject: Comments from IESG on draft-ietf-provreg-grrp-reqs-05.txt
Sender: [email-masked]

(1) CORE used but not defined.

(2) Reference in appx to IANA ports only.

(3) 3.1[7] refers to transactional security without defining it.

(4) 3.4.2[2] talks about validity without defining it - in particular,
preemption not discussed.

(5) 3.4.3[2] has 1 IP address with multiple name servers. Is that really
what you want?

(6) 3.4.3 does not require the association of info with registrars, but
assumes it in [4].

(7) 3.4.5 does not require the ability to do unapproved transfer (such as
if registrar is dead).

(8) Section 4 (MUST not introduce limitations) is not really possible.

(9) Internationalization requirements are (surprisingly) reasonably OK.

(10) Searchability requirements are VERY weak (by ID only) - that is
probably how it should be.

(11) The ID has NSI-specific registrations in it even though its a WG doc,
i.e. if the registrations has to be done, they should be in a separate
document

(12) The IANA considerations says:
These assignments should be preserved as long as the corresponding systems
are operational.  Additional IANA services might be required to support
testing and deployment of protocol implementations.

1/ how whould the IANA know to zap registrations?
   (this partcular problem is removed if the NSI registrations are removed)
2/ how is the IANA to know what to do to do the additiopnal registrations?

        paf

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Roger Castillo Cortazar'" <[email-masked]>, [email-masked]
Subject: RE: Identifiers, Handles and ROID's
Date: Wed, 20 Feb 2002 15:05:55 -0500
Sender: [email-masked]

Roger,

I'll have to fix the text in 2.7 of epp-06 when dealing with IESG comments
to make it match the schema (long since changed per WG discussion); the text
reflects an earlier approach.  The text that's in there now must've slipped
through -- thanks for catching it.

I'm _not_ going to re-enter the handle/ROID discussion other than saying
that the ROID in the specs and the "globally unique identifier" in the
requirements are intended to be the same thing... ;-)

-Scott- 

> -----Original Message-----
> From: Roger Castillo Cortazar [mailto:[email-masked]]
> Sent: Wednesday, February 20, 2002 2:39 PM
> To: [email-masked]
> Subject: Identifiers, Handles and ROID's
> 
> 
> Hi everybody.
> I have a few questions about the globally unique identifiers 
> for objects.
> 
> In the reqs. we can read.
> 
> 3.4.1 Object Identification
> ...
>    [2] Object identifiers MUST be globally unique.
> ...
>    [6] An object's identifier MUST be generated and stored 
> when an object
>    is created.
> 
> Nothing about the indentifier being returned to the client.
> 
> Now, in the EPP specs.
> 
> 2.7 Object Identification
> ...
>    Globally unique identifiers can help facilitate object information
>    sharing between repositories.  A globally unique identifier MUST be
>    assigned to every object when the object is created, and the
>    identifier MUST be returned within the response for the 
> command that
>    created the object.
> ...
> 
> Followed by the algorithm to create such identifier.
> 
> But an identifier as described by that algorithm is not 
> returned by the 
> <create> command as described in the specs.
> 
> 
> And more ....
> 
> This could be silly, but I've been reading past year messages 
> on the topic 
> of unique handle generation
> to try to figure out a few things, and I just may need a few 
> clarifications.
> 
> I can see three concepts here:
> 
> - The handle as discussed on the list almost a year ago,
> - The globally unique identifier as can be read in the drafts,
> - The ROID's as returned in the <info> command response.
> 
> Are all these the same thing ?
> 
> The discussed handle is the local part of the globally unique 
> identifier ?
> Are the contact-id and the FQDN for the domains and hosts 
> instances of any 
> of these identifiers ?
> 
> Greetings.
> 
> 
> Roger Castillo Cortazar
> NIC-Mexico http://www.nic.mx
> 

Date: Wed, 20 Feb 2002 13:38:55 -0600
To: [email-masked]
From: Roger Castillo Cortazar <[email-masked]>
Subject: Identifiers, Handles and ROID's
Sender: [email-masked]

Hi everybody.
I have a few questions about the globally unique identifiers for objects.

In the reqs. we can read.

3.4.1 Object Identification
...
   [2] Object identifiers MUST be globally unique.
...
   [6] An object's identifier MUST be generated and stored when an object
   is created.

Nothing about the indentifier being returned to the client.

Now, in the EPP specs.

2.7 Object Identification
...
   Globally unique identifiers can help facilitate object information
   sharing between repositories.  A globally unique identifier MUST be
   assigned to every object when the object is created, and the
   identifier MUST be returned within the response for the command that
   created the object.
...

Followed by the algorithm to create such identifier.

But an identifier as described by that algorithm is not returned by the 
<create> command as described in the specs.

And more ....

This could be silly, but I've been reading past year messages on the topic 
of unique handle generation
to try to figure out a few things, and I just may need a few clarifications.

I can see three concepts here:

- The handle as discussed on the list almost a year ago,
- The globally unique identifier as can be read in the drafts,
- The ROID's as returned in the <info> command response.

Are all these the same thing ?

The discussed handle is the local part of the globally unique identifier ?
Are the contact-id and the FQDN for the domains and hosts instances of any 
of these identifiers ?

Greetings.

Roger Castillo Cortazar
NIC-Mexico http://www.nic.mx

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Tomas Mackus'" <[email-masked]>
Cc: [email-masked]
Subject: RE: grrp - object deletion
Date: Wed, 20 Feb 2002 10:16:28 -0500
Sender: [email-masked]

Thomas,

I didn't write such text in the requirements document because I thought it
crosses into being a data consistency issue rather than being a functional
protocol requirement.  Plus, with the document now in the hands of the IESG
I'm loath to make any changes that aren't directed by them as part of the
last call process.

-Scott- 

> -----Original Message-----
> From: Tomas Mackus [mailto:[email-masked]]
> Sent: Wednesday, February 20, 2002 10:10 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: grrp - object deletion
> 
> 
> >3.4.2 Object Registration
> ....
> 
> >  [3] The protocol MUST provide services to register name servers.  Name
> >  server registration MUST NOT be limited to a specific period of time.
> >  Name servers MUST be registered with a valid IPv4 or IPv6 address when
> >  a "glue record" is required for delegation.
> 
> 
> >3.4.7 Object Deletion
> >  [1] The protocol MUST provide services to remove a domain name from
> >  the registry.
> >  [2] The protocol MUST provide services to remove a name server from
> >  the registry.
> 
> 
> 
> Mabe in 3.4.7 [1] should be mentioned, that name servers MUST 
> be deleted
> with domain name from registry, if these name servers are 
> subdomains of this
> domain name...i.e. glue records MUST be deleted too....
> 
> 
> Tomas
> 

From: "Tomas Mackus" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: grrp - object deletion
Date: Wed, 20 Feb 2002 17:10:24 +0200
Sender: [email-masked]

>3.4.2 Object Registration
....

>  [3] The protocol MUST provide services to register name servers.  Name
>  server registration MUST NOT be limited to a specific period of time.
>  Name servers MUST be registered with a valid IPv4 or IPv6 address when
>  a "glue record" is required for delegation.

>3.4.7 Object Deletion
>  [1] The protocol MUST provide services to remove a domain name from
>  the registry.
>  [2] The protocol MUST provide services to remove a name server from
>  the registry.

Mabe in 3.4.7 [1] should be mentioned, that name servers MUST be deleted
with domain name from registry, if these name servers are subdomains of this
domain name...i.e. glue records MUST be deleted too....

Tomas

To: "Damaraju, Ayesha" <[email-masked]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, "Liu, Hong" <[email-masked]>, Edward Lewis <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Call for agenda items for Minneapolis 
Date: Tue, 19 Feb 2002 18:10:24 -0800
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> ... not a good idea to use name value pairs in a string - with no schema
> definition it kills the purpose of XML & XML validators

Yup. The document (whether a registry operational document, or an I-D) could
have referenced or modified existing schema, or proposed something useful. A
name value pair is simply ... pre-XML. Fine for RRP-esque things (no offense
intended to the RRP-esque afficianados), but infra-dig for EPP.

Eric

To: "Liu, Hong" <[email-masked]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, Edward Lewis <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Call for agenda items for Minneapolis 
Date: Tue, 19 Feb 2002 16:29:54 -0800
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> Nice to see you jump in on this. You are right, it IS an informational I-D
> as an individual submission to the WG. What do you think?

Registries have policies. Policies can be generalized until one or more
mechanism(s) are identified that allow a class or classes of policies.

We could see informationals from every registry, each full of specific
utility and gratifying some specific external audience -- Karen Rose in
the case at hand -- but not intended for implementors of interoperable
services.

An I-D could be useful, contain the grain of an idea that is generally
useful, and scoped policy is a generally useful idea. We are, as a group,
still working on policies that span scopes, e.g., data collection and the
multi-jurisdictional registration systems and the trans-jurisctional flow
of registrations within a single registration system. Scope tied to a
namespace is already in "our scope", so submission "to the WG" is either
late or redundant.

Turning to the specifics:

What NeuStar proposed in addressing the nexus requirement was:

	registrars obtain (from registrants) certification that
		o the US DoC's nexus requirement is met,
	and
		o the manner in which the requirement is met

There is no protocol requirement here. The provisioning of registrars by
registrants, however done, and consisting of whatever data, is outside
the scope of this registry provisioning protocol.

As Scott has pointed out many times, there are issues that are adequately
covered by contract, and need not have any articulation within a protocol.
This is just such a case.

In addition, NeuStar proposed to check selected data provided by the
candidate registrant, e.g., valid US ZIP code.

There is no _new_ protocol requirement in this statement either.

Finally, NeuStar proposed to check the information provided for the
primary and secondary nameservers identified by the (registrant|registrar).

There is no _new_ protocol requirement in this statement either.

As to a "Purpose" requirement, this appears to be outside of the scope of
SB1335-01-Q-0740, and therefore, an _operator_ specific feature.

As it happens, there are at least two efforts to provide label semantics
for UR*s, the W3C PICS effort, and the W3C P3P effort. As it happens, I've
worked on both. It is possible that a scoped vocabulary (like PICS attempted
in a historic US policy context, or P3P has established w.r.t. privacy in a
synthetic three-theories (EU/OEDC/US) context) could be a generally useful
extension to a registry provisioning protocol, and of interest to implementors
of interoperable systems. I missed something however in this draft.

I would have said the same thing six weeks ago.

As a personal comment, the idea of using the IETF to publish a national code
concerning the classes of persons authorized to use the Internet is not one
that comes naturally to me. Section 3.2

More minutia

Section 7. Internationalization considerations are about characters and text.
Just being "in" one nation state doesn't automatically remove the problem of
i18n considerations. 

Use:
	These parameters do not introduce any additional international
	considerations other than those specified for EPP contact object
	mapping [5].    
 
Section 8. Registry (implementor) private parameters can't require IANA
action. Use: "None."

Section 9. See 7 above. s/i18n/sec/

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Call for agenda items for Minneapolis 
Date: Tue, 19 Feb 2002 12:42:57 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Eric Brunner-Williams in Portland Maine
> [mailto:[email-masked]]
> Sent: Tuesday, February 19, 2002 3:18 PM
> To: Edward Lewis
> Cc: [email-masked]; [email-masked]
> Subject: Re: Call for agenda items for Minneapolis 
> 
> 
> From the abstract:
> 
> > These two new parameters only apply to ... <a single domain 
> name registry>
> 
> and from the statement of intent:
> 
> > ... specify ...  extensions ... required ... interconnect  
> ... registry
> 
> The authors have created a registry-private extension, as other registries
> have for trademark data, and no doubt will continue to experiment with as
> the registry experience matures. Such things are properly in operational
> registry practices documents, or informational I-Ds, not requiring working
> group change control and process.

I have to agree with Eric.  I'd prefer that we spend meeting time on topics
of concern to the WG as a whole.

FWIW I _do_ have some pro bono commentary for the authors if they wish to
discuss the mechanics of the extensions in an offline exchange.  Hint: how
does a client learn of the existence of this extension, and how does the
client inform the server of intent to use the extension?

-Scott-

To: Edward Lewis <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Call for agenda items for Minneapolis 
Date: Tue, 19 Feb 2002 12:17:45 -0800
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

>From the abstract:

> These two new parameters only apply to ... <a single domain name registry>

and from the statement of intent:

> ... specify ...  extensions ... required ... interconnect  ... registry

The authors have created a registry-private extension, as other registries
have for trademark data, and no doubt will continue to experiment with as
the registry experience matures. Such things are properly in operational
registry practices documents, or informational I-Ds, not requiring working
group change control and process.

I would have said the same thing six weeks ago.

Eric

Date: Tue, 19 Feb 2002 09:51:38 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Call for agenda items for Minneapolis
Cc: [email-masked]
Sender: [email-masked]

It's still a month away, but it seems like we do have a two-hour slot
reserved for Wednesday (Mar 20).  (Apply the caveat that the time/date is
tentative when considering travel plans.)  In the mean time, your co-chairs
will be spanning the globe, so we need to leave enough lead time to
generate the agenda.

So - topics?

PS - I've heard a few, including a request to discuss this individual
submission:

>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
>	Title		: New EPP Parameters for the usTLD
>	Author(s)	: H. Liu et al.
>	Filename	: draft-liu-epp-ustld-00.txt
>	Pages		: 11
>	Date		: 18-Feb-02
>
>This document defines two new EPP parameters to enable the exchange
>of additional information between the registry and the registrars for
>the United States ccTLD (usTLD). These two new parameters only apply
>to contact objects served as registrants for usTLD domains. This is
>accomplished according to the EPP extension framework in the command-
>response <extension> field.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-liu-epp-ustld-00.txt

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Do you have the time to listen to me whine
About nothing and everything all at once?
-- Green Day ("Basket Case")

Opinions expressed are property of my evil twin, not my employer.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Roger Castillo Cortazar'" <[email-masked]>, [email-masked]
Subject: RE: Object associations.
Date: Tue, 19 Feb 2002 09:45:22 -0500
Sender: [email-masked]

Roger,

The general topic of a query mechanism to do reverse-association lookups has
indeed been covered in the past.  I'd provide a pointer to archived messages
but I didn't see anything obvious with a quick glance.

I've argued that broad query mechanisms are out of place in a provisioning
protocol.  The kind of query that you've described below, when used (for
example) to return all of the delegations to a name server or all of the
domains associated with a contact, can literally return millions of records.
There are other ways to provide this info, such as via offline reporting
services, without adding search and lookup facilities to a provisioning
protocol.

More below...

-Scott- 

> -----Original Message-----
> From: Roger Castillo Cortazar [mailto:[email-masked]]
> Sent: Monday, February 18, 2002 7:39 PM
> To: [email-masked]
> Subject: Object associations.
> 
> 
> I don't know if this has been issued before, but I checked in 
> the cafax history
> and I couldn't find anything about it.
> 
> In the reqs. document
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-re
> qs-05.txt
> we can read as folows:
> 
> 3.4.9 Object Information Query
> 
>    [4] The protocol MUST provide services to identify all associated
>    object references, such as name servers associated with domains
>    (including delegations and hierarchical relationships) and contacts
>    associated with domains.  This information MUST be visible if the
>    object associations have an impact on the success or failure of
>    protocol operations.
> 
> Now, as we can read in the host mappings.
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-04.txt
> we can find this:
> 
> 2.3 Status Values
> 
> linked
> 
>    The host object has at least one active association with another
>    object, such as a domain object.  Servers SHOULD provide 
> services to
>    determine existing object associations.
> 
> 3.2.2 EPP <delete> Command
> 
>    A host name object MUST NOT be deleted if the host object is
>    associated with any other object.  For example, if the 
> host object is
>    associated with a domain object, the host object MUST NOT 
> be deleted
>    until the existing association has been broken.
> 
> 
> ..............................
> 
> The service for identifying all associated object references 
> is a MUST in 
> the protocol reqs.
> 
> There isn't  any problem with the domain object as pointed in 
> 3.4.9 [4].
> The information about object associations for a domain object 
> MUST be given 
> to authorized clients,
> and that's how it's described in the domain object mappings.
> 
> This service is NOT described in the host mappings.
> How can a client query the registry to look for all the 
> object associations 
> for one of his sponsored host objects ?
> Looks like the protocol spec is not fulfilling the 
> requirements for this 
> service.

As you noted, one can determine the contact and host objects associated with
a domain object by doing an <info> command on the domain.  One can also find
out that a contact or host object is linked to a domain object (but they
can't get a list of specific domain object(s)) by doing an <info> command on
the contact or host object.  I wrote the requirement and interpret it to
mean that the protocol MUST provide information describing attribute
associations, as in "this is an object and these are the attributes of that
object".  The "linked" status flag in the host and contact mappings lets the
client know that an association exists (which in my interpretation meets the
requirement as it identifies a reference) without introducing the
possibility of having to return a potentially very large result set.  As
described above, this sort of reverse-lookup service is best provided by
som3ething other than a provisioning protocol.

> Now, let's assume we offer the service to the clients.
> The number of associations for a host object could be a few 
> hundreds, and 
> in some cases a few hundreds of thousands.

In at least one name space I'm familiar with the number would be much higher
in some common cases.  Some registrars offer hosting services where their
servers and contacts are used for EVERY domain they register.

> Has anyone given a little tough about this ? Maybe those who 
> are working on 
> implementations.
> How can we interpret and apply this considerations of de reqs. to the 
> object mappings for hosts ?
> 
> Perhaps we can add an <host:assoc> child element to the 
> server response to 
> the <info> command
> to show the number of active associations for the host object.
> 
> 
> The same considerations can be made for the contact objetc and its 
> associations with domain objetcts.
> 
> In the contact object mappings, we can read in 3.2.2 EPP 
> <delete> Command, 
> that a server SHOULD notify
> clients of object relationships when a <delete> command is 
> attempted and 
> fails due to existing object relationships.
> 
> How can a client verify that the contact object he wants to delete no 
> longer has any active relationship ?

Yep, it's been thought about, it's in the archives somewhere.

One possibility: when a <delete> command fails due to an existing
association, the client should receive an error message explaining that the
delete fails because of an existing association.  A service message should
also be created and enqueued as described in the specs.  It's quite possible
for the server to create a service message that lists the active
associations rather than including them in every <info> response.  In many
cases the number of associations might be small enough to "fit" in the
message, and where size becomes an issue the service message could point the
client to an offline reporting service where the associations can be
determined.

-Scott-

Date: Mon, 18 Feb 2002 18:38:38 -0600
To: [email-masked]
From: Roger Castillo Cortazar <[email-masked]>
Subject: Object associations.
Sender: [email-masked]

I don't know if this has been issued before, but I checked in the cafax history
and I couldn't find anything about it.

In the reqs. document
http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-05.txt
we can read as folows:

3.4.9 Object Information Query

   [4] The protocol MUST provide services to identify all associated
   object references, such as name servers associated with domains
   (including delegations and hierarchical relationships) and contacts
   associated with domains.  This information MUST be visible if the
   object associations have an impact on the success or failure of
   protocol operations.

Now, as we can read in the host mappings.
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-04.txt
we can find this:

2.3 Status Values

linked

   The host object has at least one active association with another
   object, such as a domain object.  Servers SHOULD provide services to
   determine existing object associations.

3.2.2 EPP <delete> Command

   A host name object MUST NOT be deleted if the host object is
   associated with any other object.  For example, if the host object is
   associated with a domain object, the host object MUST NOT be deleted
   until the existing association has been broken.

..............................

The service for identifying all associated object references is a MUST in 
the protocol reqs.

There isn't  any problem with the domain object as pointed in 3.4.9 [4].
The information about object associations for a domain object MUST be given 
to authorized clients,
and that's how it's described in the domain object mappings.

This service is NOT described in the host mappings.
How can a client query the registry to look for all the object associations 
for one of his sponsored host objects ?
Looks like the protocol spec is not fulfilling the requirements for this 
service.

Now, let's assume we offer the service to the clients.
The number of associations for a host object could be a few hundreds, and 
in some cases a few hundreds of thousands.

Has anyone given a little tough about this ? Maybe those who are working on 
implementations.
How can we interpret and apply this considerations of de reqs. to the 
object mappings for hosts ?

Perhaps we can add an <host:assoc> child element to the server response to 
the <info> command
to show the number of active associations for the host object.

The same considerations can be made for the contact objetc and its 
associations with domain objetcts.

In the contact object mappings, we can read in 3.2.2 EPP <delete> Command, 
that a server SHOULD notify
clients of object relationships when a <delete> command is attempted and 
fails due to existing object relationships.

How can a client verify that the contact object he wants to delete no 
longer has any active relationship ?

..................................................

Greetings.

Roger Castillo Cortazar
NIC-Mexico http://www.nic.mx