Re: Implementation of EPP (other nits)

[Michael Graff <[e-mail]>]

Daniel Manley <[e-mail]> writes:

> does the schema permit setting these fields to "" (empty string)?

Nope.

From the base document:

  <!--
  Abstract client and object identifier type.
  -->
    <simpleType name="clIDType">
      <restriction base="token">
        <minLength value="3"/>
        <maxLength value="16"/>
      </restriction>
    </simpleType>

As used for updating the registrant field in a domain:

  <!--
  Data elements that can be changed.
  -->
    <complexType name="chgType">
      <sequence>
        <element name="registrant" type="eppcom:clIDType"
         minOccurs="0"/>
        <element name="authInfo" type="domain:authInfoType"
         minOccurs="0"/>
      </sequence>
    </complexType>

That won't allow an empty string, if I understand XML right.

--Michael



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gATLQL9p024636 for <[e-mail]>; Fri, 29 Nov 2002 22:26:21 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gATLQLlP024635 for ietf-provreg-outgoing; Fri, 29 Nov 2002 22:26:21 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from rc.isc.org (rc.isc.org [204.152.187.2]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gATLQK9p024630 for <[e-mail]>; Fri, 29 Nov 2002 22:26:21 +0100 (MET)
Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by rc.isc.org (Postfix) with ESMTP id 796DF1D73; Fri, 29 Nov 2002 21:26:19 +0000 (UTC) (envelope-from [e-mail])
Received: by farside.isc.org (Postfix, from userid 10015) id 35178AA72; Fri, 29 Nov 2002 21:26:19 +0000 (UTC)
To: Daniel Manley <[e-mail]>
Cc: Michael Graff <[e-mail]>, [e-mail]
Subject: Re: Implementation of EPP (other nits)
References: <[e-mail]> <[e-mail]>
From: Michael Graff <[e-mail]>
Date: 29 Nov 2002 21:26:19 +0000
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 35
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Daniel Manley <[e-mail]> writes:

> does the schema permit setting these fields to "" (empty string)?

Nope.

>From the base document:

  <!--
  Abstract client and object identifier type.
  -->
    <simpleType name="clIDType">
      <restriction base="token">
        <minLength value="3"/>
        <maxLength value="16"/>
      </restriction>
    </simpleType>

As used for updating the registrant field in a domain:

  <!--
  Data elements that can be changed.
  -->
    <complexType name="chgType">
      <sequence>
        <element name="registrant" type="eppcom:clIDType"
         minOccurs="0"/>
        <element name="authInfo" type="domain:authInfoType"
         minOccurs="0"/>
      </sequence>
    </complexType>

That won't allow an empty string, if I understand XML right.

--Michael


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gATLFD9p024555 for <[e-mail]>; Fri, 29 Nov 2002 22:15:13 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gATLFDul024554 for ietf-provreg-outgoing; Fri, 29 Nov 2002 22:15:13 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from fep04-mail.bloor.is.net.cable.rogers.com (fep04-mail.bloor.is.net.cable.rogers.com [66.185.86.74]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gATLFB9p024549 for <[e-mail]>; Fri, 29 Nov 2002 22:15:12 +0100 (MET)
Received: from isc.org ([24.103.90.17]) by fep04-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <[e-mail]>; Fri, 29 Nov 2002 16:15:06 -0500
Date: Fri, 29 Nov 2002 16:15:15 -0500
Subject: Re: Implementation of EPP (other nits)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Mime-Version: 1.0 (Apple Message framework v548)
Cc: Michael Graff <[e-mail]>, [e-mail]
To: Daniel Manley <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
X-Mailer: Apple Mail (2.548)
X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep04-mail.bloor.is.net.cable.rogers.com from [24.103.90.17] using ID <[e-mail]> at Fri, 29 Nov 2002 16:15:05 -0500
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id gATLFC9p024550
Sender: [e-mail]
Precedence: bulk

On Friday, Nov 29, 2002, at 15:33 Canada/Eastern, Daniel Manley wrote:

> does the schema permit setting these fields to "" (empty string)?

It seems like it would be possible to define a contact handle which 
means "no contact", and specify that within a <domain:registrant> 
element to indicate the absense of a registrant for a domain. That's 
very, very ugly indeed, however.

The <domain:authInfo> element would an even bigger hack, since the DTD 
specifies sub-elements.

Using magic values to indicate deletion seems like a gratuitously bad 
idea :)


Joe

> Michael Graff a écrit:
>
>> I don't know how many of you are actually attempting to implement the
>> current drafts, but I am...
>>
>> The "registrant" and "authinfo" attributes are optional when creating
>> domains, but once there, cannot be removed with <update>, only 
>> changed.
>>
>> --Michael




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gATKYb9p024270 for <[e-mail]>; Fri, 29 Nov 2002 21:34:37 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gATKYa6M024269 for ietf-provreg-outgoing; Fri, 29 Nov 2002 21:34:36 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from toronto.mail.tucows.com (bfos.tucows.com [207.136.98.11]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gATKYZ9p024264 for <[e-mail]>; Fri, 29 Nov 2002 21:34:36 +0100 (MET)
Received: from dmanley.pc.internal.tucows.com ([10.0.10.19] helo=tucows.com) by toronto.mail.tucows.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.36 #3) id 18HrqM-00067y-00; Fri, 29 Nov 2002 15:34:34 -0500
Message-ID: <[e-mail]>
Date: Fri, 29 Nov 2002 15:33:06 -0500
From: Daniel Manley <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.0.1) Gecko/20020918
X-Accept-Language: en-us
MIME-Version: 1.0
To: Michael Graff <[e-mail]>
CC: [e-mail]
Subject: Re: Implementation of EPP (other nits)
References: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

does the schema permit setting these fields to "" (empty string)?

Dan

Michael Graff a écrit:

>I don't know how many of you are actually attempting to implement the
>current drafts, but I am...
>
>The "registrant" and "authinfo" attributes are optional when creating
>domains, but once there, cannot be removed with <update>, only changed.
>
>--Michael
>  
>


-- 
Daniel Manley
Tucows, Inc.
Toronto, Canada
[e-mail]





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gATDg89p021608 for <[e-mail]>; Fri, 29 Nov 2002 14:42:08 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gATDg8qg021607 for ietf-provreg-outgoing; Fri, 29 Nov 2002 14:42:08 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nohope.patoche.org (nohope.patoche.org [80.67.173.199]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gATDg79p021602 for <[e-mail]>; Fri, 29 Nov 2002 14:42:07 +0100 (MET)
Received: from nohope.patoche.org (localhost.gandi.net [127.0.0.1]) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) with ESMTP id gATDg29P007942 for <[e-mail]>; Fri, 29 Nov 2002 14:42:02 +0100
Received: (from patrick@localhost) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) id gATDg2nb007940 for [e-mail]; Fri, 29 Nov 2002 14:42:02 +0100
Date: Fri, 29 Nov 2002 14:42:02 +0100
From: Patrick <[e-mail]>
To: [e-mail]
Subject: Re: EPP statuses and other questions
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.24i
X-PGP-KeyID: A241FB6B
X-PGP-Fingerprint: 9DA9 5054 7A5D 03FC A9AD  9AFF 1371 9F06 A241 FB6B
X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B
Organization: Gandi
Sender: [e-mail]
Precedence: bulk

On Tue, Nov 26, 2002 at 10:32:44PM +0000, Michael Graff took time to write:
> Michael Graff <[e-mail]> writes:
> 
> > I've read almost every post on that page, and a few from other pages.
> 
> And after reading much more, I feel the mistake is that there are two
> handles for objects now, and that is becomming a pain in trying to
> implement EPP.

As someone implementing EPP, I totally agree with Michael.

> (3)  The various <create> commands need to return the ROID an object was
>      assigned.  As things are now, I need to look up the contact using
>      <info> before I can use it in an <authinfo roid="whatever"> tag.

This is a serious problem. IIRC it was given in the create response
in earlier drafts, then removed.

Current status of ROIDs in the three new gTLD registries is a mess,
especially regarding what is available in whois.

If the purpose is to confuse registrants, currently it is achieved.
Most people have problems with handles, and currently they must have,
for them a different handle for *each* Registry.

> (6)  EPP is extensible.  Once other issues, such as how to notify
>      referrers of data, or even a good use for this sort of thing is
>      found, a draft can be written to extend EPP to handle
>      registry-side ROIDs.  Until then, I at least feel they complicate
>      an already complicated protocol, and should be removed for now.

Agreed.

Patrick.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAS1fe9p007328 for <[e-mail]>; Thu, 28 Nov 2002 02:41:40 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAS1fev2007327 for ietf-provreg-outgoing; Thu, 28 Nov 2002 02:41:40 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from isrv4.isc.org (isrv4.isc.org [204.152.184.27]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAS1fd9p007322 for <[e-mail]>; Thu, 28 Nov 2002 02:41:39 +0100 (MET)
Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by isrv4.isc.org (Postfix) with ESMTP id DBA118CE for <[e-mail]>; Thu, 28 Nov 2002 01:41:37 +0000 (UTC) (envelope-from [e-mail])
Received: by farside.isc.org (Postfix, from userid 10015) id 8B81BAA72; Thu, 28 Nov 2002 01:41:37 +0000 (UTC)
To: [e-mail]
Subject: Implementation of EPP (other nits)
From: Michael Graff <[e-mail]>
Date: 28 Nov 2002 01:41:37 +0000
Message-ID: <[e-mail]>
Lines: 7
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

I don't know how many of you are actually attempting to implement the
current drafts, but I am...

The "registrant" and "authinfo" attributes are optional when creating
domains, but once there, cannot be removed with <update>, only changed.

--Michael


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gARIAc9p003327 for <[e-mail]>; Wed, 27 Nov 2002 19:10:38 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gARIAcZh003326 for ietf-provreg-outgoing; Wed, 27 Nov 2002 19:10:38 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gARIAb9p003321 for <[e-mail]>; Wed, 27 Nov 2002 19:10:37 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA29582; Wed, 27 Nov 2002 13:10:35 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <V87KDF1X>; Wed, 27 Nov 2002 13:05:42 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Michael Graff'" <[e-mail]>
Cc: [e-mail]
Subject: RE: EPP statuses and other questions
Date: Wed, 27 Nov 2002 13:09:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> > On Tue, Nov 26, 2002 at 10:32:44PM +0000,
> >  Michael Graff <[e-mail]> wrote 
> >  a message of 55 lines which said:
> > 
> > > (1)  A handle (like FOO1-ISC) is not self-describing.  Is 
> that a contact
> > >      handle, a domain handle, or what?
> > 
> > I see it a a "registry policy" issue. Some will have a global
> > namespace for handles (with the risks you explain) and some 
> will have
> > separate namespaces for contacts and hosts.
> 
> According to the current draft, this isn't possible.  For 
> hosts and for
> domains, sure.  However, for clients, the registrant (not 
> even the registrar
> according to how people say they'll be used!) chooses the local name,
> and therefore the GLOBAL name as well, since the global ROID 
> is defined
> as the local_part-REGISTRY

Where in the current drafts do you see requirements for how the local part
of the ROID is defined as you've described?  There's _nothing_ in the
contact draft that says that the local part MUST be the contact ID, and the
core draft says this (section 2.8):

"Specific identifier values are a matter of repository policy, but they
SHOULD be constructed according to the following algorithm:

a) Divide the provisioning repository world into a number of object
repository classes.

b) Each repository within a class is assigned an identifier that is
maintained by IANA.

(c) Each repository is responsible for assigning a unique local
identifier for each object within the repository.

(d) The globally unique identifier is a concatenation of the local
identifier, followed by a hyphen ("-", ASCII value 0x002D), followed
by the repository identifier."

There's nothing here that I see that requires the restriction you've alluded
to.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gARHFZ9p002779 for <[e-mail]>; Wed, 27 Nov 2002 18:15:35 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gARHFZL1002778 for ietf-provreg-outgoing; Wed, 27 Nov 2002 18:15:35 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from isrv4.isc.org (isrv4.isc.org [204.152.184.27]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gARHFY9p002773 for <[e-mail]>; Wed, 27 Nov 2002 18:15:34 +0100 (MET)
Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by isrv4.isc.org (Postfix) with ESMTP id 668B41EB3; Wed, 27 Nov 2002 17:15:30 +0000 (UTC) (envelope-from [e-mail])
Received: by farside.isc.org (Postfix, from userid 10015) id 50226AA73; Wed, 27 Nov 2002 17:15:30 +0000 (UTC)
To: Stephane Bortzmeyer <[e-mail]>
Cc: Michael Graff <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>, [e-mail]
Subject: Re: EPP statuses and other questions
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Michael Graff <[e-mail]>
Date: 27 Nov 2002 17:15:30 +0000
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 45
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Stephane Bortzmeyer <[e-mail]> writes:

> On Tue, Nov 26, 2002 at 10:32:44PM +0000,
>  Michael Graff <[e-mail]> wrote 
>  a message of 55 lines which said:
> 
> > (1)  A handle (like FOO1-ISC) is not self-describing.  Is that a contact
> >      handle, a domain handle, or what?
> 
> I see it a a "registry policy" issue. Some will have a global
> namespace for handles (with the risks you explain) and some will have
> separate namespaces for contacts and hosts.

According to the current draft, this isn't possible.  For hosts and for
domains, sure.  However, for clients, the registrant (not even the registrar
according to how people say they'll be used!) chooses the local name,
and therefore the GLOBAL name as well, since the global ROID is defined
as the local_part-REGISTRY

> > (2)  Part of the handle namespace is client-chosen, part is registry-chosen.
> >      On contacts, the local (and thus the global) identifiers are chosen
> >      by the registrant, 
> 
> Which is bad, IMHO. It may require several round-trips before the
> registrar (<pc>the client</pc>) finds a free handle. Why is there no
> provision for registry-generated contact handles? (Or should we assume
> the ROID will have this role?)

See above, the ROID is derrived directly from the local part.

So, we have:

        entity local name       ROID            ROID Chosen by
        ---------------------   ------------    --------------
        foo.com                 FOO-ISC         Registry
        ns1.foo.com             NS1_FOO-ISC     Registry
        mg2                     MG2-ISC         Registrant

I don't see why using what I see as a far more sane method of using URNs
here wouldn't work.  After all, that's more or less the expected thing in
an XML encoding, and it solves the problem without any need for ROIDs.
Baring that, I think the ROID issue is serious enough, and badly spec'd
enough, that it needs to be fixed before the draft makes it to RFC status.

--Michael


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gARH9x9p002707 for <[e-mail]>; Wed, 27 Nov 2002 18:09:59 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gARH9xGW002706 for ietf-provreg-outgoing; Wed, 27 Nov 2002 18:09:59 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from rc.isc.org (rc.isc.org [204.152.187.2]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gARH9w9p002701 for <[e-mail]>; Wed, 27 Nov 2002 18:09:58 +0100 (MET)
Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by rc.isc.org (Postfix) with ESMTP id 7A33CC61F; Wed, 27 Nov 2002 17:09:57 +0000 (UTC) (envelope-from [e-mail])
Received: by farside.isc.org (Postfix, from userid 10015) id 11984AA74; Wed, 27 Nov 2002 17:09:57 +0000 (UTC)
To: "Hollenbeck, Scott" <[e-mail]>
Cc: "'Michael Graff'" <[e-mail]>, [e-mail]
Subject: Re: "ok" status on domains (and other objects)
References: <[e-mail]>
From: Michael Graff <[e-mail]>
Date: 27 Nov 2002 17:09:56 +0000
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 23
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

"Hollenbeck, Scott" <[e-mail]> writes:

> We need to understand something: the protocol documents have almost
> completed IESG review.  I don't have a lot of liberty in making changes to
> documents that have completed both WG and IETF-wide last calls (other than
> dealing with editorial issues) unless _serious_ issues are discovered.  In
> my mind, _serious_ means that a large number of WG participants agree that
> something needs to be changed _now_ and the chairs declare that we have
> consensus on the need for such a change.

I'd argue that the ROID stuff is a serious issue, BTW.  :)  Making the ok
and inactive states "automatic" doesn't seem like a huge issue, nor does
it seem to be different than what the draft expects.

> The answer to your first question is "yes".  I will _try_ to deal with
> wordsmithing the text to more fully explain that the default "ok" status is
> set and unset as a result of other explicit status-setting operations.  I'm
> not open to the idea of changing status behavior unless we enter into the
> _serious_ issue state as described above.

I sort of assumed the wordsmithing route would happen.

--Michael


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAR9nE9p028662 for <[e-mail]>; Wed, 27 Nov 2002 10:49:14 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gAR9nEJO028661 for ietf-provreg-outgoing; Wed, 27 Nov 2002 10:49:14 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAR9nA9p028656 for <[e-mail]>; Wed, 27 Nov 2002 10:49:12 +0100 (MET)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id gAR9n6hA753070; Wed, 27 Nov 2002 10:49:06 +0100 (CET)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id E177110D3B; Wed, 27 Nov 2002 10:49:05 +0100 (CET)
Date: Wed, 27 Nov 2002 10:49:05 +0100
From: Stephane Bortzmeyer <[e-mail]>
To: Michael Graff <[e-mail]>
Cc: "Hollenbeck, Scott" <[e-mail]>, [e-mail]
Subject: Re: EPP statuses and other questions
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.28i
X-Operating-System: Debian GNU/Linux 3.0
X-Kernel: Linux 2.4.18-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
Sender: [e-mail]
Precedence: bulk

On Tue, Nov 26, 2002 at 10:32:44PM +0000,
 Michael Graff <[e-mail]> wrote 
 a message of 55 lines which said:

> (1)  A handle (like FOO1-ISC) is not self-describing.  Is that a contact
>      handle, a domain handle, or what?

I see it a a "registry policy" issue. Some will have a global
namespace for handles (with the risks you explain) and some will have
separate namespaces for contacts and hosts.

> (2)  Part of the handle namespace is client-chosen, part is registry-chosen.
>      On contacts, the local (and thus the global) identifiers are chosen
>      by the registrant, 

Which is bad, IMHO. It may require several round-trips before the
registrar (<pc>the client</pc>) finds a free handle. Why is there no
provision for registry-generated contact handles? (Or should we assume
the ROID will have this role?)



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAR4UR9p026741 for <[e-mail]>; Wed, 27 Nov 2002 05:30:27 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAR4URsp026740 for ietf-provreg-outgoing; Wed, 27 Nov 2002 05:30:27 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from felix.automagic.org (felix.automagic.org [204.152.186.101]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gAR4UP9p026735 for <[e-mail]>; Wed, 27 Nov 2002 05:30:26 +0100 (MET)
Received: (qmail 4067 invoked by uid 0); 27 Nov 2002 04:30:19 -0000
Received: from localhost.automagic.org (HELO isc.org) (127.0.0.1) by localhost.automagic.org with SMTP; 27 Nov 2002 04:30:19 -0000
Date: Tue, 26 Nov 2002 23:30:18 -0500
Subject: Re: format of contents of <domain:curExpDate>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v548)
Cc: [e-mail]
To: "Hollenbeck, Scott" <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.548)
Sender: [e-mail]
Precedence: bulk

On Thursday, Nov 14, 2002, at 11:13 Canada/Eastern, Joe Abley wrote:

> On Thursday, Nov 14, 2002, at 08:56 Canada/Eastern, Hollenbeck, Scott 
> wrote:
>
>> You seem to be thinking that the value for this particular field is 
>> one that
>> needs to be either given to or retrieved from the registrant as part 
>> of a
>> renewal operation -- it doesn't.
>
> [blah blah]
>
> If the procedure you suggested (rip the date part out of a 
> <domain:curExpDate>, in whatever timezone was specified in that data) 
> is what you intended, then the draft needs to specify:
>
>  (a) that procedure, and
>
>  (b) that the time zone used in all situations where a server can 
> return a <domain:exDate> must be consistent when sending responses to 
> a single registrar.

I had completely missed the paragraph near the beginning of the 
domain-mapping, host-mapping and contact-mapping drafts which specifies 
that all dates and times exchanged between server and client MUST be in 
UTC. My bad. That would seem to take care of (b) above.

I still think it would be more consistent to use a dateTime type in 
<domain:curExpDate>, but I can no longer think of an operational reason 
to demand it. I hereby withdraw my previous long-winded and tedious 
request :)


Joe



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAR2GH9p025219 for <[e-mail]>; Wed, 27 Nov 2002 03:16:17 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gAR2GGcf025208 for ietf-provreg-outgoing; Wed, 27 Nov 2002 03:16:16 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAR2GA9p025201 for <[e-mail]>; Wed, 27 Nov 2002 03:16:10 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id VAA02116; Tue, 26 Nov 2002 21:16:09 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <V5CJCGKA>; Tue, 26 Nov 2002 21:15:47 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Michael Graff'" <[e-mail]>, [e-mail]
Subject: RE: "ok" status on domains (and other objects)
Date: Tue, 26 Nov 2002 21:15:32 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> Quick question:
> 
> The "ok" status is server-managed, and is said that it cannot 
> occur with
> other statuses.  Does this mean it is implicitly removed when a client
> attempts to set any status, like clientHold, and will return 
> implicitly
> when no other status values are set?  If so, can the protocol draft
> explicitly state this?
> 
> Having it be implicit seems like an implementation choice.  I would
> rather see it removed explicitly, or go away all together, 
> which means an
> object without any status is automatically "ok".

We need to understand something: the protocol documents have almost
completed IESG review.  I don't have a lot of liberty in making changes to
documents that have completed both WG and IETF-wide last calls (other than
dealing with editorial issues) unless _serious_ issues are discovered.  In
my mind, _serious_ means that a large number of WG participants agree that
something needs to be changed _now_ and the chairs declare that we have
consensus on the need for such a change.

The answer to your first question is "yes".  I will _try_ to deal with
wordsmithing the text to more fully explain that the default "ok" status is
set and unset as a result of other explicit status-setting operations.  I'm
not open to the idea of changing status behavior unless we enter into the
_serious_ issue state as described above.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAR1ar9p024975 for <[e-mail]>; Wed, 27 Nov 2002 02:36:53 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAR1arTZ024974 for ietf-provreg-outgoing; Wed, 27 Nov 2002 02:36:53 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from isrv4.isc.org (isrv4.isc.org [204.152.184.27]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAR1ap9p024969 for <[e-mail]>; Wed, 27 Nov 2002 02:36:52 +0100 (MET)
Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by isrv4.isc.org (Postfix) with ESMTP id 56B9A6F2 for <[e-mail]>; Wed, 27 Nov 2002 01:36:50 +0000 (UTC) (envelope-from [e-mail])
Received: by farside.isc.org (Postfix, from userid 10015) id D731EAA75; Wed, 27 Nov 2002 01:36:49 +0000 (UTC)
To: [e-mail]
Subject: "ok" status on domains (and other objects)
From: Michael Graff <[e-mail]>
Date: 27 Nov 2002 01:36:49 +0000
Message-ID: <[e-mail]>
Lines: 13
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Quick question:

The "ok" status is server-managed, and is said that it cannot occur with
other statuses.  Does this mean it is implicitly removed when a client
attempts to set any status, like clientHold, and will return implicitly
when no other status values are set?  If so, can the protocol draft
explicitly state this?

Having it be implicit seems like an implementation choice.  I would
rather see it removed explicitly, or go away all together, which means an
object without any status is automatically "ok".

--Michael


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAR0LF9p024563 for <[e-mail]>; Wed, 27 Nov 2002 01:21:15 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAR0LF88024562 for ietf-provreg-outgoing; Wed, 27 Nov 2002 01:21:15 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from web14310.mail.yahoo.com (web14310.mail.yahoo.com [216.136.224.60]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gAR0LD9p024557 for <[e-mail]>; Wed, 27 Nov 2002 01:21:14 +0100 (MET)
Message-ID: <[e-mail]>
Received: from [211.150.223.195] by web14310.mail.yahoo.com via HTTP; Tue, 26 Nov 2002 16:21:12 PST
Date: Tue, 26 Nov 2002 16:21:12 -0800 (PST)
From: Hong Liu <[e-mail]>
Subject: Re: Handling of External Host Objects
To: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Dan, Scott, and Janusz,

As the person who re-opened this topic on the list, I
would also like to see a concrete proposal to get a
closure on this topic. It looks like the WG is leaning
towards reverting back to the single-copy model, but
is still unclear of how it should be done.

Whether external hosts are treated as an independent
object or an attribute to a domain object, the end
result seems to be the same: they are single-copy,
read-only entities by registrars once they are created
in the registry. This is the only sensible way to
avoid sponsorship monoply by any registrar who first
created an external host.

There are pros and cons for either approach. The
attribute approach is conceptually cleaner, but incurs
changes to many EPP commands such as create, update,
info, etc. The object approach is not as clean, but it
minimizes syntatical changes to EPP commands and keep
the host handling APIs similar. In the end, it really
boils down to the matter of taste. From implementation
point of view, the registry will create a DB object,
be it an attribute or object at the EPP level. 

--Hong

--- Daniel Manley <[e-mail]> wrote:
> Another good compromise for external hosts.  Looks
> like it avoids 
> ("settles"?) some of the ambiguous ownership issues
> for external hosts. 
>  It also keeps the domain transfer cans of worms
> locked and sealed.
> 
> Does anyone have meetings minutes for the discussion
> on external hosts 
> in Atlanta?
> 
> Dan
> 
> 
> Hollenbeck, Scott a écrit:
> 
> >>To alleviate the problems mentioned above let me
> propose the following
> >>changes
> >>to epp host and domain mapping documents:
> >>    
> >>
> >
> >If I understand this correctly you're suggesting a
> move back to the way
> >things were (more or less, with some limits to
> address the issues) before
> >the per-client thing came up, right?  I like the
> idea of consistency and
> >simplicity -- what do others think?
> >
> >-Scott-
> >  
> >
> 
> 
> -- 
> Daniel Manley
> Tucows, Inc.
> Toronto, Canada
> [e-mail]
> 
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAQMWl9p023830 for <[e-mail]>; Tue, 26 Nov 2002 23:32:47 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAQMWl22023829 for ietf-provreg-outgoing; Tue, 26 Nov 2002 23:32:47 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from rc.isc.org (rc.isc.org [204.152.187.2]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAQMWj9p023824 for <[e-mail]>; Tue, 26 Nov 2002 23:32:46 +0100 (MET)
Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by rc.isc.org (Postfix) with ESMTP id 58A97C5CA; Tue, 26 Nov 2002 22:32:45 +0000 (UTC) (envelope-from [e-mail])
Received: by farside.isc.org (Postfix, from userid 10015) id F274BAA72; Tue, 26 Nov 2002 22:32:44 +0000 (UTC)
To: Michael Graff <[e-mail]>
Cc: "Hollenbeck, Scott" <[e-mail]>, [e-mail]
Subject: Re: EPP statuses and other questions
References: <[e-mail]> <[e-mail]>
From: Michael Graff <[e-mail]>
Date: 26 Nov 2002 22:32:44 +0000
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 55
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Michael Graff <[e-mail]> writes:

> I've read almost every post on that page, and a few from other pages.

And after reading much more, I feel the mistake is that there are two
handles for objects now, and that is becomming a pain in trying to
implement EPP.

(0)  ROIDs are not well thought out, nor well integrated into the 07
     draft at least.

(1)  A handle (like FOO1-ISC) is not self-describing.  Is that a contact
     handle, a domain handle, or what?

(2)  Part of the handle namespace is client-chosen, part is registry-chosen.
     On contacts, the local (and thus the global) identifiers are chosen
     by the registrant, where domain and other ROIDs are chosen by the
     registry.  This means the registry cannot fix (1) easily.

     Example:  Suppose a contact, "FLAME1" is created, and assigned
     ROID of FLAME1-ISC.  Now, later, that contact is deleted.
     Suppose a domain is created, "FLAME.ORG", and it is 
     assigned the ROID of "FLAME1-ISC".  Now, that is no longer a
     valid contact ROID.  All external references will be totally
     confused.  WORSE, since domains and contacts can have passwords,
     would:

        <authinfo roid="FLAME1-ISC">password</authinfo>

     allow me to modify other domains?  After all, FLAME1-ISC may be
     listed as an external technical contact for FOO.COM, and I can
     get the password right for the domain-versio of FLAME1-ISC.

(3)  The various <create> commands need to return the ROID an object was
     assigned.  As things are now, I need to look up the contact using
     <info> before I can use it in an <authinfo roid="whatever"> tag.

(4)  Using two names, one which is (in the contact case) derrived from the
     other, seems pretty silly.  If you're going to do that, use only the
     global (or use the URN concept to refer to external data,
     mentioned in the mail archives and in my last post.)

(5)  The -FOO suffix doesn't really fit with the new world order of
     URIs, URNs, and is different than how XML, the EPP protocol of
     choice (yuck) would do it.

(6)  EPP is extensible.  Once other issues, such as how to notify
     referrers of data, or even a good use for this sort of thing is
     found, a draft can be written to extend EPP to handle
     registry-side ROIDs.  Until then, I at least feel they complicate
     an already complicated protocol, and should be removed for now.
     Additionally, making it OPTIONAL gives the registry more
     flexability into if it WANTS external references or not.

--Michael


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAQL809p023132 for <[e-mail]>; Tue, 26 Nov 2002 22:08:00 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAQL80RN023131 for ietf-provreg-outgoing; Tue, 26 Nov 2002 22:08:00 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from rc.isc.org (rc.isc.org [204.152.187.2]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAQL7x9p023122 for <[e-mail]>; Tue, 26 Nov 2002 22:07:59 +0100 (MET)
Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by rc.isc.org (Postfix) with ESMTP id 99AA1C5B4; Tue, 26 Nov 2002 21:07:58 +0000 (UTC) (envelope-from [e-mail])
Received: by farside.isc.org (Postfix, from userid 10015) id 51441AA72; Tue, 26 Nov 2002 21:07:58 +0000 (UTC)
To: "Hollenbeck, Scott" <[e-mail]>
Cc: "'Michael Graff'" <[e-mail]>, [e-mail]
Subject: Re: EPP statuses and other questions
References: <[e-mail]>
From: Michael Graff <[e-mail]>
Date: 26 Nov 2002 21:07:58 +0000
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 43
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

"Hollenbeck, Scott" <[e-mail]> writes:

> The list archives are back up.  I'm no fan of ROIDs myself, but instead of
> rehashing the debate that led to their inclusion in the protocol I'd suggest
> that you go through the archives.  It starts about here:
> 
> http://www.cafax.se/ietf-provreg/maillist/2001-01/maillist.html
> 
> and goes on for quite a while.

I've read almost every post on that page, and a few from other pages.

My only concern is that by adding RIODs, there are now two ways to refer
to an entity.  Worse yet, there are amazing ways to end up with
inconsistent and confusing versions of the local and global IDs.

In the spec, for contacts, the globally unique id (ROID, if I understand
things right) is the client-supplied local name + the registry identifer.
This is intended to allow external references to that contact.  How is this
expected to actually work?  How are notifications passed to others using
this global ID?  I don't see anything about that in the spec.

I'd suggest global IDs be removed, and added back as an extension later,
if (1) a registry WANTED that extension, and (2) a good, well-thought-out
inter-registry/inter-database protocol is formed.

We don't need to have that in the first cut, this is an extensable protocol,
after all, and the base implementation is already complicated enough.

P.S.  I don't see why we need to complicate the protocol with ROIDs, anyway.
After all, when I want my web page to refer to someone else's site, I just
include an identifer (the host and the path, etc) -- why can't an
inter-registry handle be something more similar to a URN?

        srs.isc.org:mg2
        srs.example.com:foo.com

etc.  This does the same sort of thing that ROIDs do now, and keeps the
complications of ROIDs out of the picture.  The other points about inter-
database sharing of IDs still applies, though.

--Michael



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAQJrd9p022531 for <[e-mail]>; Tue, 26 Nov 2002 20:53:39 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAQJrdUf022530 for ietf-provreg-outgoing; Tue, 26 Nov 2002 20:53:39 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from toronto.mail.tucows.com (bfos.tucows.com [207.136.98.11]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAQJrc9p022525 for <[e-mail]>; Tue, 26 Nov 2002 20:53:38 +0100 (MET)
Received: from dmanley.pc.internal.tucows.com ([10.0.10.19] helo=tucows.com) by toronto.mail.tucows.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.36 #3) id 18Glm1-00017g-00; Tue, 26 Nov 2002 14:53:33 -0500
Message-ID: <[e-mail]>
Date: Tue, 26 Nov 2002 14:51:50 -0500
From: Daniel Manley <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.0.1) Gecko/20020918
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>
CC: "'janusz sienkiewicz'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Handling of External Host Objects
References: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Another good compromise for external hosts.  Looks like it avoids 
("settles"?) some of the ambiguous ownership issues for external hosts. 
 It also keeps the domain transfer cans of worms locked and sealed.

Does anyone have meetings minutes for the discussion on external hosts 
in Atlanta?

Dan


Hollenbeck, Scott a écrit:

>>To alleviate the problems mentioned above let me propose the following
>>changes
>>to epp host and domain mapping documents:
>>    
>>
>
>If I understand this correctly you're suggesting a move back to the way
>things were (more or less, with some limits to address the issues) before
>the per-client thing came up, right?  I like the idea of consistency and
>simplicity -- what do others think?
>
>-Scott-
>  
>


-- 
Daniel Manley
Tucows, Inc.
Toronto, Canada
[e-mail]





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAQJKB9p022190 for <[e-mail]>; Tue, 26 Nov 2002 20:20:11 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAQJKBsr022189 for ietf-provreg-outgoing; Tue, 26 Nov 2002 20:20:11 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAQJKA9p022184 for <[e-mail]>; Tue, 26 Nov 2002 20:20:10 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gAQJK7Ym017595; Tue, 26 Nov 2002 14:20:07 -0500 (EST)
Received: from [66.44.91.230] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA24097; Tue, 26 Nov 2002 14:20:04 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b13ba097848ba6c@[66.44.91.230]>
Date: Tue, 26 Nov 2002 14:20:13 -0500
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: a week later...
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

...and I'm already more that a week behind the mailing list.

What I want to address in the short term are the milestones for the 
group.  The way we've listed milestones in the past has been "not 
good enough."  I.e., our milestones should have something like 
"submit document A to the IESG for proposed standard."

The question I have is about the SOAP document.  In the face-to-face 
meeting there was interest from two people in implementing/supporting 
the effort.

The question: do other implementors want to discuss this document as 
part of the WG?

I'm not asking if it is worthy, or whether it is to be, for some 
version of the word, mandatory.  I just want to know if this is a 
topic that is worthwhile for the WG's effort.  (A good idea that is 
of interest to just one person does not need to involve a WG 
discussion.)

If the answer to the question is yes, then we'll have a milestone:
    <some date> Submit EPP mapping to SOAP to IESG for Proposed Standard

We can also declare it to be Experimental or just Informational too, 
the PS label is used for demonstration purposes only.

So, if you are interested in implementing a mapping to SOAP, please 
state your case.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAQC6h9p018033 for <[e-mail]>; Tue, 26 Nov 2002 13:06:43 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gAQC6hQG018032 for ietf-provreg-outgoing; Tue, 26 Nov 2002 13:06:43 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAQC6f9p018027 for <[e-mail]>; Tue, 26 Nov 2002 13:06:41 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA21839; Tue, 26 Nov 2002 07:06:39 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <V5CJBQSK>; Tue, 26 Nov 2002 07:06:18 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Michael Graff'" <[e-mail]>
Cc: [e-mail]
Subject: RE: EPP statuses and other questions
Date: Tue, 26 Nov 2002 07:06:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> So, once again, I'm back to thinking that we have a unique string (the
> old style "handle" mentality) in EPP.  Am I still not seeing
> something?
> 
> If the riods aren't used externally, so they can be queried through
> say whois, why are they needed at all?  In that case, the domain name
> or host name really is enough.

The list archives are back up.  I'm no fan of ROIDs myself, but instead of
rehashing the debate that led to their inclusion in the protocol I'd suggest
that you go through the archives.  It starts about here:

http://www.cafax.se/ietf-provreg/maillist/2001-01/maillist.html

and goes on for quite a while.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAQ1SX9p012756 for <[e-mail]>; Tue, 26 Nov 2002 02:28:33 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAQ1SXNs012755 for ietf-provreg-outgoing; Tue, 26 Nov 2002 02:28:33 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from whale.cnnic.net.cn ([159.226.6.187]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAQ1SU9p012750 for <[e-mail]>; Tue, 26 Nov 2002 02:28:31 +0100 (MET)
Received: from lwz ([159.226.7.67]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id H65TG000.L9P; Tue, 26 Nov 2002 09:28:48 +0800 
From: "wenzhe lu" <[e-mail]>
To: "Hollenbeck Scott" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: pendingDelete and ok status
Date: Tue, 26 Nov 2002 09:27:41 +0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by nic.cafax.se id gAQ1SW9p012751
Sender: [e-mail]
Precedence: bulk

Thx.  :-)

Lu Wenzhe

-----Original Message-----
From: Hollenbeck, Scott [mailto:[e-mail]]
Sent: Monday, November 25, 2002 8:16 PM
To: 'wenzhe lu'
Cc: [e-mail]
Subject: RE: pendingDelete and ok status


> I am from CNNIC(.cn registry). In our .cn registry system, an 
> expired domain name will be
> in pendingDelete status after it expires(I discuss this issue 
> with you before
> and you give us this suggestion, thx. :-). Do you remember? 
> ). If the registry system
> receive a renew command for this domain during the special 
> pendingDelete preriod, it will
> be in ok status again.But I have a question now: 
> 
> In general, pend* means an atom action. A domain with 
> pendingDelete status
> will be deleted after days. But in the situation discussed 
> above, a domain name with
> pendingDelete status will be in two possible results: ok or deleted.
> 
> Do you think it is ambivalent for pendingDelete's semanteme?
> If yes, what is your suggestion? Please tell me if you have 
> any good idea. :-)
> 
> Best Regards,
> 
> Lu Wenzhe

As described in section 2.3 of the domain mapping draft, a domain can't be
in both pending* status and "ok" status.  If a <renew> command is received
before the domain is deleted, you should replace the "pendingDelete" status
with "ok" status, or just remove "pendingDelete" status if there is another
status values that would preclude setting "ok" status.

-Scott-



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAPNwk9p012189 for <[e-mail]>; Tue, 26 Nov 2002 00:58:46 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAPNwkxb012188 for ietf-provreg-outgoing; Tue, 26 Nov 2002 00:58:46 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from rc.isc.org (rc.isc.org [204.152.187.2]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAPNwj9p012183 for <[e-mail]>; Tue, 26 Nov 2002 00:58:45 +0100 (MET)
Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by rc.isc.org (Postfix) with ESMTP id DD44CBFB5; Mon, 25 Nov 2002 23:58:43 +0000 (UTC) (envelope-from [e-mail])
Received: by farside.isc.org (Postfix, from userid 10015) id 8A852AA72; Mon, 25 Nov 2002 23:58:43 +0000 (UTC)
To: "Hollenbeck, Scott" <[e-mail]>
Cc: [e-mail]
Subject: Re: EPP statuses and other questions
References: <[e-mail]>
From: Michael Graff <[e-mail]>
Date: 25 Nov 2002 23:58:43 +0000
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 50
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

"Hollenbeck, Scott" <[e-mail]> writes:

> The unique identifier for domains and hosts is the domain name and
> host name, respectively.  The valid syntax for these names is
> defined in multiple normative references listed in the specs.

Coming in somewhat late to the EPP game, I still find the object
identifiers to be somewhat confusing.  For contacts, we have a
client-supplied string.  Ok, I can live with that.  For domains, you
say it's the domain name, and for hosts, the hostname.

Then, the "roid" is confusing.  Not only is it NOT returned in
response to a <create> command, it needs to be used in some cases as a
unique identifier!

For authinfo, if you're working on a domain object and want to specify
the authinfo for a contact instead, you use the contact's "roid" --
the client-supplied name (converted to a globally-unique ID), like
"SA1234-ISC" or "MG2-ISC" or whatever.

  C:          <domain:pw roid="JD1234-REP">2fooBAR</domain:pw>

This specifies that the password data is associated with the contact
JD1234-REP, not the domain object's password.  However, this
contact:roid isn't returned in response to a contact <create> request
but is for <info>.

Domains and hosts have riods too, and they are not the
hostname or domain name.  In what context are these to be used?
If the domain roid is really the global identifier (the local ID with
the registry identifier appended, like FLAME-ISC for an "isc"
registry) then the (for lack of a beter term) "handle" for a host or
domain isn't the host or domain name.

  S:        <domain:name>example.tld</domain:name>
  S:        <domain:roid>EXAMPLE1-REP</domain:roid>

Additionally, from the definition of a riod, a period isn't allowed,
and they can only be 80 characters long before the dash.  Domain names
can be longer.

So, once again, I'm back to thinking that we have a unique string (the
old style "handle" mentality) in EPP.  Am I still not seeing
something?

If the riods aren't used externally, so they can be queried through
say whois, why are they needed at all?  In that case, the domain name
or host name really is enough.

--Michael


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAPCGJ9p005950 for <[e-mail]>; Mon, 25 Nov 2002 13:16:19 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gAPCGJ5Q005949 for ietf-provreg-outgoing; Mon, 25 Nov 2002 13:16:19 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAPCGI9p005944 for <[e-mail]>; Mon, 25 Nov 2002 13:16:18 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA01777; Mon, 25 Nov 2002 07:16:09 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <V5CJAM5M>; Mon, 25 Nov 2002 07:15:50 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'wenzhe lu'" <[e-mail]>
Cc: [e-mail]
Subject: RE: pendingDelete and ok status
Date: Mon, 25 Nov 2002 07:15:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> I am from CNNIC(.cn registry). In our .cn registry system, an 
> expired domain name will be
> in pendingDelete status after it expires(I discuss this issue 
> with you before
> and you give us this suggestion, thx. :-). Do you remember? 
> ). If the registry system
> receive a renew command for this domain during the special 
> pendingDelete preriod, it will
> be in ok status again.But I have a question now: 
> 
> In general, pend* means an atom action. A domain with 
> pendingDelete status
> will be deleted after days. But in the situation discussed 
> above, a domain name with
> pendingDelete status will be in two possible results: ok or deleted.
> 
> Do you think it is ambivalent for pendingDelete's semanteme?
> If yes, what is your suggestion? Please tell me if you have 
> any good idea. :-)
> 
> Best Regards,
> 
> Lu Wenzhe

As described in section 2.3 of the domain mapping draft, a domain can't be
in both pending* status and "ok" status.  If a <renew> command is received
before the domain is deleted, you should replace the "pendingDelete" status
with "ok" status, or just remove "pendingDelete" status if there is another
status values that would preclude setting "ok" status.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAP82P9p004269 for <[e-mail]>; Mon, 25 Nov 2002 09:02:25 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAP82PPM004268 for ietf-provreg-outgoing; Mon, 25 Nov 2002 09:02:25 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from whale.cnnic.net.cn ([159.226.6.187]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAP82M9p004263 for <[e-mail]>; Mon, 25 Nov 2002 09:02:24 +0100 (MET)
Received: from lwz ([159.226.7.67]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id H64H0G00.R9R; Mon, 25 Nov 2002 16:02:40 +0800 
From: "wenzhe lu" <[e-mail]>
To: "Hollenbeck Scott" <[e-mail]>
Cc: <[e-mail]>
Subject: 
Date: Mon, 25 Nov 2002 16:01:37 +0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]6>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by nic.cafax.se id gAP82P9p004264
Sender: [e-mail]
Precedence: bulk

Dear Scott,

I am from CNNIC(.cn registry). In our .cn registry system, an expired domain name will be
in pendingDelete status after it expires(I discuss this issue with you before
and you give us this suggestion, thx. :-). Do you remember? ). If the registry system
receive a renew command for this domain during the special pendingDelete preriod, it will
be in ok status again.But I have a question now: 

In general, pend* means an atom action. A domain with pendingDelete status
will be deleted after days. But in the situation discussed above, a domain name with
pendingDelete status will be in two possible results: ok or deleted.

Do you think it is ambivalent for pendingDelete's semanteme?
If yes, what is your suggestion? Please tell me if you have any good idea. :-)

Best Regards,

Lu Wenzhe



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gALHY2sQ003015 for <[e-mail]>; Thu, 21 Nov 2002 18:34:02 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gALHY22p003014 for ietf-provreg-outgoing; Thu, 21 Nov 2002 18:34:02 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gALHY1sQ003009 for <[e-mail]>; Thu, 21 Nov 2002 18:34:01 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA29878; Thu, 21 Nov 2002 12:33:57 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <V87J01GN>; Thu, 21 Nov 2002 12:29:17 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Hong Liu'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Handling of External Host Objects
Date: Thu, 21 Nov 2002 12:33:31 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yes, it was discussed.  No specific conclusions were reached other than we
need to continue discussion.

I tried to summarize the main points of your objection to the currently
documented approach, but I don't recall anyone in the room supporting the
change you've proposed.  Hence the need for more discussion.

If anyone else who was in the room heard it differently, please speak up.

-Scott-

> -----Original Message-----
> From: Hong Liu [mailto:[e-mail]]
> Sent: Thursday, November 21, 2002 11:29 AM
> To: '[e-mail]'
> Subject: RE: Handling of External Host Objects
> 
> 
> Scott,
> 
> Sorry that I could not be in Atlanta to discuss this
> topic in person. Was this issue discussed during the
> provreg WG session? Any conlusion on this topic?
> 
> I certainly have my personal view on this, but I would
> like to hear from your feedback first.
> 
> Cheers,
> 
> --Hong
> 
> --- "Hollenbeck, Scott" <[e-mail]>
> wrote:
> > > To alleviate the problems mentioned above let me
> > propose the following
> > > changes
> > > to epp host and domain mapping documents:
> > 
> > If I understand this correctly you're suggesting a
> > move back to the way
> > things were (more or less, with some limits to
> > address the issues) before
> > the per-client thing came up, right?  I like the
> > idea of consistency and
> > simplicity -- what do others think?
> > 
> > -Scott-
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gALGSasQ002336 for <[e-mail]>; Thu, 21 Nov 2002 17:28:36 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gALGSZkF002335 for ietf-provreg-outgoing; Thu, 21 Nov 2002 17:28:35 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from web14306.mail.yahoo.com (web14306.mail.yahoo.com [216.136.173.82]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gALGSYsQ002330 for <[e-mail]>; Thu, 21 Nov 2002 17:28:34 +0100 (MET)
Message-ID: <[e-mail]>
Received: from [211.150.220.196] by web14306.mail.yahoo.com via HTTP; Thu, 21 Nov 2002 08:28:33 PST
Date: Thu, 21 Nov 2002 08:28:33 -0800 (PST)
From: Hong Liu <[e-mail]>
Subject: RE: Handling of External Host Objects
To: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Scott,

Sorry that I could not be in Atlanta to discuss this
topic in person. Was this issue discussed during the
provreg WG session? Any conlusion on this topic?

I certainly have my personal view on this, but I would
like to hear from your feedback first.

Cheers,

--Hong

--- "Hollenbeck, Scott" <[e-mail]>
wrote:
> > To alleviate the problems mentioned above let me
> propose the following
> > changes
> > to epp host and domain mapping documents:
> 
> If I understand this correctly you're suggesting a
> move back to the way
> things were (more or less, with some limits to
> address the issues) before
> the per-client thing came up, right?  I like the
> idea of consistency and
> simplicity -- what do others think?
> 
> -Scott-


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus – Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gALF7tsQ001270 for <[e-mail]>; Thu, 21 Nov 2002 16:07:55 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gALF7tE7001269 for ietf-provreg-outgoing; Thu, 21 Nov 2002 16:07:55 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gALF7rsQ001258 for <[e-mail]>; Thu, 21 Nov 2002 16:07:53 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA20901; Thu, 21 Nov 2002 10:07:52 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <V5C28SM3>; Thu, 21 Nov 2002 10:07:40 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'janusz sienkiewicz'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Handling of External Host Objects
Date: Thu, 21 Nov 2002 10:07:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> To alleviate the problems mentioned above let me propose the following
> changes
> to epp host and domain mapping documents:

If I understand this correctly you're suggesting a move back to the way
things were (more or less, with some limits to address the issues) before
the per-client thing came up, right?  I like the idea of consistency and
simplicity -- what do others think?

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gALBTgPG002264 for <[e-mail]>; Thu, 21 Nov 2002 12:29:42 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gALBTgbb002263 for ietf-provreg-outgoing; Thu, 21 Nov 2002 12:29:42 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mxintern.kundenserver.de (mxintern.kundenserver.de [212.227.126.201]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gALBTfPG002258 for <[e-mail]>; Thu, 21 Nov 2002 12:29:41 +0100 (MET)
Received: from rocco.schlund.de ([172.17.0.162] helo=schlund.de) by mxintern.kundenserver.de with esmtp (Exim 3.35 #1) id 18EpWe-0001JY-00; Thu, 21 Nov 2002 12:29:40 +0100
Message-ID: <[e-mail]>
Date: Thu, 21 Nov 2002 12:32:29 +0100
From: Jens-Uwe Gaspar <[e-mail]>
Organization: Schlund + Partner AG
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-17.7.x i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Michael Graff <[e-mail]>
CC: "Hollenbeck, Scott" <[e-mail]>, [e-mail]
Subject: Re: EPP statuses and other questions
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Dear Michael,

Michael Graff wrote:
> 
> "Hollenbeck, Scott" <[e-mail]> writes:
> 
> > People said that they wanted to include additional information describing
> > why a status has been applied, to add clarifying info, etc.  The server
> > might not care about the reason, but it's not necessarily there for server
> > interpretation -- it's there because it describes something about the
> > object.
> 
> I still don't think the registry is the place for this additional
> information.  I'm certain people want to store things like credit
> card numbers to bill people with, but the registry isn't the place for
> that, either.  I know my example here is absurd, but since the data
> isn't there for the operation of the registry, it should not be in
> the registry, IMHO.
> 
> Why flags were set on domains, hosts, etc. seems like it should go into
> the registrar database, instead.  But, I understand why it's there,
> even if I think it's a mistake.  :)

Sure, that kind of information can be stored in the registrar-database.
But we prefer that it is stored in the registry. It often happens, that
a domain has to be set on lock-status for UDRP/WIPO/injunctions.
Even so we store a comment like

  'domain locked at 21-Jan-2002 by request of somebody (UDRP)'

in our registrar-database, we also attach it as comment to the
lock-status in the registry. The registry holds in our case the
authoritative information.

The registry is a good place for it, so our customer support can
easily see the cause for the lock/hold from a registry-request only
(by some internal info-server). 

Kind regards,

Jens-Uwe Gaspar

>...

________________________________________________________________________
Jens-Uwe Gaspar                              Schlund + Partner AG
E-Mail: [e-mail]                       Erbprinzenstr. 4 - 12
Tel. [phone]                        76133 Karlsruhe, Germany
Fax  [phone]                        http://www.schlund.de


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAL123u6007109 for <[e-mail]>; Thu, 21 Nov 2002 02:02:03 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAL1234x007108 for ietf-provreg-outgoing; Thu, 21 Nov 2002 02:02:03 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from rc.isc.org (rc.isc.org [204.152.187.2]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAL122u6007103 for <[e-mail]>; Thu, 21 Nov 2002 02:02:02 +0100 (MET)
Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by rc.isc.org (Postfix) with ESMTP id 71F3CC72F; Thu, 21 Nov 2002 01:02:01 +0000 (UTC) (envelope-from [e-mail])
Received: by farside.isc.org (Postfix, from userid 10015) id 4933FAA72; Thu, 21 Nov 2002 01:02:01 +0000 (UTC)
To: "Hollenbeck, Scott" <[e-mail]>
Cc: "'Michael Graff'" <[e-mail]>, [e-mail]
Subject: Re: EPP statuses and other questions
References: <[e-mail]>
From: Michael Graff <[e-mail]>
Date: 21 Nov 2002 01:02:01 +0000
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 40
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

"Hollenbeck, Scott" <[e-mail]> writes:

> People said that they wanted to include additional information describing
> why a status has been applied, to add clarifying info, etc.  The server
> might not care about the reason, but it's not necessarily there for server
> interpretation -- it's there because it describes something about the
> object.

I still don't think the registry is the place for this additional
information.  I'm certain people want to store things like credit
card numbers to bill people with, but the registry isn't the place for
that, either.  I know my example here is absurd, but since the data
isn't there for the operation of the registry, it should not be in
the registry, IMHO.

Why flags were set on domains, hosts, etc. seems like it should go into
the registrar database, instead.  But, I understand why it's there,
even if I think it's a mistake.  :)

> The unique identifier for domains and hosts is the domain name and host
> name, respectively.  The valid syntax for these names is defined in multiple
> normative references listed in the specs.

Ahh, I missed that part, sorry.

> As I've said in a private response to a message you sent me off-list, the
> contact mapping is a general purpose mapping that is not necessarily for use
> only with domain names and the like.  The idea is that the identifier can be
> something that is easy for a human to remember, much like those you provide
> when you register for services like email accounts, web site accounts, etc.
> Implementers and server operators can define an implementation profile that
> requires certain strings in the ID, or restricts use of certain strings, but
> those limits are not something that should be built into the protocol
> itself.

I can see the need for this sort of thing, even if I don't like it.  I
assume this is so I can move my contact/domains to a new registrar without
having to change contact handles, etc.

--Michael


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAL0eQu6006891 for <[e-mail]>; Thu, 21 Nov 2002 01:40:26 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAL0eQbi006890 for ietf-provreg-outgoing; Thu, 21 Nov 2002 01:40:26 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAL0ePu6006885 for <[e-mail]>; Thu, 21 Nov 2002 01:40:25 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id TAA28624; Wed, 20 Nov 2002 19:40:23 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <V5C28DP2>; Wed, 20 Nov 2002 19:40:13 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Michael Graff'" <[e-mail]>, [e-mail]
Subject: RE: EPP statuses and other questions
Date: Wed, 20 Nov 2002 19:39:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> I have a few questions.  First, is it an error to attempt to 
> add a status
> to an object when that object already has that status?  For instance,
> adding clientHold to a domain when it already has that set?
> 
> Also, what about removing one that isn't there?
> 
> From a SQL point of view, it would be simplier to return an error.  To
> allow this would require loading the existing status information and
> comparing the changes to what's there, rather than simply returning
> an error to the client when the INSERT or DELETE fails.  (Remember,
> at least on PostgreSQL, an INSERT which violates constraints 
> like UNIQUE
> will abort the current transaction, so it would have to be restarted
> after removing the already-present status.)

If a request can not be completed as requested an error should be returned.
Status values can not exist twice, so I would say that an error should be
returned if a status can not be added because it's already present.  Same
for trying to remove one that's not there.

> While I'm on statuses, what is the reasoning for allowing clients to
> specify arbitrary text for why things are in a given status?  I can
> understand the server doing this, but allowing the client to add this
> seems to (1) make it difficult to return language-dependent messages,
> since the client specifies only one language for a status, and (2) is
> an odd separation of the registry-registrar data.  Even the example
> given:
> 
>   C:          <domain:status s="clientHold"
>   C:           lang="en">Payment overdue.</domain:status>
> 
> is something odd, since why would the registry _care_ why the
> clientHold, was there?  The registry seems like a bad place for this
> information, since it isn't clear if it is returned via say WHOIS.

People said that they wanted to include additional information describing
why a status has been applied, to add clarifying info, etc.  The server
might not care about the reason, but it's not necessarily there for server
interpretation -- it's there because it describes something about the
object.

> On to "server local" IDs.
> 
> What was the rationale for allowing the CLIENT to specify the 
> SERVER LOCAL
> identifier for contacts (and I assume domains, and hosts)?  
> This seems like
> a really bad idea.  For one, I could put some pretty rude IDs 
> in there,
> as a registrar.  Just choosing the first letters of a name 
> won't work, since
> I could choose "For Unlawful Carnal Knowledge, Very Slowly Goes Nim"
> and end up with the obvious contact ID.  :)
> 
> Additionally, during a transfer, the receiving registrar 
> can't change it,
> so what's the point in letting the originating one specify it?  The
> registrar should just record the ID assigned to the object by 
> the server
> and be done with it.

The unique identifier for domains and hosts is the domain name and host
name, respectively.  The valid syntax for these names is defined in multiple
normative references listed in the specs.

As I've said in a private response to a message you sent me off-list, the
contact mapping is a general purpose mapping that is not necessarily for use
only with domain names and the like.  The idea is that the identifier can be
something that is easy for a human to remember, much like those you provide
when you register for services like email accounts, web site accounts, etc.
Implementers and server operators can define an implementation profile that
requires certain strings in the ID, or restricts use of certain strings, but
those limits are not something that should be built into the protocol
itself.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAKN01u6006219 for <[e-mail]>; Thu, 21 Nov 2002 00:00:01 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAKN01wQ006218 for ietf-provreg-outgoing; Thu, 21 Nov 2002 00:00:01 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from isrv4.isc.org (isrv4.isc.org [204.152.184.27]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAKN00u6006201 for <[e-mail]>; Thu, 21 Nov 2002 00:00:01 +0100 (MET)
Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by isrv4.isc.org (Postfix) with ESMTP id 5FE2278E; Wed, 20 Nov 2002 22:59:59 +0000 (UTC) (envelope-from [e-mail])
Received: by farside.isc.org (Postfix, from userid 10015) id DA695AA73; Wed, 20 Nov 2002 22:59:58 +0000 (UTC)
To: [e-mail]
Subject: EPP statuses and other questions
From: Michael Graff <[e-mail]>
Date: 20 Nov 2002 22:59:58 +0000
Message-ID: <[e-mail]>
Lines: 69
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

I would check the mailing list archives, but...

Trying 192.71.228.17...
telnet: Unable to connect to remote host: Connection refused


I have a few questions.  First, is it an error to attempt to add a status
to an object when that object already has that status?  For instance,
adding clientHold to a domain when it already has that set?

Also, what about removing one that isn't there?

>From a SQL point of view, it would be simplier to return an error.  To
allow this would require loading the existing status information and
comparing the changes to what's there, rather than simply returning
an error to the client when the INSERT or DELETE fails.  (Remember,
at least on PostgreSQL, an INSERT which violates constraints like UNIQUE
will abort the current transaction, so it would have to be restarted
after removing the already-present status.)


While I'm on statuses, what is the reasoning for allowing clients to
specify arbitrary text for why things are in a given status?  I can
understand the server doing this, but allowing the client to add this
seems to (1) make it difficult to return language-dependent messages,
since the client specifies only one language for a status, and (2) is
an odd separation of the registry-registrar data.  Even the example
given:

  C:          <domain:status s="clientHold"
  C:           lang="en">Payment overdue.</domain:status>

is something odd, since why would the registry _care_ why the
clientHold, was there?  The registry seems like a bad place for this
information, since it isn't clear if it is returned via say WHOIS.


On to "server local" IDs.

What was the rationale for allowing the CLIENT to specify the SERVER LOCAL
identifier for contacts (and I assume domains, and hosts)?  This seems like
a really bad idea.  For one, I could put some pretty rude IDs in there,
as a registrar.  Just choosing the first letters of a name won't work, since
I could choose "For Unlawful Carnal Knowledge, Very Slowly Goes Nim"
and end up with the obvious contact ID.  :)

Additionally, during a transfer, the receiving registrar can't change it,
so what's the point in letting the originating one specify it?  The
registrar should just record the ID assigned to the object by the server
and be done with it.

As I see it, the spec can:

(1)  Allow it to be specified, but the server may choose to ignore it.
     If the server always ignores it, this will make <contact:check> a
     totally useless command, and having it will create oddness for the
     client.  I.e, either they'll do a <check> and get back "no" for
     everything, and since they HAVE to specify something, be confused, or
     they'll get back a false "OK" and have the value they prefer ignored.

(2)  Remove the ability for a client to specify the name at all.

(3)  Allow the <transfer> command to change the ID, or the <update>
     command to do so, or both.

I would prefer to see (2), since it puts the policy on ID patterns
where I think it should be, on the registry.

--Michael


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAKHoVu6003404 for <[e-mail]>; Wed, 20 Nov 2002 18:50:31 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAKHoVpa003403 for ietf-provreg-outgoing; Wed, 20 Nov 2002 18:50:31 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAKHoTu6003398 for <[e-mail]>; Wed, 20 Nov 2002 18:50:30 +0100 (MET)
Received: from dev3.int.libertyrms.com ([10.1.2.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 18EYzZ-0007CH-00; Wed, 20 Nov 2002 12:50:25 -0500
Message-ID: <[e-mail]>
Date: Wed, 20 Nov 2002 12:57:18 -0500
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3custom i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Handling of External Host Objects
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

I am not a big supporter of external hosts management per client basis.
By allowing limited mass domain updates on external host name change, the
feature makes epp client implementation easier. Unfortunatelly it makes
epp server implementation harder because it imposes asymetric treatment
of hosts objects (internal, external) across the whole system.  As
the thread shows it also complicates domain transfer implementation for
both epp client and epp server.

To alleviate the problems mentioned above let me propose the following
changes
to epp host and domain mapping documents:

Remove the text from host mapping document page 3:

  External host objects MUST be managed on a per-client basis.  No
  superordinate domain object exists in the repository, thus no single
  client has management authority for the superordinate domain object.
  Per-client management ensures that no single client can create an
  instance of an external host object to the detriment of other clients

Modify the text in  host mapping document page 18

  Host name changes MAY have an impact on associated objects that refer
  to the host object.  A host name change SHOULD NOT require additional
  updates of associated objects to preserve existing associations.

to

  Host name changes MAY have an impact on associated objects that refer
  to the host object.  In most situations a host name change SHOULD NOT
  require additional updates of associated objects to preserve existing
  associations. The only exception is external host name change for a host

  object that has associations with objects that are sponsored by a
different
  client. In such situation an EPP error message MUST be returned with
  error code 2305 ("Object association prohibits operation").

Remove the text from domain mapping document page 3:

  DNS domains can be delegated to external hosts.  If a domain has been
  delegated to an external host, a client MUST have created a host
  object for each delegation to an external host before requesting a
  domain transfer.  A transfer request or approval MUST fail with EPP
  error code 2305 if host objects representing the external hosts are
  not managed by the requesting client at the time a transfer request is
  made and at the time the transfer request is approved.


The changes above, unless I made a mistake or ommited something, should
result in the following
behaviour:

Mass updates on host name changes are allowed with one exception. If the
host is an external host
an error is returned if the host has associations with objects (domains)
sponsored by other clients.
If such situation occurs the client has still a way to provision the
change by creating a new external
host with the new name and updating affected objects sponsored by the
client.
Yes, it is imposing a limitation on "mass update" on external host name
change. In my opinion there
are benefits that justify the limitation. The two most important benefits
are:

No external host management per client basis is required.
Domain transfer request and approval process is simplified.

I know it is not a perfect solution but in my opinion it may be a
reasonable compromise for epp client
and server implementation.

Janusz

"Hollenbeck, Scott" wrote:

> > >This solution does not allow object-based management of
> > external hosts,
> > >which means that renaming the external host would need to be
> > done on a
> > >per-name basis.  It may address the other issues that people
> > have talked
> > >about on this thread, though.
> > >
> > I see how this could resolve/avoid a lot of potential problems
> > (transfers, ownership, etc), but with these new gTLDs, I would guess
> > that the majority of nameservers in use are non-authoritative to the
> > registries, so registrars would lose the ability to do mass
> > updates as
> > with nameservers as objects.  I don't think I would want to give this
> > up.  As a registrar, I would have to write scripts to perform mass
> > updates, taking up processing time on both the client and the server
> > systems.
>
> Which puts us right back where we started with this discussion... ;-)
>
> -Scott-



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAK3MncE018934 for <[e-mail]>; Wed, 20 Nov 2002 04:22:49 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gAK3Mnuj018933 for ietf-provreg-outgoing; Wed, 20 Nov 2002 04:22:49 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from web14307.mail.yahoo.com (web14307.mail.yahoo.com [216.136.173.83]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gAK3MlcE018928 for <[e-mail]>; Wed, 20 Nov 2002 04:22:48 +0100 (MET)
Message-ID: <[e-mail]>
Received: from [211.150.224.199] by web14307.mail.yahoo.com via HTTP; Tue, 19 Nov 2002 19:22:47 PST
Date: Tue, 19 Nov 2002 19:22:47 -0800 (PST)
From: Hong Liu <[e-mail]>
Subject: Re: last-verified-date
To: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]> wrote:
[snip...]
> 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
> 

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAJINJcE013521 for <[e-mail]>; Tue, 19 Nov 2002 19:23:19 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gAJINJOA013520 for ietf-provreg-outgoing; Tue, 19 Nov 2002 19:23:19 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAJINIcE013515 for <[e-mail]>; Tue, 19 Nov 2002 19:23:18 +0100 (MET)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id gAJINHOG039415 for <[e-mail]>; Tue, 19 Nov 2002 19:23:17 +0100 (CET) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id gAJINHVC039414 for [e-mail]; Tue, 19 Nov 2002 19:23:17 +0100 (CET)
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAJIGccE013463 for <[e-mail]>; Tue, 19 Nov 2002 19:16:38 +0100 (MET)
Received: from x22.ripe.net.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id gAJIGTZm014853; Tue, 19 Nov 2002 19:16:29 +0100
Date: Tue, 19 Nov 2002 19:16:29 +0100 (CET)
From: Bruce Campbell <[e-mail]>
X-X-Sender: [e-mail]
To: Edward Lewis <[e-mail]>
cc: [e-mail]
Subject: Re: UDP as a transport
In-Reply-To: <a05111b02ba0027eb0269@[204.42.65.231]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Tue, 19 Nov 2002, Edward Lewis wrote:

> (Paraphrasing) EPP MUST NOT use a datagram-based transport protocol.
> E.g., EPP MUST NOT be run using UDP or anyother protocol that does
> not natively provide reliability and congestion control services.

I'd flip it around, and require that EPP MUST be run on a transport that
provides reliability and congestion control services.  This should also
exclude some of the other estotic transports as well.

--==--
Bruce.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAJHxgcE013285 for <[e-mail]>; Tue, 19 Nov 2002 18:59:42 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gAJHxfSE013284 for ietf-provreg-outgoing; Tue, 19 Nov 2002 18:59:42 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from felix.automagic.org (felix.automagic.org [204.152.186.101]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gAJHxdcE013279 for <[e-mail]>; Tue, 19 Nov 2002 18:59:40 +0100 (MET)
Received: (qmail 10404 invoked by uid 0); 19 Nov 2002 17:59:38 -0000
Received: from localhost.automagic.org (HELO isc.org) (127.0.0.1) by localhost.automagic.org with SMTP; 19 Nov 2002 17:59:38 -0000
Date: Tue, 19 Nov 2002 12:59:37 -0500
Subject: Re: UDP as a transport
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v548)
Cc: [e-mail]
To: Edward Lewis <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <a05111b02ba0027eb0269@[204.42.65.231]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.548)
Sender: [e-mail]
Precedence: bulk

On Tuesday, Nov 19, 2002, at 12:44 Canada/Eastern, Edward Lewis wrote:

> After some more consultation with a Transport AD, we are being "urged" 
> to disallow the use of UDP as a transport for EPP.  Based on this, who 
> will take issue with:
>
> (Paraphrasing) EPP MUST NOT use a datagram-based transport protocol. 
> E.g., EPP MUST NOT be run using UDP or anyother protocol that does not 
> natively provide reliability and congestion control services.

It might be better to specify the specific objectionable aspects of a 
UDP transport that should not feature in a transport, rather than 
talking about a datagram-based transport.

For example, the fact that requests over UDP can be submitted with 
trivially spoofed source addresses, or that encryption or 
transport-layer authentication has to happen per transaction, rather 
than per session, might be characteristics which should not feature in 
an EPP transport protocol.

Mandating reliability seems like a poor idea (how do you do SMTP 
transport if you need transport-layer reliability?)


Joe



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAJHiLcE013120 for <[e-mail]>; Tue, 19 Nov 2002 18:44:21 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gAJHiL8H013119 for ietf-provreg-outgoing; Tue, 19 Nov 2002 18:44:21 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAJHiJcE013114 for <[e-mail]>; Tue, 19 Nov 2002 18:44:20 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gAJHiGYm011039 for <[e-mail]>; Tue, 19 Nov 2002 12:44:17 -0500 (EST)
Received: from [204.42.65.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA04487; Tue, 19 Nov 2002 12:44:15 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b02ba0027eb0269@[204.42.65.231]>
Date: Tue, 19 Nov 2002 12:44:06 -0500
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: UDP as a transport
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

After some more consultation with a Transport AD, we are being 
"urged" to disallow the use of UDP as a transport for EPP.  Based on 
this, who will take issue with:

(Paraphrasing) EPP MUST NOT use a datagram-based transport protocol. 
E.g., EPP MUST NOT be run using UDP or anyother protocol that does 
not natively provide reliability and congestion control services.

That wording is meant to provoke discussion - I am not proposing that 
text for inclusion in the specification.  We can derive that text 
once we hear comments on this thread.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAJG0jcE012119 for <[e-mail]>; Tue, 19 Nov 2002 17:00:45 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAJG0jBi012118 for ietf-provreg-outgoing; Tue, 19 Nov 2002 17:00:45 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAJG0icE012113 for <[e-mail]>; Tue, 19 Nov 2002 17:00:44 +0100 (MET)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id gAJG0hOG038989 for <[e-mail]>; Tue, 19 Nov 2002 17:00:43 +0100 (CET) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id gAJG0h4O038988 for [e-mail]; Tue, 19 Nov 2002 17:00:43 +0100 (CET)
Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAJF7xcE011646 for <[e-mail]>; Tue, 19 Nov 2002 16:08:00 +0100 (MET)
Received: from dick.shockey.us (dick.ietf55.ops.ietf.org [204.42.72.131]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id HAA11743 for <[e-mail]>; Tue, 19 Nov 2002 07:07:31 -0800
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 19 Nov 2002 10:03:45 -0500
To: [e-mail]
From: Richard Shockey <[e-mail]>
Subject: Fwd: P3P next steps list
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

FYI

>From: Lorrie Cranor <[e-mail]>
>Reply-To: Lorrie Cranor <[e-mail]>
>To: [e-mail]
>Subject: P3P next steps list
>Date: Thu, 14 Nov 2002 21:06:24 -0500
>X-Mailer: Internet Mail Service (5.5.2653.19)
>List-Help: <http://www.w3.org/Mail/>
>List-Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
>
>
>Thanks to everyone who participated for a great workshop! We
>had some very useful discussions and got a good sense of
>the areas where there is interest in additional work. Rough minutes
>will be sent to this list soon and a summary report should be ready
>in mid-December.
>
>The following is the list of areas for future work that we identified
>and prioritized during the closing session. I have indicated the
>names of the people who volunteered to write up a 1 page proposal
>on each of these areas. Please include purpose, scope, resources,
>and time frame and send your proposals to this mailing list by
>Dec. 13.
>
>
>Areas for future work
>
>1. Vocabulary issues [high priority - mostly for 1.1, maybe some for 2.0]
>   a. Article 10 issues [volunteers: Diana and Giles]
>   b. primary data uses [volunteer: Lorrie]
>   c. general vocab review [maybe longterm - volunteer: Lorrie]
>
>2. Indication of agent status, multiple domains owned by same company,
>   etc. [high priority - possibly for 1.1, otherwise for 2.0 -
>   volunteer: Brian Zwit]
>
>3. Spec ambiguities [short term high priority - volunteer: Matthias]
>
>4. Compact policies [high priority for 1.1, Brooks has been
>   volunteered]
>   a. What are performance issues that motivate CP and what are
>      alternative approaches? Where exactly is the problem?
>   b. Semantic issues
>   c. Cross-product problem -- need for grouping mechanism
>   d. Agent status, multiple domains owned by the same company, etc.
>
>5. User agent behavior [high priority, either short term or long term,
>   volunteer: Brian Zwit]
>   a. Human readable notices
>     i. user friendly version in spec (must, should, or reference examples)
>     ii. coordinate with short notices
>
>6. Statements in the spec to better articulate what P3P is and isn't
>   [short term high priority, volunteer: Brian Zwit]
>
>7. How to use P3P w/out binding to HTTP and URIs [quick win,
>   volunteer: Danny]
>
>8. Consent recording mechanism [high priority, long term, volunteer:
>   Matthias]
>
>9. Feedback channel [little interest]
>
>10. User preference language -- APPEL, etc. [high priority, volunteer:
>Giles]
>   a. ontology - default languages
>
>11. Convert P3P data schema to XML schema [low priority but might be
>     quick win, volunteer: Giles]
>
>12. Coordination with other efforts [high priority for both short
>     term and long term, volunteer: Danny]
>     a. Liberty Alliance
>     b. Other authentication efforts
>     c. Web services/SOAP
>     d. Geopriv
>     e. Short notices
>     f. DAML
>
>13. XML signatures [low priority but might be quick win, volunteer: Giles]
>
>14. P3P in backend databases [little interest]
>
>15. Identity management [Marit volunteered by Rigo]
>
>16. Outreach - to be covered by POWG
>
>
>Workshop Deliverables
>1. raw minutes (send to rigo for posting)
>2. this list
>3. summary report (Lorrie and Danny will prepare draft by Dec. 13)
>4. one page write ups (first drafts sent to workshop mailing list by
>    Dec. 13) -- include purpose, scope, resources, time frame


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: [phone]
<mailto:[e-mail]> or <mailto:[e-mail]>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAJ3C2cE006868 for <[e-mail]>; Tue, 19 Nov 2002 04:12:02 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAJ3C1tL006867 for ietf-provreg-outgoing; Tue, 19 Nov 2002 04:12:01 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAJ3C0cE006862 for <[e-mail]>; Tue, 19 Nov 2002 04:12:01 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id WAA25155; Mon, 18 Nov 2002 22:11:58 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <V87J8PB2>; Mon, 18 Nov 2002 22:07:25 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: updated agenda
Date: Mon, 18 Nov 2002 22:11:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Ed,

We should also try to talk about the external hosts thread that has been on
the WG mailing list over the last few weeks.  It would seem to fit in the
same section as Rick's "last verified" proposal.

-Scott-

> -----Original Message-----
> From: Edward Lewis [mailto:[e-mail]]
> Sent: Monday, November 18, 2002 4:10 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: updated agenda
> 
> 
> In the past few days, we've done some re-working of the agenda, not 
> removing any topics from those we are expecting input, dropping folks 
> that we know won't be there, etc.  We've also done this from the 
> perspective of wanting to determine if we should think of shutting 
> down the WG in the near future.
> 
> That may sound drastic, but it is in line with the way the IETF 
> works.  WG's are not intended to be persistent, but are in place to 
> achieve certain goals.  (In case you are concerned about achieving 
> draft standard status, that can be done be convening another WG to do 
> that step.  It doesn't have to happen in the same WG that produces a 
> proposed standard.)
> 
> So, with that premise, here's an updated version of the agenda:
> 
> 1 Agenda bashing - 5 mins
> 
> 2 IESG issues with base, 30 m
> 
>      Listing of the comments
>        and
>      Addressing the issues
> 
>      Ed and Scott - what ever this takes, it is the main item
> 
> 2.5 Other issues with the base 10m
> 
>      Last-Verified
> 
>      Rick
> 
> 3 SOAP submission 20m or so
> 
>      Jon Peterson for Hong Liu
>      Group should ask: is this of general interest?  Is there need to
>      work towards an interoperable version of this?
> 
>      Even if the work is of good quality, it might not be 
> general enough
>      for us to work on it.  I don't want us to judge the quality - but
>      judge the appropriateness for the WG.
> 
> 4 SMTP submission 20m
> 
>      No presentation on the document is planned, but, once again,
>      does anyone to pick this up?  Besides passing interests, is
>      there multiple folks willing to commit to making this happen?
> 
> 5 Extension Guidelines Draft 10m ?
> 
>      I would like to have a real discussion as this is may be the last
>      work item we have and it should be easy to get this finished
> 
> 6 Discussion on the future of the WG
> 
>      To end the group we need to get the extension doc done, not admit
>      the new docs, and drop the interop milestone.  'Course - 
> we're not
>      advocating this, I am not stating that the new docs 
> won't be acceptable,
>      but we want to ask the question about closing the WG soon.
> 
>      We strongly want to impress on the group that there's 
> resistance to
>      the new documents, but we want to take a hard look at 
> whether these
>      will prolong the WG's life.  The last thing I want to have is a
>      languishing WG hanging around.
> 
>      Closing the WG doesn't mean that we shut down the mail list - so
>      comments from implementations can roll keep rolling in.
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                          [phone]
> ARIN Research Engineer
> 


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAJ2dfcE006432 for <[e-mail]>; Tue, 19 Nov 2002 03:39:41 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gAJ2dfYD006431 for ietf-provreg-outgoing; Tue, 19 Nov 2002 03:39:41 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAJ2decE006426 for <[e-mail]>; Tue, 19 Nov 2002 03:39:40 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gAJ1LWYm093920 for <[e-mail]>; Mon, 18 Nov 2002 20:21:32 -0500 (EST)
Received: from [204.42.65.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id UAA16019; Mon, 18 Nov 2002 20:21:19 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b02b9ff426c7cf2@[204.42.65.231]>
Date: Mon, 18 Nov 2002 20:21:11 -0500
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: need a scribe for tomorrow
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

I might as well start asking for a volunteer now - 13 hours before the session.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAIL9gcE003902 for <[e-mail]>; Mon, 18 Nov 2002 22:09:42 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAIL9gjf003901 for ietf-provreg-outgoing; Mon, 18 Nov 2002 22:09:42 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAIL9fcE003896 for <[e-mail]>; Mon, 18 Nov 2002 22:09:42 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gAIL9cYm087382; Mon, 18 Nov 2002 16:09:40 -0500 (EST)
Received: from [204.42.65.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA15959; Mon, 18 Nov 2002 16:09:35 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b07b9ff03cd38b2@[204.42.65.231]>
Date: Mon, 18 Nov 2002 16:09:37 -0500
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: updated agenda
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

In the past few days, we've done some re-working of the agenda, not 
removing any topics from those we are expecting input, dropping folks 
that we know won't be there, etc.  We've also done this from the 
perspective of wanting to determine if we should think of shutting 
down the WG in the near future.

That may sound drastic, but it is in line with the way the IETF 
works.  WG's are not intended to be persistent, but are in place to 
achieve certain goals.  (In case you are concerned about achieving 
draft standard status, that can be done be convening another WG to do 
that step.  It doesn't have to happen in the same WG that produces a 
proposed standard.)

So, with that premise, here's an updated version of the agenda:

1 Agenda bashing - 5 mins

2 IESG issues with base, 30 m

     Listing of the comments
       and
     Addressing the issues

     Ed and Scott - what ever this takes, it is the main item

2.5 Other issues with the base 10m

     Last-Verified

     Rick

3 SOAP submission 20m or so

     Jon Peterson for Hong Liu
     Group should ask: is this of general interest?  Is there need to
     work towards an interoperable version of this?

     Even if the work is of good quality, it might not be general enough
     for us to work on it.  I don't want us to judge the quality - but
     judge the appropriateness for the WG.

4 SMTP submission 20m

     No presentation on the document is planned, but, once again,
     does anyone to pick this up?  Besides passing interests, is
     there multiple folks willing to commit to making this happen?

5 Extension Guidelines Draft 10m ?

     I would like to have a real discussion as this is may be the last
     work item we have and it should be easy to get this finished

6 Discussion on the future of the WG

     To end the group we need to get the extension doc done, not admit
     the new docs, and drop the interop milestone.  'Course - we're not
     advocating this, I am not stating that the new docs won't be acceptable,
     but we want to ask the question about closing the WG soon.

     We strongly want to impress on the group that there's resistance to
     the new documents, but we want to take a hard look at whether these
     will prolong the WG's life.  The last thing I want to have is a
     languishing WG hanging around.

     Closing the WG doesn't mean that we shut down the mail list - so
     comments from implementations can roll keep rolling in.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAIGMKcE001613 for <[e-mail]>; Mon, 18 Nov 2002 17:22:20 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gAIGMKJj001612 for ietf-provreg-outgoing; Mon, 18 Nov 2002 17:22:20 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail7.knipp.de (mail7.knipp.de [195.253.6.55]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAIGMIcE001607 for <[e-mail]>; Mon, 18 Nov 2002 17:22:18 +0100 (MET)
Received: (from root@localhost) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) id RAA16563; Mon, 18 Nov 2002 17:22:14 +0100 (MET)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id RAA16555; Mon, 18 Nov 2002 17:22:11 +0100 (MET)
Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id RAA07592; Mon, 18 Nov 2002 17:22:10 +0100 (MET)
Message-ID: <[e-mail]>
Date: Mon, 18 Nov 2002 17:21:44 +0100
From: Klaus Malorny <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20021115
X-Accept-Language: en, de
MIME-Version: 1.0
To: Hong Liu <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: last-verified-date
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by AMaViS perl-11
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id gAIGMJcE001608
Sender: [e-mail]
Precedence: bulk

Hong Liu wrote:
> 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
> 

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


___________________________________________________________________________
      |       |
      | knipp |                   Knipp  Medien und Kommunikation GmbH
       -------                           Technologiepark
                                         Martin-Schmeißer-Weg 9
      Dipl. Inf. Klaus Malorny           44227 Dortmund
      [e-mail]             Tel. [phone]





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAIEJYcE000435 for <[e-mail]>; Mon, 18 Nov 2002 15:19:34 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gAIEJYHj000434 for ietf-provreg-outgoing; Mon, 18 Nov 2002 15:19:34 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from web14307.mail.yahoo.com (web14307.mail.yahoo.com [216.136.173.83]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gAIEJWcE000429 for <[e-mail]>; Mon, 18 Nov 2002 15:19:32 +0100 (MET)
Message-ID: <[e-mail]>
Received: from [159.226.7.85] by web14307.mail.yahoo.com via HTTP; Mon, 18 Nov 2002 06:19:31 PST
Date: Mon, 18 Nov 2002 06:19:31 -0800 (PST)
From: Hong Liu <[e-mail]>
Subject: Re: last-verified-date
To: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

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

--- Rick Wesson <[e-mail]> wrote:
> 
> 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
> 
> 


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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAHL2TcE023067 for <[e-mail]>; Sun, 17 Nov 2002 22:02:29 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAHL2TVi023066 for ietf-provreg-outgoing; Sun, 17 Nov 2002 22:02:29 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAHL2ScE023061 for <[e-mail]>; Sun, 17 Nov 2002 22:02:28 +0100 (MET)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id gAHL2ROG031274 for <[e-mail]>; Sun, 17 Nov 2002 22:02:27 +0100 (CET) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id gAHL2R1j031273 for [e-mail]; Sun, 17 Nov 2002 22:02:27 +0100 (CET)
Received: from web14310.mail.yahoo.com (web14310.mail.yahoo.com [216.136.224.60]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gAHGcHcE021717 for <[e-mail]>; Sun, 17 Nov 2002 17:38:18 +0100 (MET)
Message-ID: <[e-mail]>
Received: from [211.150.223.5] by web14310.mail.yahoo.com via HTTP; Sun, 17 Nov 2002 08:38:16 PST
Date: Sun, 17 Nov 2002 08:38:16 -0800 (PST)
From: Hong Liu <[e-mail]>
Subject: Re: last-verified-date
To: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

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

--- Rick Wesson <[e-mail]> wrote:
> 
> 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
> 
> 


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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAFFvGcE003186 for <[e-mail]>; Fri, 15 Nov 2002 16:57:16 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gAFFvGc1003185 for ietf-provreg-outgoing; Fri, 15 Nov 2002 16:57:16 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAFFvFcE003180 for <[e-mail]>; Fri, 15 Nov 2002 16:57:15 +0100 (MET)
Received: from james.nic.fr (IDENT:[e-mail] [192.134.4.83]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id gAFFvD7I1204938; Fri, 15 Nov 2002 16:57:13 +0100 (CET)
Received: (from guillard@localhost) by james.nic.fr (8.11.0/8.11.0) id gAFFwCl13130; Fri, 15 Nov 2002 16:58:12 +0100
Date: Fri, 15 Nov 2002 16:58:12 +0100
From: Olivier Guillard <[e-mail]>
To: Klaus Malorny <[e-mail]>
Cc: Olivier Guillard / AFNIC <[e-mail]>, Rick Wesson <[e-mail]>, James M Woods <[e-mail]>, [e-mail]
Subject: Re: last-verified-date
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Nov 15, 2002 at 04:11:42PM +0100
Sender: [e-mail]
Precedence: bulk

> 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.

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 
> innermost zone is the only authoritative source of the IP address of a name 
> server.

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

Olivier

le vendredi 15 novembre à 16 H 11 , Klaus Malorny a écrit :
> Olivier Guillard / AFNIC wrote:
> > Hello Klaus,
> > 
> > 
> >>Just for clarity: The registry does not manage the in-zone name servers 
> >>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
> 
> 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").
> 
> 
> regards,
> 
> Klaus
> 
> 
> ___________________________________________________________________________
>       |       |
>       | knipp |                   Knipp  Medien und Kommunikation GmbH
>        -------                           Technologiepark
>                                          Martin-Schmeißer-Weg 9
>       Dipl. Inf. Klaus Malorny           44227 Dortmund
>       [e-mail]             Tel. [phone]
> 
> 

-- 
Olivier Guillard
---
|| AFNIC - Immeuble International
|| 2 rue Stephenson - Montigny-le-Bretonneux
|| 78181, Saint-Quentin-en-Yvelines CEDEX, France
|| http://www.nic.fr/
|| mailto:[e-mail]
|| tel: [phone]


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAFFCYcE002727 for <[e-mail]>; Fri, 15 Nov 2002 16:12:34 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gAFFCYDa002726 for ietf-provreg-outgoing; Fri, 15 Nov 2002 16:12:34 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail7.knipp.de (mail7.knipp.de [195.253.6.55]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAFFCWcE002721 for <[e-mail]>; Fri, 15 Nov 2002 16:12:32 +0100 (MET)
Received: (from root@localhost) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) id QAA00663; Fri, 15 Nov 2002 16:12:21 +0100 (MET)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id QAA00655; Fri, 15 Nov 2002 16:12:19 +0100 (MET)
Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id QAA16559; Fri, 15 Nov 2002 16:12:17 +0100 (MET)
Message-ID: <[e-mail]>
Date: Fri, 15 Nov 2002 16:11:42 +0100
From: Klaus Malorny <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20021114
X-Accept-Language: en, de
MIME-Version: 1.0
To: Olivier Guillard / AFNIC <[e-mail]>
CC: Rick Wesson <[e-mail]>, James M Woods <[e-mail]>, [e-mail]
Subject: Re: last-verified-date
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by AMaViS perl-11
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id gAFFCXcE002722
Sender: [e-mail]
Precedence: bulk

Olivier Guillard / AFNIC wrote:
> Hello Klaus,
> 
> 
>>Just for clarity: The registry does not manage the in-zone name servers 
>>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

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


___________________________________________________________________________
      |       |
      | knipp |                   Knipp  Medien und Kommunikation GmbH
       -------                           Technologiepark
                                         Martin-Schmeißer-Weg 9
      Dipl. Inf. Klaus Malorny           44227 Dortmund
      [e-mail]             Tel. [phone]






Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAFEL8cE002359 for <[e-mail]>; Fri, 15 Nov 2002 15:21:08 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAFEL8hq002358 for ietf-provreg-outgoing; Fri, 15 Nov 2002 15:21:08 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mailhost.chi1.ameritech.net (mailhost1-chcgil.chcgil.ameritech.net [206.141.192.67]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAFEL6cE002353 for <[e-mail]>; Fri, 15 Nov 2002 15:21:06 +0100 (MET)
Received: from repligate ([67.36.190.93]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20021115142104.TDRY29240.mailhost.chi1.ameritech.net@repligate>; Fri, 15 Nov 2002 08:21:04 -0600
Message-ID: <13d801c28cb2$59e9b130$5dbe2443@repligate>
From: "Jim Fleming" <[e-mail]>
To: "Daniel Manley" <[e-mail]>
Cc: <[e-mail]>
References: <000401c28c24$f8ce5be0$6c01a8c0@locker> <[e-mail]>
Subject: .US Update
Date: Fri, 15 Nov 2002 08:21:55 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

From: "Daniel Manley" <[e-mail]>
> 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?


http://www.dnso.org/clubpublic/registrars/Arc01/msg03547.html
From: "Michael D. Palage" <[e-mail]>
.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


----- Original Message -----
From: "Daniel Manley" <[e-mail]>
To: "James M Woods" <[e-mail]>
Cc: "'Rick Wesson'" <[e-mail]>; <[e-mail]>
Sent: Friday, November 15, 2002 8:08 AM
Subject: Re: last-verified-date


> 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
>
>
> James M Woods a écrit:
>
> >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: [e-mail] [mailto:[e-mail]]
> >On Behalf Of Rick Wesson
> >Sent: November 14, 2002 4:05 PM
> >To: '[e-mail]'
> >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.
> >
> >I appreciate any thoughts the group has on this proposal.
> >
> >thanks,
> >
> >-rick
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> Daniel Manley
> Tucows, Inc.
> Toronto, Canada
> [e-mail]
>
>
>
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAFEBZcE002272 for <[e-mail]>; Fri, 15 Nov 2002 15:11:35 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gAFEBZD7002271 for ietf-provreg-outgoing; Fri, 15 Nov 2002 15:11:35 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from toronto.mail.tucows.com (bfos.tucows.com [207.136.98.11]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAFEBYcE002266 for <[e-mail]>; Fri, 15 Nov 2002 15:11:34 +0100 (MET)
Received: from dmanley.pc.internal.tucows.com ([10.0.10.19] helo=tucows.com) by toronto.mail.tucows.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.36 #3) id 18ChC1-0007Cr-00; Fri, 15 Nov 2002 09:11:33 -0500
Message-ID: <[e-mail]>
Date: Fri, 15 Nov 2002 09:08:55 -0500
From: Daniel Manley <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.0.1) Gecko/20020918
X-Accept-Language: en-us
MIME-Version: 1.0
To: James M Woods <[e-mail]>
CC: "'Rick Wesson'" <[e-mail]>, [e-mail]
Subject: Re: last-verified-date
References: <000401c28c24$f8ce5be0$6c01a8c0@locker>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

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


James M Woods a écrit:

>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: [e-mail] [mailto:[e-mail]]
>On Behalf Of Rick Wesson
>Sent: November 14, 2002 4:05 PM
>To: '[e-mail]'
>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.
>
>I appreciate any thoughts the group has on this proposal.
>
>thanks,
>
>-rick
>
>
>
>
>
>  
>


-- 
Daniel Manley
Tucows, Inc.
Toronto, Canada
[e-mail]





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAFACgcE000630 for <[e-mail]>; Fri, 15 Nov 2002 11:12:42 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAFACgxN000629 for ietf-provreg-outgoing; Fri, 15 Nov 2002 11:12:42 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAFACfcE000624 for <[e-mail]>; Fri, 15 Nov 2002 11:12:41 +0100 (MET)
Received: from james.nic.fr (IDENT:[e-mail] [192.134.4.83]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id gAFACb7I1173086; Fri, 15 Nov 2002 11:12:37 +0100 (CET)
Received: (from guillard@localhost) by james.nic.fr (8.11.0/8.11.0) id gAFADaE05711; Fri, 15 Nov 2002 11:13:36 +0100
Date: Fri, 15 Nov 2002 11:13:36 +0100
From: Olivier Guillard / AFNIC <[e-mail]>
To: Klaus Malorny <[e-mail]>
Cc: Rick Wesson <[e-mail]>, James M Woods <[e-mail]>, [e-mail]
Subject: Re: last-verified-date
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Nov 15, 2002 at 12:05:02AM +0100
Sender: [e-mail]
Precedence: bulk

Hello Klaus,

> Just for clarity: The registry does not manage the in-zone name servers 
> 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

le vendredi 15 novembre à 00 H 05 , Klaus Malorny a écrit :
> Rick Wesson wrote:
> > 
> 
> Hi Rick,
> 
> > 
> > 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.
> > 
> 
 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
>       [e-mail]             Tel. [phone]

-- 
Olivier


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAEN2dcE026056 for <[e-mail]>; Fri, 15 Nov 2002 00:02:39 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gAEN2dsT026055 for ietf-provreg-outgoing; Fri, 15 Nov 2002 00:02:39 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail7.knipp.de (mail7.knipp.de [195.253.6.55]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAEN2ccE026050 for <[e-mail]>; Fri, 15 Nov 2002 00:02:38 +0100 (MET)
Received: (from root@localhost) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) id AAA19949; Fri, 15 Nov 2002 00:02:27 +0100 (MET)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id AAA19941; Fri, 15 Nov 2002 00:02:25 +0100 (MET)
Received: from knipp.de (hp9000.do.knipp.de [195.253.2.54]) by hp9000.do.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id AAA29983; Fri, 15 Nov 2002 00:02:22 +0100 (MET)
Message-ID: <[e-mail]>
Date: Fri, 15 Nov 2002 00:05:02 +0100
From: Klaus Malorny <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021021
X-Accept-Language: en, de
MIME-Version: 1.0
To: Rick Wesson <[e-mail]>
CC: James M Woods <[e-mail]>, [e-mail]
Subject: Re: last-verified-date
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Rick Wesson wrote:
> 

Hi Rick,

> 
> 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.
> 

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
      [e-mail]             Tel. [phone]



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAEM2PcE025477 for <[e-mail]>; Thu, 14 Nov 2002 23:02:25 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAEM2PEn025476 for ietf-provreg-outgoing; Thu, 14 Nov 2002 23:02:25 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from tomts23-srv.bellnexxia.net (tomts23-srv.bellnexxia.net [209.226.175.185]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAEM2NcE025471 for <[e-mail]>; Thu, 14 Nov 2002 23:02:24 +0100 (MET)
Received: from locker ([65.95.186.224]) by tomts23-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20021114220222.MMBW9028.tomts23-srv.bellnexxia.net@locker>; Thu, 14 Nov 2002 17:02:22 -0500
From: "James M Woods" <[e-mail]>
To: "'Rick Wesson'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: last-verified-date
Date: Thu, 14 Nov 2002 17:02:13 -0500
Message-ID: <000701c28c29$7f9d05a0$6c01a8c0@locker>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk

>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:[e-mail]] 
Sent: November 14, 2002 4:50 PM
To: James M Woods
Cc: [e-mail]
Subject: RE: last-verified-date




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

> 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?


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









Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAELnrcE025305 for <[e-mail]>; Thu, 14 Nov 2002 22:49:53 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAELnqgg025304 for ietf-provreg-outgoing; Thu, 14 Nov 2002 22:49:52 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAELnpcE025299 for <[e-mail]>; Thu, 14 Nov 2002 22:49:52 +0100 (MET)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id gAELnoFP013081; Thu, 14 Nov 2002 13:49:51 -0800 (PST)
Date: Thu, 14 Nov 2002 13:49:56 -0800 (PST)
From: Rick Wesson <[e-mail]>
To: James M Woods <[e-mail]>
cc: <[e-mail]>
Subject: RE: last-verified-date
In-Reply-To: <000401c28c24$f8ce5be0$6c01a8c0@locker>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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

> 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?


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







Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAELU1cE025105 for <[e-mail]>; Thu, 14 Nov 2002 22:30:01 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAELU0Th025104 for ietf-provreg-outgoing; Thu, 14 Nov 2002 22:30:00 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from tomts8-srv.bellnexxia.net (tomts8.bellnexxia.net [209.226.175.52]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAELTxcE025096 for <[e-mail]>; Thu, 14 Nov 2002 22:29:59 +0100 (MET)
Received: from locker ([65.95.186.224]) by tomts8-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20021114212958.FCPQ21613.tomts8-srv.bellnexxia.net@locker>; Thu, 14 Nov 2002 16:29:58 -0500
From: "James M Woods" <[e-mail]>
To: "'Rick Wesson'" <[e-mail]>, <[e-mail]>
Subject: RE: last-verified-date
Date: Thu, 14 Nov 2002 16:29:48 -0500
Message-ID: <000401c28c24$f8ce5be0$6c01a8c0@locker>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk

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: [e-mail] [mailto:[e-mail]]
On Behalf Of Rick Wesson
Sent: November 14, 2002 4:05 PM
To: '[e-mail]'
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.

I appreciate any thoughts the group has on this proposal.

thanks,

-rick







Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAEL4wcE024933 for <[e-mail]>; Thu, 14 Nov 2002 22:04:58 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gAEL4wC0024932 for ietf-provreg-outgoing; Thu, 14 Nov 2002 22:04:58 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAEL4ucE024927 for <[e-mail]>; Thu, 14 Nov 2002 22:04:57 +0100 (MET)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id gAEL4tFP012735 for <[e-mail]>; Thu, 14 Nov 2002 13:04:55 -0800 (PST)
Date: Thu, 14 Nov 2002 13:05:00 -0800 (PST)
From: Rick Wesson <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: last-verified-date
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAEKojcE024755 for <[e-mail]>; Thu, 14 Nov 2002 21:50:45 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAEKojlU024754 for ietf-provreg-outgoing; Thu, 14 Nov 2002 21:50:45 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from toronto.mail.tucows.com (bfos.tucows.com [207.136.98.11]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAEKoicE024749 for <[e-mail]>; Thu, 14 Nov 2002 21:50:44 +0100 (MET)
Received: from dmanley.pc.internal.tucows.com ([10.0.10.19] helo=tucows.com) by toronto.mail.tucows.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.36 #3) id 18CQwk-0005s5-00 for [e-mail]; Thu, 14 Nov 2002 15:50:42 -0500
Message-ID: <[e-mail]>
Date: Thu, 14 Nov 2002 15:48:01 -0500
From: Daniel Manley <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.0.1) Gecko/20020918
X-Accept-Language: en-us
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
Subject: Re: Handling of External Host Objects (in the context of domain transfer)
References: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
I've been reading over this thread a bit more to get a better understanding.
&nbsp;I didn't see any response to this sub-thread created by Hong (though perhaps
it's been beat to death and I just haven't gotten to that part yet).<br>
<br>
I believe that Hong's suggestion in this additional wording:<br>
<br>
<pre wrap="">&gt; "A transfer request or approval MUST fail with EPP error code 2305 if host
&gt; objects representing the external hosts _do not exist_ for the requesting
&gt; client at the time a transfer request is made and at the time the transfer
&gt; request is approved."</pre>
It seems to essentially echo Asbjorn's comment earlier in [1] regarding automagically
swapping the host references out of convenience. &nbsp;I personally like this
suggestion -- I wish somehow this was possible with contacts. &nbsp;It helps simplify
the domain transfer process.<br>
<br>
Dan<br>
<br>
[1] <a class="moz-txt-link-freetext" href="http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00102.html">http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00102.html</a><br>
<br>
<br>
<br>
<br>
Liu, Hong a &eacute;crit:<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">Jim, Asbjorn,

There are two topics that are intervined on this thread of discussions:

(1) The wording on handling (multi-copy) external hosts for domain transfer,
and
(2) Single-copy vs. multi-copy for external host objects

In this email, I would like to address (1). I will change the thread to more
accurately reflect the discussion in a follow-up email.

For completeness, let me quote the paragraph in epp domain -05 again:

"DNS domains can be delegated to external hosts. If a domain has been
delegated to an external host, a client MUST have created a host object for
each delegation to an external host before requesting a domain transfer. A
transfer request or approval MUST fail with EPP error code 2305 if host
objects representing the external hosts are not managed by the requesting
client at the time a transfer request is made and at the time the transfer
request is approved."

The main problem I have is with the last sentence "...MUST fail...if...are
not managed by the requesting client...". Maybe the better wording would be:

"A transfer request or approval MUST fail with EPP error code 2305 if host
objects representing the external hosts _do not exist_ for the requesting
client at the time a transfer request is made and at the time the transfer
request is approved."

Then add the following sentence:

"If the appropriate external hosts exist at the time of a transfer approve
or transfer auto-approve, then the registry SHOULD update the external host
references for the domain from the losing registrar to the gaining registrar
at the same time the pendingTransfer status is removed and the sponsoring
registrar is changed."

Thoughts?

--Hong

-----Original Message-----
From: Gould, James [<a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</a>]
Sent: Wednesday, October 30, 2002 9:13 AM
To: '<a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>'; 'Liu, Hong'
Subject: RE: Handling of External Host Objects (in the context of domain
t ransfer) 


Hong,

[snip]
  </pre>
  <pre wrap=""><!---->As far as domain transfers are related to external hosts, additional
validation checks can be built into the registry to ensure that the
requesting registrar has the appropriate external hosts on a transfer
request, transfer approve, or transfer auto-approve.  If the appropriate
external hosts exist at the time of a transfer approve or transfer
auto-approve, than the registry can update the external host references from
the domain at the same time the pendingTransfer status is removed and the
sponsoring registrar is changed.   If the appropriate external hosts do not
exist, than the transfer request, transfer approve or transfer auto-approve
will fail.  The EPP poll messages can be used to keep both the sponsoring
and requesting registrars informed throughout the transfer process.  

Jim

  </pre>
  <blockquote type="cite">
    <pre wrap="">----------
From: 	Liu, Hong
Sent: 	Tuesday, October 29, 2002 8:09 PM
To: 	'<a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>'
Subject: 	Re: Handling of External Host Objects (in the context of
domain t ransfer) 

Hi, Asbjorn,

Thanks for discussing this topic. This is my response to your posting [1].
For some reason, I did not get the posting directly from the mailer. I
just
found that out by looking throught the mail archive. The following
presenation is somewhat awkward since I have to quote your email.

Quote:
"I don't understand the first part here, why would the losing registrar
need
to delete the link to the external host before transfer? He would only
need
to go to the new registrar and create the external host there (if it is
not
already there), request the transfer, and the domain would automagically
swap to "using" the newly created external host when the transfer is
completed. The domain will resolve during the whole process."
Answer:
The paragraph I quoted from epp domain mapping is the following:
"DNS domains can be delegated to external hosts. If a domain has been
delegated to an external host, a client MUST have created a host object
for
each delegation to an external host before requesting a domain transfer. A
transfer request or approval MUST fail with EPP error code 2305 if host
objects representing the external hosts are not managed by the requesting
client at the time a transfer request is made and at the time the transfer
request is approved."
So in my previous email, 2(a) is the result of the last sentence, while
2(b)
is the restatement of the second sentence. The main problem is with 2(a).
What is your read on the last sentence above?
    </pre>
  </blockquote>
  <pre wrap=""><!---->[snip]
  </pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="$mailwrapcol">-- 
Daniel Manley
Tucows, Inc.
Toronto, Canada
<a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
</pre>
<br>
</body>
</html>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAEGD9cE022195 for <[e-mail]>; Thu, 14 Nov 2002 17:13:09 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gAEGD9Wl022194 for ietf-provreg-outgoing; Thu, 14 Nov 2002 17:13:09 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from felix.automagic.org (felix.automagic.org [204.152.186.101]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gAEGD7cE022189 for <[e-mail]>; Thu, 14 Nov 2002 17:13:08 +0100 (MET)
Received: (qmail 11650 invoked by uid 0); 14 Nov 2002 16:13:05 -0000
Received: from localhost.automagic.org (HELO isc.org) (127.0.0.1) by localhost.automagic.org with SMTP; 14 Nov 2002 16:13:05 -0000
Date: Thu, 14 Nov 2002 11:13:02 -0500
Subject: Re: format of contents of <domain:curExpDate>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v548)
Cc: [e-mail]
To: "Hollenbeck, Scott" <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.548)
Sender: [e-mail]
Precedence: bulk

On Thursday, Nov 14, 2002, at 08:56 Canada/Eastern, Hollenbeck, Scott 
wrote:

> You seem to be thinking that the value for this particular field is 
> one that
> needs to be either given to or retrieved from the registrant as part 
> of a
> renewal operation -- it doesn't.

Actually, I wasn't. I was thinking that it's a value that needs to be 
interpreted in precisely the same way by both registrar and registry, 
and was making the observation that the way in which the field should 
be interpreted is not currently communicated between client and server. 
Mention of the registrant was purely to illustrate that there are 
reasons for a registrar to interpret the data concerned in a localised 
fashion, in contexts other than <domain:renew>.

If the procedure you suggested (rip the date part out of a 
<domain:curExpDate>, in whatever timezone was specified in that data) 
is what you intended, then the draft needs to specify:

  (a) that procedure, and

  (b) that the time zone used in all situations where a server can 
return a <domain:exDate> must be consistent when sending responses to a 
single registrar.

Consider the following, in support of (b). Suppose a registry had EPP 
servers distributed geographically, in different time zones (one in 
Europe somewhere, one in the US maybe), and client connections to EPP 
servers were load-balanced in some fashion (round-robin DNS, anycast) 
or there was a capability of fail-over between sites. Suppose servers 
in each site returned date objects encoded in the local time zone, as 
is common practice in other protocols (SMTP "Received" headers, for 
example), and as is permitted by the EPP protocol.

It might be easily possible in that scenario for a client to receive a 
date specified in UTC-5 in response to one <domain:info> request, and 
to receive a date specified in UTC+2 in response to a subsequent one. 
Which timezone should be used when encoding a <domain:curExpDate>, in 
the case that you don't know which EPP server is going to handle the 
transaction?

This may sound like a wildly contrived example, but I seem to remember 
several of the ORG redelegation proposals specifying widely-flung 
geographic diversity in registry infrastructure. It doesn't seem like 
an unreasonable thing for a registry to do.

> That's why I said it was a nit.  It's got nothing to do with being
> insensitive to time zone differences.

It is certainly a minor point in the grand scheme of things, but I 
think it's more relevant than a nit.


Joe



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAEDuWcE020825 for <[e-mail]>; Thu, 14 Nov 2002 14:56:32 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gAEDuWcj020824 for ietf-provreg-outgoing; Thu, 14 Nov 2002 14:56:32 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAEDuVcE020819 for <[e-mail]>; Thu, 14 Nov 2002 14:56:31 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA25632; Thu, 14 Nov 2002 08:56:29 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <V5C2XNTN>; Thu, 14 Nov 2002 08:56:29 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Joe Abley'" <[e-mail]>
Cc: [e-mail]
Subject: RE: format of contents of <domain:curExpDate>
Date: Thu, 14 Nov 2002 08:56:16 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> I'm not seeing how this would increase opportunities for error, 
> although it's 8am here (I'm in Ontario now, but I'm still a 
> Kiwi :) and 
> the caffeine has yet to seep into the veins. If I'm missing 
> something, 
> please let me know.

You seem to be thinking that the value for this particular field is one that
needs to be either given to or retrieved from the registrant as part of a
renewal operation -- it doesn't.  It can be retrieved in UTC directly from
the registry with an <info> command, parsed, and copied into the parameters
list for the <renew> command with no explicit need to translate the value
into local time.  I offered that adding the time values is possible, but
it's not necessary to ensure that the command is idempotent -- the date
alone provides enough granularity for that.  Acquiring and exchanging
information that isn't necessary to complete an operation is where I see the
increased opportunity for error.

That's why I said it was a nit.  It's got nothing to do with being
insensitive to time zone differences.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAEDfLcE020734 for <[e-mail]>; Thu, 14 Nov 2002 14:41:21 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gAEDfLZo020733 for ietf-provreg-outgoing; Thu, 14 Nov 2002 14:41:21 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from felix.automagic.org (felix.automagic.org [204.152.186.101]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gAEDfJcE020728 for <[e-mail]>; Thu, 14 Nov 2002 14:41:19 +0100 (MET)
Received: (qmail 9836 invoked by uid 0); 14 Nov 2002 13:41:17 -0000
Received: from localhost.automagic.org (HELO isc.org) (127.0.0.1) by localhost.automagic.org with SMTP; 14 Nov 2002 13:41:17 -0000
Date: Thu, 14 Nov 2002 08:41:16 -0500
Subject: Re: format of contents of <domain:curExpDate>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v548)
Cc: [e-mail]
To: "Hollenbeck, Scott" <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.548)
Sender: [e-mail]
Precedence: bulk

On Thursday, Nov 14, 2002, at 07:24 Canada/Eastern, Hollenbeck, Scott 
wrote:

>> I can see how that would be the case if everybody in the
>> world lived in
>> the same time zone. It seems like it might cause friction otherwise,
>> however.
>
> This field isn't used for local interpretation purposes -- it's used 
> _only_
> to match the date as currently archived by the server.  We could 
> instead
> force a match on date, hours, minutes, seconds, and time zone, but that
> would seem to increase opportunities for error.

 From an implementation perspective it would be nice to have a single 
date format for use throughout the protocol, that we called regardless 
of which element we were parsing. That was my original reason for 
bringing it up.

> This is such a nit that I really don't care, though.  If anyone else 
> thinks
> that it would be better to use a full date-time value in this field, 
> please
> speak up.

This field *does* have a local interpretation, regardless of whether 
the protocol requires an interpretation to be made at the registrar.

Consider a registrar in New Zealand (UTC+12, UTC+13 in the southern 
summer) and a registry on the west coast of the US (UTC-8, UTC-7 in the 
northern summer). The date in New Zealand is usually (but not always) 
one day in advance of the date in California.

The NZ registrar will presumably have a local market of registrants, 
and it will communicate expiry dates to those registrants in a way that 
makes sense for New Zealanders.

Because of the requirement to interpret the renewal date in two 
timezones, complexity arises. The date has to be converted either from 
a locally-held value when talking to the registry, or from a 
registry-held value when talking to a registrant.

You could argue that the exact moment at which the expiry occurs is not 
relevant, since the registry probably operates a grace period which 
gives the required 1 day of flexibility, but that is an assumption 
about policy and would seem to be out-of-scope for a provisioning 
protocol document.

It seems to me that this is indeed an irritating nit as viewed from the 
perspective of one who rarely has to deal with other organisations in a 
different timezone where the date is different. However, having lived 
in New Zealand and worked with a lot of people in California while I 
was there, this kind of ambiguity arises all the time and usually 
requires annoying kludge-coding to attempt to approximate real-life 
practice when functional specifications don't specify what MUST happen. 
I would be very surprised if this is a problem that is unique to New 
Zealand, although given its time zone it is probably more of a problem 
there than elsewhere.

Specifying a full time instead of a date seems to me like it would 
avoid a problem, and would make implementation easier.

I'm not seeing how this would increase opportunities for error, 
although it's 8am here (I'm in Ontario now, but I'm still a Kiwi :) and 
the caffeine has yet to seep into the veins. If I'm missing something, 
please let me know.


Joe



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAECx0cE020387 for <[e-mail]>; Thu, 14 Nov 2002 13:59:00 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gAECx0DB020386 for ietf-provreg-outgoing; Thu, 14 Nov 2002 13:59:00 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mx01.gnr.com (mx01.gnr.com [193.109.220.157]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gAECwwcE020381 for <[e-mail]>; Thu, 14 Nov 2002 13:58:58 +0100 (MET)
Received: (qmail 477 invoked by alias); 14 Nov 2002 12:58:57 -0000
Received: from unknown (HELO gnr-mailsweeper.gnr.com) (213.105.192.220) by muk-gnrmx-01.gnr.com with SMTP; 14 Nov 2002 12:58:57 -0000
Received: from gnr-exch01.gnr.com (unverified) by gnr-mailsweeper.gnr.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 14 Nov 2002 13:03:30 +0000
Received: from gnr.com ([192.168.3.23]) by gnr-exch01.gnr.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 14 Nov 2002 12:55:12 +0000
Message-ID: <[e-mail]>
Date: Thu, 14 Nov 2002 13:57:34 +0000
From: Asbjorn Steira <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: format of contents of <domain:curExpDate>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Nov 2002 12:55:12.0804 (UTC) FILETIME=[1221E640:01C28BDD]
Sender: [e-mail]
Precedence: bulk

Hollenbeck, Scott wrote:

> This is such a nit that I really don't care, though.  If anyone else 
> thinks that it would be better to use a full date-time value in this 
> field, please speak up.

I think we should just leave it as it is.

Asbjorn

-- 
Asbjorn Steira
The Global Name Registry, Limited



Information contained herein is Global Name Registry Proprietary Information and is made available to you because of your interest in our company.    This information is submitted in confidence and its disclosure to you is not intended to constitute public disclosure or authorization for disclosure to other parties.
*****************
What's your .name?
Get one at www.name
*****************



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAECPDcE020058 for <[e-mail]>; Thu, 14 Nov 2002 13:25:13 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gAECPDJ0020057 for ietf-provreg-outgoing; Thu, 14 Nov 2002 13:25:13 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAECPCcE020052 for <[e-mail]>; Thu, 14 Nov 2002 13:25:12 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA23138; Thu, 14 Nov 2002 07:25:09 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <V5C2XLT8>; Thu, 14 Nov 2002 07:25:09 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Joe Abley'" <[e-mail]>
Cc: [e-mail]
Subject: RE: format of contents of <domain:curExpDate>
Date: Thu, 14 Nov 2002 07:24:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> I can see how that would be the case if everybody in the 
> world lived in 
> the same time zone. It seems like it might cause friction otherwise, 
> however.

This field isn't used for local interpretation purposes -- it's used _only_
to match the date as currently archived by the server.  We could instead
force a match on date, hours, minutes, seconds, and time zone, but that
would seem to increase opportunities for error.

This is such a nit that I really don't care, though.  If anyone else thinks
that it would be better to use a full date-time value in this field, please
speak up.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gAE4WacE017201 for <[e-mail]>; Thu, 14 Nov 2002 05:32:36 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gAE4WZ0M017200 for ietf-provreg-outgoing; Thu, 14 Nov 2002 05:32:35 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from felix.automagic.org (felix.automagic.org [204.152.186.101]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gAE4WYcE017195 for <[e-mail]>; Thu, 14 Nov 2002 05:32:34 +0100 (MET)
Received: (qmail 30149 invoked by uid 0); 14 Nov 2002 04:32:32 -0000
Received: from localhost.automagic.org (HELO isc.org) (127.0.0.1) by localhost.automagic.org with SMTP; 14 Nov 2002 04:32:32 -0000
Date: Wed, 13 Nov 2002 23:32:29 -0500
Subject: Re: format of contents of <domain:curExpDate>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v548)
Cc: [e-mail]
To: "Hollenbeck, Scott" <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.548)
Sender: [e-mail]
Precedence: bulk

On Thursday, Nov 7, 2002, at 18:15 Canada/Eastern, Hollenbeck, Scott 
wrote:

>>>> Whatever the format turns out to be, it would be a good thing if the
>>>> nature of the contents of <domain:curExpDate> could be clearly
>>>> specified in the domain mapping document.
>>>
>>> "date" is a built-in XML Schema data type.  XML Schema is a normative
>>> reference.  The XML Schema specifications describe the format quite
>>> clearly.
>>
>> Thanks, that does indeed clear it up.
>>
>> Just out of interest, why was it decided to use "date" in
>> <domain:curExpDate>, rather than "dateTime" as used in (e.g.)
>> <domain:qDate> and <host:trDate>?
>
> Because the date alone provided the needed granularity without having 
> to get
> into hours, minutes, or seconds.

I can see how that would be the case if everybody in the world lived in 
the same time zone. It seems like it might cause friction otherwise, 
however.


Joe



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gACCq3cE025054 for <[e-mail]>; Tue, 12 Nov 2002 13:52:03 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gACCq3CK025053 for ietf-provreg-outgoing; Tue, 12 Nov 2002 13:52:03 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gACCq1cE025048 for <[e-mail]>; Tue, 12 Nov 2002 13:52:01 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA13473; Tue, 12 Nov 2002 07:52:00 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <V87JZ6J6>; Tue, 12 Nov 2002 07:47:41 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Stephane Bortzmeyer'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Is is mandatory for an object to belong to a registrar?
Date: Tue, 12 Nov 2002 07:51:50 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> > The model is one where objects are managed by some client.  
> If you're asking
> > if the <contact:clID> is optional in an <info> response, 
> it's not.  If
> > you're suggesting that it should be, I would disagree.  
> Someone or something
> > has to be the authoritative management agent for an object.
> 
> This is not how all registries work at the present time. For instance,
> in the RIPE-NCC database (an address registry for Europe/MiddleEast),
> every object can have 1 to N "maintainers" and every maintainer has
> full rights over the object. This is very convenient because it
> allows, for instance, a network provider to add its client and itself
> as maintainers of contact objects: each one can make a change of, for
> instance, a phone number.
> 
> True, an object is created by some client but it can be modified by
> several "actors".
> 
> Now, if the RIPE-NCC wants to use the EPP contact mapping, what will
> they put as clID? (The crID will be the creator, a LIR - Local
> Internet Registry, typically a network provider.)=

It would be helpful if you read and quoted the last part of my previous
message -- you can use the server/registry as the "client" if it allows
multiple actors to maintain an object.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gACCZbcE024789 for <[e-mail]>; Tue, 12 Nov 2002 13:35:37 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gACCZbul024788 for ietf-provreg-outgoing; Tue, 12 Nov 2002 13:35:37 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gACCZacE024783 for <[e-mail]>; Tue, 12 Nov 2002 13:35:36 +0100 (MET)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id gACCZZhA861569; Tue, 12 Nov 2002 13:35:35 +0100 (CET)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id 817EC10D2B; Tue, 12 Nov 2002 13:35:35 +0100 (CET)
Date: Tue, 12 Nov 2002 13:35:35 +0100
From: "'Stephane Bortzmeyer'" <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
Cc: "'Stephane Bortzmeyer'" <[e-mail]>, [e-mail]
Subject: Re: Is is mandatory for an object to belong to a registrar?
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.28i
X-Operating-System: Debian GNU/Linux 3.0
X-Kernel: Linux 2.4.18-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
Sender: [e-mail]
Precedence: bulk

On Tue, Nov 12, 2002 at 07:27:53AM -0500,
 Hollenbeck, Scott <[e-mail]> wrote 
 a message of 57 lines which said:

> The model is one where objects are managed by some client.  If you're asking
> if the <contact:clID> is optional in an <info> response, it's not.  If
> you're suggesting that it should be, I would disagree.  Someone or something
> has to be the authoritative management agent for an object.

This is not how all registries work at the present time. For instance,
in the RIPE-NCC database (an address registry for Europe/MiddleEast),
every object can have 1 to N "maintainers" and every maintainer has
full rights over the object. This is very convenient because it
allows, for instance, a network provider to add its client and itself
as maintainers of contact objects: each one can make a change of, for
instance, a phone number.

True, an object is created by some client but it can be modified by
several "actors".

Now, if the RIPE-NCC wants to use the EPP contact mapping, what will
they put as clID? (The crID will be the creator, a LIR - Local
Internet Registry, typically a network provider.)


 



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gACCS6cE024698 for <[e-mail]>; Tue, 12 Nov 2002 13:28:06 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gACCS6Wv024697 for ietf-provreg-outgoing; Tue, 12 Nov 2002 13:28:06 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gACCS4cE024692 for <[e-mail]>; Tue, 12 Nov 2002 13:28:04 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA13086; Tue, 12 Nov 2002 07:28:01 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <V87JZ50Q>; Tue, 12 Nov 2002 07:23:43 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Stephane Bortzmeyer'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Is is mandatory for an object to belong to a registrar?
Date: Tue, 12 Nov 2002 07:27:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: 'Stephane Bortzmeyer' [mailto:[e-mail]]
> Sent: Tuesday, November 12, 2002 5:01 AM
> To: Hollenbeck, Scott
> Cc: 'Stephane Bortzmeyer'; [e-mail]
> Subject: Re: Is is mandatory for an object to belong to a registrar?
> 
> 
> On Fri, Nov 08, 2002 at 08:44:06AM -0500,
>  Hollenbeck, Scott <[e-mail]> wrote 
>  a message of 29 lines which said:
> 
> > I deliberately tried to stay away from the concept of ownership 
> 
> OK, but replace "owner" and "owns" in my message by "sponsor" and
> "sponsors" and I have the same concern. If I want to implement a
> registry where contacts are not owned/sponsored/managed by registrars,
> is it possible with EPP?

I also don't use the term "registrar" anywhere in the documents.  "Client"
is used instead, and a client can be anything that talks to the server.

> > "manage", etc. seemed like more neutral terms.  I don't 
> think you'll find a
> > single use of the word "own" to describe the client-object 
> relationship in
> > the specs 
> 
> Right, but not the point.

Sorry, but I think it's very relevent.  You suggested that registrars "own"
objects, and I'm saying that they don't.

> > The answer to your question is "yes".  The current protocol 
> specifications
> > allow implementation of a model where contacts can not be 
> transferred.
> 
> I was more specific: a model where contacts are not tied to a
> registrar. For instance, <info> should not mandate:
> 
>   - A <contact:clID> element that contains the identifier of the
>   sponsoring client.
> 
> (There is a <contact:crID> element if you want historical information
> about who created a contact.)

The model is one where objects are managed by some client.  If you're asking
if the <contact:clID> is optional in an <info> response, it's not.  If
you're suggesting that it should be, I would disagree.  Someone or something
has to be the authoritative management agent for an object.

Now, if you're asking if that agent has to be a registrar the answer is
"no".  One might develop a model where the agent is the server (or a
registry operator to use the registry-registrar terms you've used) itself.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gACA0ucE023469 for <[e-mail]>; Tue, 12 Nov 2002 11:00:56 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gACA0u7n023468 for ietf-provreg-outgoing; Tue, 12 Nov 2002 11:00:56 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gACA0tcE023463 for <[e-mail]>; Tue, 12 Nov 2002 11:00:55 +0100 (MET)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id gACA0s7I1503821; Tue, 12 Nov 2002 11:00:55 +0100 (CET)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id 6F06610D2B; Tue, 12 Nov 2002 11:00:54 +0100 (CET)
Date: Tue, 12 Nov 2002 11:00:54 +0100
From: "'Stephane Bortzmeyer'" <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
Cc: "'Stephane Bortzmeyer'" <[e-mail]>, [e-mail]
Subject: Re: Is is mandatory for an object to belong to a registrar?
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.28i
X-Operating-System: Debian GNU/Linux 3.0
X-Kernel: Linux 2.4.18-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
Sender: [e-mail]
Precedence: bulk

On Fri, Nov 08, 2002 at 08:44:06AM -0500,
 Hollenbeck, Scott <[e-mail]> wrote 
 a message of 29 lines which said:

> I deliberately tried to stay away from the concept of ownership 

OK, but replace "owner" and "owns" in my message by "sponsor" and
"sponsors" and I have the same concern. If I want to implement a
registry where contacts are not owned/sponsored/managed by registrars,
is it possible with EPP?

> "manage", etc. seemed like more neutral terms.  I don't think you'll find a
> single use of the word "own" to describe the client-object relationship in
> the specs 

Right, but not the point.

> The answer to your question is "yes".  The current protocol specifications
> allow implementation of a model where contacts can not be transferred.

I was more specific: a model where contacts are not tied to a
registrar. For instance, <info> should not mandate:

  - A <contact:clID> element that contains the identifier of the
  sponsoring client.

(There is a <contact:crID> element if you want historical information
about who created a contact.)



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA8NgmcE021857 for <[e-mail]>; Sat, 9 Nov 2002 00:42:48 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gA8NgmiX021856 for ietf-provreg-outgoing; Sat, 9 Nov 2002 00:42:48 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA8NglcE021851 for <[e-mail]>; Sat, 9 Nov 2002 00:42:47 +0100 (MET)
Received: from user-2ivelj3.dialup.mindspring.com ([165.247.86.99] helo=dick.ix.netcom.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 18AIlw-0003RB-00; Fri, 08 Nov 2002 18:42:44 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 08 Nov 2002 12:17:39 -0500
To: Edward Lewis <[e-mail]>
From: Richard Shockey <[e-mail]>
Subject: RE: proposed agenda
Cc: [e-mail]
In-Reply-To: <a05111b01b9f174c976c3@[192.149.252.234]>
References: <[e-mail]> < <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

At 09:07 AM 11/8/2002 -0500, you wrote:
>At 17:43 -0500 11/7/02, Richard Shockey wrote:
>>I'm assuming you are considering using Eric ID as the basis for the Privacy
>>Discussions? Right?
>
>Well, it's a discussion point.  Honestly it's the one provreg related 
>draft I've had time to read, so I can't go further than that.  But since 
>we are going to be discussing privacy in general, I think it'll be included.
>
>...Providing someone is able to speak to it.  I understand Eric may not be 
>there in person.

Well I might be able to help Eric if doesnt mind and address some of the 
issues here. I'm certainly hearing it on my side of the street.

I'm nearly convinced that this or something like it is a requirement for 
provreg to incorporate in its objects and I know the AD's are increasingly 
focusing their attention on privacy related issues involving data 
collection and that is what provreg is about.

This is important to me since we have ample evidence many national ENUM 
administrations will look to provreg protocols as a base line for provisioning.

I'd also like to call to the attention of the list the upcoming W3C 
workshop on privacy issues and the future of P3P.

http://www.w3.org/2002/p3p-ws/

Any one who thinks these privacy issues are going to go away is putting 
their head in the sand....I'd suggest to the WG that its time to step up to 
the plate and "do the right thing"


>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-brunner-epp-data-considerations-00.txt
>
>
>Thanks.  In my haste to get the agenda to the proper authorities, I didn't 
>look hard enough for this URL.
>--
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Edward Lewis                                          [phone]
>ARIN Research Engineer


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: [phone]
<mailto:[e-mail]> or <mailto:[e-mail]>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA8EIicE016216 for <[e-mail]>; Fri, 8 Nov 2002 15:18:44 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gA8EIij2016215 for ietf-provreg-outgoing; Fri, 8 Nov 2002 15:18:44 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA8EIgcE016210 for <[e-mail]>; Fri, 8 Nov 2002 15:18:42 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gA8EIfYm051519; Fri, 8 Nov 2002 09:18:42 -0500 (EST)
Received: from [192.149.252.234] ([192.149.252.234]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA00858; Fri, 8 Nov 2002 09:18:40 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@ops
Message-Id: <a05111b01b9f174c976c3@[192.149.252.234]>
In-Reply-To: <[e-mail]>
References: < <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 8 Nov 2002 09:07:13 -0500
To: Richard Shockey <[e-mail]>, Edward Lewis <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: RE: proposed agenda
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 17:43 -0500 11/7/02, Richard Shockey wrote:
>I'm assuming you are considering using Eric ID as the basis for the Privacy
>Discussions? Right?

Well, it's a discussion point.  Honestly it's the one provreg related 
draft I've had time to read, so I can't go further than that.  But 
since we are going to be discussing privacy in general, I think it'll 
be included.

...Providing someone is able to speak to it.  I understand Eric may 
not be there in person.

>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-brunner-epp-data-considerations-00.txt


Thanks.  In my haste to get the agenda to the proper authorities, I 
didn't look hard enough for this URL.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA8DiGcE015864 for <[e-mail]>; Fri, 8 Nov 2002 14:44:16 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gA8DiGCH015863 for ietf-provreg-outgoing; Fri, 8 Nov 2002 14:44:16 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA8DiFcE015857 for <[e-mail]>; Fri, 8 Nov 2002 14:44:15 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA27340; Fri, 8 Nov 2002 08:44:13 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <V5C2SMST>; Fri, 8 Nov 2002 08:44:12 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Stephane Bortzmeyer'" <[e-mail]>, [e-mail]
Subject: RE: Is is mandatory for an object to belong to a registrar?
Date: Fri, 8 Nov 2002 08:44:06 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> I suspect that the question is stupid but I nevertheless would like to
> clarify things in my mind.
> 
> A colleague of me objected to EPP that EPP "mandates all objects to
> belong to a registrar (the creator)". Of course, this should be a
> local policy: most registries do not bill for contact creation, only
> for domain creation, so there is no "hard" reason to make contacts a
> property of registrars. But the issue is: is it allowed with EPP?
> 
> I believe that yes. A registry can always set a
> clientTransferProhibited for all objects and/or can always reply with
> 2306 to every <transfer> of a contact. (Wether the current EPP
> implementations allow it is another matter...)
> 
> But I wanted to be sure: a registry where contacts are *not* owned by
> registrars (and therefore not transferrable) can use EPP and the
> current mappings, yes or no?

I deliberately tried to stay away from the concept of ownership when
describing the client-object relationship -- there are too many legal
meanings and personal perceptions attached to "ownership".  "Sponsor",
"manage", etc. seemed like more neutral terms.  I don't think you'll find a
single use of the word "own" to describe the client-object relationship in
the specs -- if you do, I'd like to know about it so it can be changed.

The answer to your question is "yes".  The current protocol specifications
allow implementation of a model where contacts can not be transferred.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA8D4JcE015372 for <[e-mail]>; Fri, 8 Nov 2002 14:04:19 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gA8D4J1N015371 for ietf-provreg-outgoing; Fri, 8 Nov 2002 14:04:19 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA8D4IcE015364 for <[e-mail]>; Fri, 8 Nov 2002 14:04:18 +0100 (MET)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id gA8D4IhA1018382 for <[e-mail]>; Fri, 8 Nov 2002 14:04:18 +0100 (CET)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id E0FF210D2B; Fri,  8 Nov 2002 14:04:17 +0100 (CET)
Date: Fri, 8 Nov 2002 14:04:17 +0100
From: Stephane Bortzmeyer <[e-mail]>
To: [e-mail]
Subject: Is is mandatory for an object to belong to a registrar?
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
X-Operating-System: Debian GNU/Linux 3.0
X-Kernel: Linux 2.4.18-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
Sender: [e-mail]
Precedence: bulk

I suspect that the question is stupid but I nevertheless would like to
clarify things in my mind.

A colleague of me objected to EPP that EPP "mandates all objects to
belong to a registrar (the creator)". Of course, this should be a
local policy: most registries do not bill for contact creation, only
for domain creation, so there is no "hard" reason to make contacts a
property of registrars. But the issue is: is it allowed with EPP?

I believe that yes. A registry can always set a
clientTransferProhibited for all objects and/or can always reply with
2306 to every <transfer> of a contact. (Wether the current EPP
implementations allow it is another matter...)

But I wanted to be sure: a registry where contacts are *not* owned by
registrars (and therefore not transferrable) can use EPP and the
current mappings, yes or no?


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA83eccE011018 for <[e-mail]>; Fri, 8 Nov 2002 04:40:38 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gA83eboO011017 for ietf-provreg-outgoing; Fri, 8 Nov 2002 04:40:37 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA83eacE011012 for <[e-mail]>; Fri, 8 Nov 2002 04:40:37 +0100 (MET)
Received: from user-2iver8r.dialup.mindspring.com ([165.247.109.27] helo=dick.ix.netcom.com) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 18A00W-0004yj-00; Thu, 07 Nov 2002 22:40:33 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 07 Nov 2002 22:41:12 -0500
To: Edward Lewis <[e-mail]>
From: Richard Shockey <[e-mail]>
Subject: RE: proposed agenda
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

apologies if this shows up twice... from time to time I have to use 
different email addresses.


>>>         IESG comments:
>>>
>>>  http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00023.html
>>>  http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00114.html
>>>
>>>         Congestion control 15 mins.
>>>         Reliability        15 mins.
>>>         Privacy
>>>            Intro           10 mins. (Setting the "tone")
>>>            Text fr. Scott  20 mins.
>>>  http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00041.html
>>>
>>>            Text fr. Eric   20 mins. (I haven't retrieved and
>>>  read his ref. yet.)
>>>  see: http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00094.html

I'm assuming you are considering using Eric ID as the basis for the Privacy 
Discussions? Right?

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-brunner-epp-data-considerations-00.txt

I'm increasingly interested in the direction this may take since it may 
have implications for ENUM provisioning in the future.



 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: [phone]
<mailto:[e-mail]> or <mailto:[e-mail]>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA7NG8cE007969 for <[e-mail]>; Fri, 8 Nov 2002 00:16:08 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gA7NG8Jx007968 for ietf-provreg-outgoing; Fri, 8 Nov 2002 00:16:08 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA7NG6cE007960 for <[e-mail]>; Fri, 8 Nov 2002 00:16:06 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id SAA07630; Thu, 7 Nov 2002 18:16:04 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <V5C2R7N2>; Thu, 7 Nov 2002 18:16:04 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Joe Abley'" <[e-mail]>
Cc: [e-mail]
Subject: RE: format of contents of <domain:curExpDate>
Date: Thu, 7 Nov 2002 18:15:54 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> >> Whatever the format turns out to be, it would be a good 
> thing if the
> >> nature of the contents of <domain:curExpDate> could be clearly
> >> specified in the domain mapping document.
> >
> > "date" is a built-in XML Schema data type.  XML Schema is a 
> normative
> > reference.  The XML Schema specifications describe the format quite 
> > clearly.
> 
> Thanks, that does indeed clear it up.
> 
> Just out of interest, why was it decided to use "date" in 
> <domain:curExpDate>, rather than "dateTime" as used in (e.g.) 
> <domain:qDate> and <host:trDate>?

Because the date alone provided the needed granularity without having to get
into hours, minutes, or seconds.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA7MawcE007552 for <[e-mail]>; Thu, 7 Nov 2002 23:36:58 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gA7MawLX007551 for ietf-provreg-outgoing; Thu, 7 Nov 2002 23:36:58 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from felix.automagic.org (felix.automagic.org [204.152.186.101]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gA7MaucE007546 for <[e-mail]>; Thu, 7 Nov 2002 23:36:57 +0100 (MET)
Received: (qmail 18624 invoked by uid 0); 7 Nov 2002 22:36:55 -0000
Received: from localhost.automagic.org (HELO isc.org) (127.0.0.1) by localhost.automagic.org with SMTP; 7 Nov 2002 22:36:55 -0000
Date: Thu, 7 Nov 2002 17:36:33 -0500
Subject: Re: format of contents of <domain:curExpDate>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: [e-mail]
To: "Hollenbeck, Scott" <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
Sender: [e-mail]
Precedence: bulk

On Thursday, Nov 7, 2002, at 17:07 Canada/Eastern, Hollenbeck, Scott 
wrote:

>> Whatever the format turns out to be, it would be a good thing if the
>> nature of the contents of <domain:curExpDate> could be clearly
>> specified in the domain mapping document.
>
> "date" is a built-in XML Schema data type.  XML Schema is a normative
> reference.  The XML Schema specifications describe the format quite 
> clearly.

Thanks, that does indeed clear it up.

Just out of interest, why was it decided to use "date" in 
<domain:curExpDate>, rather than "dateTime" as used in (e.g.) 
<domain:qDate> and <host:trDate>?


Joe



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA7MEBcE007365 for <[e-mail]>; Thu, 7 Nov 2002 23:14:11 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gA7MEB4g007364 for ietf-provreg-outgoing; Thu, 7 Nov 2002 23:14:11 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA7MEAcE007359 for <[e-mail]>; Thu, 7 Nov 2002 23:14:10 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id RAA29754; Thu, 7 Nov 2002 17:14:08 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <V5C2RZQD>; Thu, 7 Nov 2002 17:07:04 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Joe Abley'" <[e-mail]>, [e-mail]
Subject: RE: format of contents of <domain:curExpDate>
Date: Thu, 7 Nov 2002 17:07:00 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> In draft-ietf-provreg-epp-domain-05, section 3.2.3 "EPP <renew> 
> Command", the required format of the characters within the 
> <domain:curExpDate> element is not specified.
> 
> The example which follows contains an element whose contents are 
> formatted as "YYYY-MM-DD", but no reference is made to this in the 
> text. The XML Schema defines the contents as "date", if I'm reading 
> that right, but "date" doesn't appear to be defined within 
> the schemas 
> presented in the EPP and domain mapping drafts, so that's not helping 
> me.
> 
> Elsewhere (e.g. in the <qDate> element described in 
> draft-ietf-provreg-epp-07) dates are required to be in 
> RFC3339 format.  
> It would seem to serve the cause of consistency if this 
> format was also 
> adopted for <domain:curExpDate>, perhaps with a requirement 
> for servers 
> to also support YYYY-MM-DD to accommodate deployed code based on 
> earlier drafts.
> 
> Whatever the format turns out to be, it would be a good thing if the 
> nature of the contents of <domain:curExpDate> could be clearly 
> specified in the domain mapping document.

"date" is a built-in XML Schema data type.  XML Schema is a normative
reference.  The XML Schema specifications describe the format quite clearly.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA7LhDcE007061 for <[e-mail]>; Thu, 7 Nov 2002 22:43:13 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gA7LhD9W007060 for ietf-provreg-outgoing; Thu, 7 Nov 2002 22:43:13 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA7LhCcE007049 for <[e-mail]>; Thu, 7 Nov 2002 22:43:12 +0100 (MET)
Received: from dev3.int.libertyrms.com ([10.1.2.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 189uQg-0001VH-00; Thu, 07 Nov 2002 16:43:10 -0500
Message-ID: <[e-mail]>
Date: Thu, 07 Nov 2002 16:49:16 -0500
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3custom i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Daniel Manley <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Handling of External Host Objects
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Dan,

having ability to do mass updates on external hosts is not a win-win solution
for registrars.
Registrars can avoid writing scripts to update domain objects. That's true.
>From the other hand they will have to implement additional steps and exception
handling for domain transfer process.
The process, even without dealing with external hosts issues, is already quite
complex.

Regards,

Janusz Sienkiewicz


Daniel Manley wrote:

> And from out of nowhere...  ;)
>
> Hollenbeck, Scott a écrit:
>
> ><snip>
> >
> >This solution does not allow object-based management of external hosts,
> >which means that renaming the external host would need to be done on a
> >per-name basis.  It may address the other issues that people have talked
> >about on this thread, though.
> >
> I see how this could resolve/avoid a lot of potential problems
> (transfers, ownership, etc), but with these new gTLDs, I would guess
> that the majority of nameservers in use are non-authoritative to the
> registries, so registrars would lose the ability to do mass updates as
> with nameservers as objects.  I don't think I would want to give this
> up.  As a registrar, I would have to write scripts to perform mass
> updates, taking up processing time on both the client and the server
> systems.
>
> >
> >I know this means that a domain can be associated with hosts as objects and
> >host as attributes and some people think that's inconsistent.  I don't think
> >it is if you agree with the first point above.
> >
> >-Scott-
> >
> >
>
> --
> Daniel Manley
> Tucows, Inc.
> Toronto, Canada
> [e-mail]



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA7KEmcE005900 for <[e-mail]>; Thu, 7 Nov 2002 21:14:48 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gA7KEmYA005899 for ietf-provreg-outgoing; Thu, 7 Nov 2002 21:14:48 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA7KEkcE005894; Thu, 7 Nov 2002 21:14:46 +0100 (MET)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST)
Message-Id: <[e-mail]>
From: The IESG <[e-mail]>
To: All IETF Working Groups: ;
Subject: Note Well Statement
x-msg: NoteWell
Date: Thu, 07 Nov 2002 15:11:40 -0500
Sender: [e-mail]
Precedence: bulk

>From time to time, especially just before a meeting, this statement is to
be sent to each and every IETF working group mailing list.
===========================================================================

				NOTE WELL

All statements related to the activities of the IETF and addressed to the
IETF are subject to all provisions of Section 10 of RFC 2026, which grants
to the IETF and its participants certain licenses and rights in such
statements.

Such statements include verbal statements in IETF meetings, as well as
written and electronic communications made at any time or place, which are
addressed to

    - the IETF plenary session,
    - any IETF working group or portion thereof,
    - the IESG, or any member thereof on behalf of the IESG,
    - the IAB or any member thereof on behalf of the IAB,
    - any IETF mailing list, including the IETF list itself,
      any working group or design team list, or any other list
      functioning under IETF auspices,
    - the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other function,
that are clearly not intended to be input to an IETF activity, group or
function, are not subject to these provisions.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA7JrDcE005572 for <[e-mail]>; Thu, 7 Nov 2002 20:53:13 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gA7JrCv2005571 for ietf-provreg-outgoing; Thu, 7 Nov 2002 20:53:12 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from felix.automagic.org (felix.automagic.org [204.152.186.101]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gA7JrAcE005565 for <[e-mail]>; Thu, 7 Nov 2002 20:53:11 +0100 (MET)
Received: (qmail 11806 invoked by uid 0); 7 Nov 2002 19:53:07 -0000
Received: from localhost.automagic.org (HELO isc.org) (127.0.0.1) by localhost.automagic.org with SMTP; 7 Nov 2002 19:53:07 -0000
Date: Thu, 7 Nov 2002 14:52:44 -0500
Mime-Version: 1.0 (Apple Message framework v546)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: format of contents of <domain:curExpDate>
From: Joe Abley <[e-mail]>
To: [e-mail]
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
X-Mailer: Apple Mail (2.546)
Sender: [e-mail]
Precedence: bulk

Hi,

In draft-ietf-provreg-epp-domain-05, section 3.2.3 "EPP <renew> 
Command", the required format of the characters within the 
<domain:curExpDate> element is not specified.

The example which follows contains an element whose contents are 
formatted as "YYYY-MM-DD", but no reference is made to this in the 
text. The XML Schema defines the contents as "date", if I'm reading 
that right, but "date" doesn't appear to be defined within the schemas 
presented in the EPP and domain mapping drafts, so that's not helping 
me.

Elsewhere (e.g. in the <qDate> element described in 
draft-ietf-provreg-epp-07) dates are required to be in RFC3339 format.  
It would seem to serve the cause of consistency if this format was also 
adopted for <domain:curExpDate>, perhaps with a requirement for servers 
to also support YYYY-MM-DD to accommodate deployed code based on 
earlier drafts.

Whatever the format turns out to be, it would be a good thing if the 
nature of the contents of <domain:curExpDate> could be clearly 
specified in the domain mapping document.


Joe



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA70edcE023960 for <[e-mail]>; Thu, 7 Nov 2002 01:40:39 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gA70edAk023959 for ietf-provreg-outgoing; Thu, 7 Nov 2002 01:40:39 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA70ebcE023954 for <[e-mail]>; Thu, 7 Nov 2002 01:40:38 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id TAA11584; Wed, 6 Nov 2002 19:40:35 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <V5C2Q79Q>; Wed, 6 Nov 2002 19:40:35 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Daniel Manley'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Handling of External Host Objects
Date: Wed, 6 Nov 2002 19:40:35 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> >This solution does not allow object-based management of 
> external hosts,
> >which means that renaming the external host would need to be 
> done on a
> >per-name basis.  It may address the other issues that people 
> have talked
> >about on this thread, though.
> >
> I see how this could resolve/avoid a lot of potential problems 
> (transfers, ownership, etc), but with these new gTLDs, I would guess 
> that the majority of nameservers in use are non-authoritative to the 
> registries, so registrars would lose the ability to do mass 
> updates as 
> with nameservers as objects.  I don't think I would want to give this 
> up.  As a registrar, I would have to write scripts to perform mass 
> updates, taking up processing time on both the client and the server 
> systems.

Which puts us right back where we started with this discussion... ;-)

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA70KOcE023787 for <[e-mail]>; Thu, 7 Nov 2002 01:20:24 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gA70KOWs023786 for ietf-provreg-outgoing; Thu, 7 Nov 2002 01:20:24 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from toronto.mail.tucows.com (toronto.mail.tucows.com [207.136.98.42]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA70KMcE023781 for <[e-mail]>; Thu, 7 Nov 2002 01:20:23 +0100 (MET)
Received: from dmanley.pc.internal.tucows.com ([10.0.10.19] helo=tucows.com) by toronto.mail.tucows.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.36 #3) id 189aPF-0004gI-00; Wed, 06 Nov 2002 19:20:21 -0500
Message-ID: <[e-mail]>
Date: Wed, 06 Nov 2002 19:17:02 -0500
From: Daniel Manley <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.0.1) Gecko/20020918
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Handling of External Host Objects
References: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

And from out of nowhere...  ;)

Hollenbeck, Scott a écrit:

><snip>
>
>This solution does not allow object-based management of external hosts,
>which means that renaming the external host would need to be done on a
>per-name basis.  It may address the other issues that people have talked
>about on this thread, though.
>
I see how this could resolve/avoid a lot of potential problems 
(transfers, ownership, etc), but with these new gTLDs, I would guess 
that the majority of nameservers in use are non-authoritative to the 
registries, so registrars would lose the ability to do mass updates as 
with nameservers as objects.  I don't think I would want to give this 
up.  As a registrar, I would have to write scripts to perform mass 
updates, taking up processing time on both the client and the server 
systems.

>
>I know this means that a domain can be associated with hosts as objects and
>host as attributes and some people think that's inconsistent.  I don't think
>it is if you agree with the first point above.
>
>-Scott-
>  
>


-- 
Daniel Manley
Tucows, Inc.
Toronto, Canada
[e-mail]





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA6L0UcE021989 for <[e-mail]>; Wed, 6 Nov 2002 22:00:30 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gA6L0UDv021988 for ietf-provreg-outgoing; Wed, 6 Nov 2002 22:00:30 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA6L0TcE021983 for <[e-mail]>; Wed, 6 Nov 2002 22:00:29 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gA6L0SYm010009 for <[e-mail]>; Wed, 6 Nov 2002 16:00:28 -0500 (EST)
Received: from [192.149.252.234] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA00952; Wed, 6 Nov 2002 16:00:27 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b12b9ef31e9acfb@[192.149.252.234]>
Date: Wed, 6 Nov 2002 16:00:42 -0500
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: Fwd: improved provreg agenda
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Now with speaking assignments...

>Date: Tue, 5 Nov 2002 15:41:07 -0500
>To: [e-mail]
>From: Edward Lewis <[e-mail]>
>Subject: improved provreg agenda
>Cc: [e-mail], Edward Lewis <[e-mail]>
>Status:
>
>Provreg: Tuesday (Nov.19) 0900-1130
>
>
>Document links where available are provided.  Archive links are 
>meant to refer to the posting plus all of the follow ups to it.
>
>1. Agenda bashing
>       5 mins.
>       I am counting on some bashing.
Me

>2. IESG issues with base
>       Congestion control 15 mins.
Scott (perhaps just a real short discussion after Allison's comments)

>       Reliability        15 mins.
Scott

>       Privacy
>          Intro           10 mins. (Setting the "tone")
Me (just to recap)

>          Text fr. Scott  20 mins.
Scott

>          Text fr. Eric   20 mins. (I haven't retrieved and read his ref. yet.)
Eric/Proxy (by permission)

>2.5 Other comments on the base
>       Last-verified      10 mins. (Rick Wesson)
Rick

>3. SOAP individ submission
Hong

>4. SMTP individ submission
Eric/Proxy (by permission)

>5. Extensions guidelines draft...
Scott (is there demand for a substantive review of this document?)

>6. Other topics
>       ? Implementation issues & reports
Anyone?

>       ? Next WG goal: interop testing (yeah, once we get RFC's & code)
Me
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA6KbkcE021795 for <[e-mail]>; Wed, 6 Nov 2002 21:37:46 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gA6KbkIJ021794 for ietf-provreg-outgoing; Wed, 6 Nov 2002 21:37:46 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA6KbjcE021789 for <[e-mail]>; Wed, 6 Nov 2002 21:37:46 +0100 (MET)
Received: from user-uiveq2f.dsl.mindspring.com ([165.247.104.79] helo=dick.ix.netcom.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 189Wvm-0001Qr-00; Wed, 06 Nov 2002 15:37:42 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 06 Nov 2002 15:37:13 -0500
To: [e-mail]
From: Richard Shockey <[e-mail]>
Subject: EC Directive on Privacy in the Electronics Communications Sector
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

Some relevance to ENUM - Provreg provisioning....

http://europa.eu.int/eur-lex/pri/en/oj/dat/2002/l_201/l_20120020731en00370047.pdf



 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: [phone]
<mailto:[e-mail]> or <mailto:[e-mail]>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA6GjncE019441 for <[e-mail]>; Wed, 6 Nov 2002 17:45:49 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gA6GjnXw019440 for ietf-provreg-outgoing; Wed, 6 Nov 2002 17:45:49 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA6GjfcE019435 for <[e-mail]>; Wed, 6 Nov 2002 17:45:41 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gA6GjcYm001074; Wed, 6 Nov 2002 11:45:38 -0500 (EST)
Received: from [192.149.252.234] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA18034; Wed, 6 Nov 2002 11:45:37 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b0cb9eef799025d@[192.149.252.234]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Wed, 6 Nov 2002 11:45:31 -0500
To: "Hollenbeck, Scott" <[e-mail]>, "'Edward Lewis'" <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: RE: proposed agenda
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Ah, yeah.  I'll have to get on that after the call I'm on.

At 11:43 -0500 11/6/02, Hollenbeck, Scott wrote:
>Ed,
>
>Who is the targeted speaker for each of these items?  I'm trying to figure
>out what I might need to prepare ahead of time.
>
>-Scott-
>
>>  -----Original Message-----
>>  From: Edward Lewis [mailto:[e-mail]]
>>  Sent: Monday, November 04, 2002 11:28 AM
>>  To: [e-mail]
>>  Cc: [e-mail]; Edward Lewis
>>  Subject: proposed agenda
>>
>>
>>  Provreg: Tuesday (Nov.19) 0900-1130
>>
>>
>>  Document links where available are provided.  Archive links are meant
>>  to refer to the posting plus all of the follow ups to it.
>>
>>  1. Agenda bashing
>>         5 mins.  (Don't hesitate to bring up issues to me or Jaap
>>  before we start)
>>         I am counting on some bashing.
>>
>>  2. IESG issues with base
>>
>>  http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-07.txt
>>  http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-con
>>  tact-05.txt
>>  http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-dom
>>  ain-05.txt
>>  http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-hos
>>  t-05.txt
>>  http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-05.txt
>>
>>         IESG comments:
>>
>>  http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00023.html
>>  http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00114.html
>>
>>         Congestion control 15 mins.
>>         Reliability        15 mins.
>>         Privacy
>>            Intro           10 mins. (Setting the "tone")
>>            Text fr. Scott  20 mins.
>>  http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00041.html
>>
>>            Text fr. Eric   20 mins. (I haven't retrieved and
>>  read his ref. yet.)
>>  see: http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00094.html
>>
>>  2.5 Other comments on the base
>>
>>  http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00074.html
>>
>>         Last-verified      10 mins. (Rick Wesson)
>>
>>  3. SOAP individ submission
>>
>>  http://www.ietf.org/internet-drafts/draft-liu-epp-soap-00.txt
>>         20 mins.
>>
>>  4. SMTP individ submission
>>
>>  http://www.ietf.org/internet-drafts/draft-brunner-epp-smtp-00.txt
>>
>>         20 mins.
>>
>>  5. Extensions guidelines draft...
>>
>>  http://www.cafax.se/internet-drafts/draft-ietf-provreg-epp-ext-00.txt
>>
>>         No discussion here, but I wanted to be sure the link
>>  is on the agenda
>>         0 mins pending the results of agenda bashing
>>
>>  6. Other topics
>>         ? Implementaion issues & reports
>>             (I know there are comments out there, waiting,
>>  begging to be made)
>>         ? Next WG goal: interop testing (yeah, once we get
>>  RFC's & code)
>>
>>  --
>>  -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>  Edward Lewis                                          [phone]
>>  ARIN Research Engineer
>>

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA6GhhcE019419 for <[e-mail]>; Wed, 6 Nov 2002 17:43:43 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gA6GhhCq019418 for ietf-provreg-outgoing; Wed, 6 Nov 2002 17:43:43 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA6GhfcE019413 for <[e-mail]>; Wed, 6 Nov 2002 17:43:42 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA14298; Wed, 6 Nov 2002 11:43:40 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <V87JWVV6>; Wed, 6 Nov 2002 11:39:35 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>
Cc: [e-mail]
Subject: RE: proposed agenda
Date: Wed, 6 Nov 2002 11:43:39 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Ed,

Who is the targeted speaker for each of these items?  I'm trying to figure
out what I might need to prepare ahead of time.

-Scott-

> -----Original Message-----
> From: Edward Lewis [mailto:[e-mail]]
> Sent: Monday, November 04, 2002 11:28 AM
> To: [e-mail]
> Cc: [e-mail]; Edward Lewis
> Subject: proposed agenda
> 
> 
> Provreg: Tuesday (Nov.19) 0900-1130
> 
> 
> Document links where available are provided.  Archive links are meant 
> to refer to the posting plus all of the follow ups to it.
> 
> 1. Agenda bashing
>        5 mins.  (Don't hesitate to bring up issues to me or Jaap 
> before we start)
>        I am counting on some bashing.
> 
> 2. IESG issues with base
> 
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-07.txt 
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-con
> tact-05.txt 
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-dom
> ain-05.txt 
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-hos
> t-05.txt 
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-05.txt
> 
>        IESG comments:
> 
> http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00023.html
> http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00114.html
> 
>        Congestion control 15 mins.
>        Reliability        15 mins.
>        Privacy
>           Intro           10 mins. (Setting the "tone")
>           Text fr. Scott  20 mins.
> http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00041.html
> 
>           Text fr. Eric   20 mins. (I haven't retrieved and 
> read his ref. yet.)
> see: http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00094.html
> 
> 2.5 Other comments on the base
> 
> http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00074.html
> 
>        Last-verified      10 mins. (Rick Wesson)
> 
> 3. SOAP individ submission
> 
> http://www.ietf.org/internet-drafts/draft-liu-epp-soap-00.txt
>        20 mins.
> 
> 4. SMTP individ submission
> 
> http://www.ietf.org/internet-drafts/draft-brunner-epp-smtp-00.txt
> 
>        20 mins.
> 
> 5. Extensions guidelines draft...
> 
> http://www.cafax.se/internet-drafts/draft-ietf-provreg-epp-ext-00.txt
> 
>        No discussion here, but I wanted to be sure the link 
> is on the agenda
>        0 mins pending the results of agenda bashing
> 
> 6. Other topics
>        ? Implementaion issues & reports
>            (I know there are comments out there, waiting, 
> begging to be made)
>        ? Next WG goal: interop testing (yeah, once we get 
> RFC's & code)
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                          [phone]
> ARIN Research Engineer
> 


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA4MppcE025397 for <[e-mail]>; Mon, 4 Nov 2002 23:51:51 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gA4Mpp4H025396 for ietf-provreg-outgoing; Mon, 4 Nov 2002 23:51:51 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA4MpncE025389 for <[e-mail]>; Mon, 4 Nov 2002 23:51:49 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gA4MpmYm054926 for <[e-mail]>; Mon, 4 Nov 2002 17:51:48 -0500 (EST)
Received: from [192.149.252.234] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA06687 for <[e-mail]>; Mon, 4 Nov 2002 17:51:44 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b09b9ecaa16beec@[192.149.252.234]>
Date: Mon, 4 Nov 2002 17:51:38 -0500
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: it's official
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Snipets from the "final" meeting agenda.

>To: IETF-Announce: ;
>From: [e-mail]
>Subject: 55th IETF Meeting Final Agenda
>Date: Mon, 04 Nov 2002 16:15:51 -0500

>Agenda of the Fifty-fifth IETF
>November 17-21, 2002

>TUESDAY, November 19, 2002
>0800-1800 IETF Registration - Imperial Registration Booth
>0800-0900 Continental Breakfast - Convention Level Foyer
>0900-1130 Morning Sessions
>Consulate       APP     provreg  Provisioning Registry Protocol WG
>Salon I         APP     xmpp     Extensible Messaging and Presence 
>Protocol BOF
>Salon III       INT     zerouter Zeroconf Router BOF
>Salon A         SEC     msec     Multicast Security WG
>Salon IV        SEC     secsh    Secure Shell WG
>Salon B         SUB     mpls     Multiprotocol Label Switching WG
>Salon II        TSV     avt      Audio/Video Transport WG

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA4GRhcE020672 for <[e-mail]>; Mon, 4 Nov 2002 17:27:43 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gA4GRhxU020671 for ietf-provreg-outgoing; Mon, 4 Nov 2002 17:27:43 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA4GRgcE020666 for <[e-mail]>; Mon, 4 Nov 2002 17:27:42 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gA4GRfYm042480; Mon, 4 Nov 2002 11:27:41 -0500 (EST)
Received: from [192.149.252.234] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA08386; Mon, 4 Nov 2002 11:27:40 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b00b9e9f2d38efe@[192.35.167.226]>
Date: Mon, 4 Nov 2002 11:27:48 -0500
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: proposed agenda
Cc: [e-mail], Edward Lewis <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Provreg: Tuesday (Nov.19) 0900-1130


Document links where available are provided.  Archive links are meant 
to refer to the posting plus all of the follow ups to it.

1. Agenda bashing
       5 mins.  (Don't hesitate to bring up issues to me or Jaap 
before we start)
       I am counting on some bashing.

2. IESG issues with base

http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-07.txt 
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-05.txt 
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-05.txt 
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-05.txt 
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-05.txt

       IESG comments:

http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00023.html
http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00114.html

       Congestion control 15 mins.
       Reliability        15 mins.
       Privacy
          Intro           10 mins. (Setting the "tone")
          Text fr. Scott  20 mins.
http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00041.html

          Text fr. Eric   20 mins. (I haven't retrieved and read his ref. yet.)
see: http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00094.html

2.5 Other comments on the base

http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00074.html

       Last-verified      10 mins. (Rick Wesson)

3. SOAP individ submission

http://www.ietf.org/internet-drafts/draft-liu-epp-soap-00.txt
       20 mins.

4. SMTP individ submission

http://www.ietf.org/internet-drafts/draft-brunner-epp-smtp-00.txt

       20 mins.

5. Extensions guidelines draft...

http://www.cafax.se/internet-drafts/draft-ietf-provreg-epp-ext-00.txt

       No discussion here, but I wanted to be sure the link is on the agenda
       0 mins pending the results of agenda bashing

6. Other topics
       ? Implementaion issues & reports
           (I know there are comments out there, waiting, begging to be made)
       ? Next WG goal: interop testing (yeah, once we get RFC's & code)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA4FOpcE019787 for <[e-mail]>; Mon, 4 Nov 2002 16:24:51 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gA4FOprE019786 for ietf-provreg-outgoing; Mon, 4 Nov 2002 16:24:51 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA4FOncE019775 for <[e-mail]>; Mon, 4 Nov 2002 16:24:50 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA27570; Mon, 4 Nov 2002 10:24:45 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <V5C233MA>; Mon, 4 Nov 2002 10:24:44 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'janusz sienkiewicz'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Handling of External Host Objects
Date: Mon, 4 Nov 2002 10:24:44 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> I assume that with the new external host approach domain 
> transfer process would
> be simplified. No error code 2305 for transfer requests and approvals.

It's premature to call what I wrote below "the new external host approach"
(it's still just a re-issue of a proposal that I'd like people to consider),
but yes, with this model there would be no need for object management errors
on transfers as currently described because there would be no need for the
per-registrar copies of external hosts.  An external host attribute would
just get carried along with all other domain object attributes.

-Scott-

> Regards,
> 
> Janusz Sienkiewicz
> 
> "Hollenbeck, Scott" wrote:
> 
> > One of the reasons I think that this external host thing 
> continues to be an
> > issue is because it's a kludge.  I firmly believe that the 
> only objects that
> > should exist in a repository are objects for which the repository is
> > authoritative.  Other needed data should exist as 
> attributes of existing
> > objects.
> >
> > I suggested this concept related to external hosts back 
> when the topic first
> > came up.  Some folks had issues with it, but I'll suggest 
> it again as an
> > alternative.  In a nutshell:
> >
> > - The only objects that should exist in a repository are 
> objects for which
> > the repository is authoritative.
> >
> > - Host objects should only be created in a repository that 
> is authoritative
> > for the host.  In the case of hosts as name servers, 
> "authoritative" means
> > that data in the repository (host name and address(es)) is 
> used to publish
> > DNS glue and the repository is the legitimate source for that data.
> >
> > - If an external host is needed for delegation purposes, it can be
> > associated with a domain object as an attribute of the 
> object with no host
> > object needed in advance.  There's no need to create an 
> external host object
> > ahead of time, no need to worry about IP addresses, etc.
> >
> > This solution does not allow object-based management of 
> external hosts,
> > which means that renaming the external host would need to 
> be done on a
> > per-name basis.  It may address the other issues that 
> people have talked
> > about on this thread, though.
> >
> > I know this means that a domain can be associated with 
> hosts as objects and
> > host as attributes and some people think that's 
> inconsistent.  I don't think
> > it is if you agree with the first point above.
> >
> > -Scott-
> 


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA4FG5cE019664 for <[e-mail]>; Mon, 4 Nov 2002 16:16:05 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gA4FG5Os019663 for ietf-provreg-outgoing; Mon, 4 Nov 2002 16:16:05 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA4FG1cE019658 for <[e-mail]>; Mon, 4 Nov 2002 16:16:04 +0100 (MET)
Received: from dev3.int.libertyrms.com ([10.1.2.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 188ixF-0004Xy-00; Mon, 04 Nov 2002 10:15:53 -0500
Message-ID: <[e-mail]>
Date: Mon, 04 Nov 2002 10:21:47 -0500
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3custom i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Handling of External Host Objects
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

I assume that with the new external host approach domain transfer process would
be simplified. No error code 2305 for transfer requests and approvals.

Regards,

Janusz Sienkiewicz

"Hollenbeck, Scott" wrote:

> One of the reasons I think that this external host thing continues to be an
> issue is because it's a kludge.  I firmly believe that the only objects that
> should exist in a repository are objects for which the repository is
> authoritative.  Other needed data should exist as attributes of existing
> objects.
>
> I suggested this concept related to external hosts back when the topic first
> came up.  Some folks had issues with it, but I'll suggest it again as an
> alternative.  In a nutshell:
>
> - The only objects that should exist in a repository are objects for which
> the repository is authoritative.
>
> - Host objects should only be created in a repository that is authoritative
> for the host.  In the case of hosts as name servers, "authoritative" means
> that data in the repository (host name and address(es)) is used to publish
> DNS glue and the repository is the legitimate source for that data.
>
> - If an external host is needed for delegation purposes, it can be
> associated with a domain object as an attribute of the object with no host
> object needed in advance.  There's no need to create an external host object
> ahead of time, no need to worry about IP addresses, etc.
>
> This solution does not allow object-based management of external hosts,
> which means that renaming the external host would need to be done on a
> per-name basis.  It may address the other issues that people have talked
> about on this thread, though.
>
> I know this means that a domain can be associated with hosts as objects and
> host as attributes and some people think that's inconsistent.  I don't think
> it is if you agree with the first point above.
>
> -Scott-



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA47JUcE015954 for <[e-mail]>; Mon, 4 Nov 2002 08:19:30 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gA47JU9o015953 for ietf-provreg-outgoing; Mon, 4 Nov 2002 08:19:30 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from melbourneit.com.au (king26.MelbourneIT.com.au [203.31.198.26]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA47JRcE015948 for <[e-mail]>; Mon, 4 Nov 2002 08:19:28 +0100 (MET)
Received: from mercury.mit (mercury.mit [192.168.80.36]) by melbourneit.com.au (8.9.3/8.9.3) with ESMTP id SAA32549; Mon, 4 Nov 2002 18:19:17 +1100
Received: by MERCURY with Internet Mail Service (5.5.2653.19) id <VAQAN17S>; Mon, 4 Nov 2002 18:19:08 +1100
Message-ID: <1595534C9032D411AECE00508BC766FB0456D36B@MERCURY>
From: Bruce Tonkin <[e-mail]>
To: "'Hollenbeck, Scott'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Handling of External Host Objects
Date: Mon, 4 Nov 2002 18:19:08 +1100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk

This makes sense to me.

An external host could be referred to in the same way that an email address
field is used.  
The registry is not authoritative for the email address, nor is it
authoritative for an external host where no glue records are created.

Regards,
Bruce


> -----Original Message-----
> From: Hollenbeck, Scott [mailto:[e-mail]]
> Sent: Sunday, November 03, 2002 12:08 PM
> To: '[e-mail]'
> Subject: RE: Handling of External Host Objects
> 
> 
> One of the reasons I think that this external host thing 
> continues to be an
> issue is because it's a kludge.  I firmly believe that the 
> only objects that
> should exist in a repository are objects for which the repository is
> authoritative.  Other needed data should exist as attributes 
> of existing
> objects.
> 
> I suggested this concept related to external hosts back when 
> the topic first
> came up.  Some folks had issues with it, but I'll suggest it 
> again as an
> alternative.  In a nutshell:
> 
> - The only objects that should exist in a repository are 
> objects for which
> the repository is authoritative.
> 
> - Host objects should only be created in a repository that is 
> authoritative
> for the host.  In the case of hosts as name servers, 
> "authoritative" means
> that data in the repository (host name and address(es)) is 
> used to publish
> DNS glue and the repository is the legitimate source for that data.
> 
> - If an external host is needed for delegation purposes, it can be
> associated with a domain object as an attribute of the object 
> with no host
> object needed in advance.  There's no need to create an 
> external host object
> ahead of time, no need to worry about IP addresses, etc.
> 
> This solution does not allow object-based management of 
> external hosts,
> which means that renaming the external host would need to be done on a
> per-name basis.  It may address the other issues that people 
> have talked
> about on this thread, though.
> 
> I know this means that a domain can be associated with hosts 
> as objects and
> host as attributes and some people think that's inconsistent. 
>  I don't think
> it is if you agree with the first point above.
> 
> -Scott-
> 


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA47CWcE015913 for <[e-mail]>; Mon, 4 Nov 2002 08:12:32 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gA47CWNF015912 for ietf-provreg-outgoing; Mon, 4 Nov 2002 08:12:32 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from host.onnethosting.com (host.onnethosting.com [209.239.41.3]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA47CTcE015907 for <[e-mail]>; Mon, 4 Nov 2002 08:12:29 +0100 (MET)
Received: from Millennium (lsanca1-ar23-4-63-048-019.lsanca1.dsl-verizon.net [4.63.48.19]) by host.onnethosting.com (8.10.2/8.10.2) with SMTP id gA47BVx03723; Mon, 4 Nov 2002 02:11:32 -0500
Message-ID: <00e001c283d1$57245e80$13303f04@Millennium>
From: "Asaad Y. Alnajjar - Millennium Inc." <[e-mail]>
To: "Tan Tin Wee" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: [minc-org-member] MINC Press Release on Interoperability Testing for IDN
Date: Sun, 3 Nov 2002 23:10:48 -0800
Organization: Millennium Inc.
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

Dear Dr. TinWee

1- Which languages are going to be part of this intended IDN testing?

2- Who is putting the guidelines together, ie criterea, standards, common whois,
policies and other IDN issues? Is it for gTLDs or will it include ccTLDs.

3- Who will supervise all the IDN issues? And how involved will be ICANN, ITU,
ISO and other distingueshed agencies?

4- I do believe that such an international vital task is for sure beyond the
authority and capabilities of MINC's board and should be in fact supervised
directly by the concerned regulatory parties and representatives such as ICANN &
ITU and for ccTLDs in conformance with ISO-3166-1.

5- Which technology providers are going to be allowed in and which one will be
prevented?
The IDN adminstration coordinators should be non technology providers, non
technology providers shareholders, not a previous/current technology providers
officers nor affiliated with any technology providers, this way we will
guarantee legitimacy of this vital work.

6- As you know AINC & the ARAB ICT are very active in Arabic and all of us at
the Arab Governments and the Arab ccTLDs do take pride in our language and its
roots and for sure and would like always to maintain its state untampered with
nor violated.
Please do keep in mind that for ARABIC we do need all the technology providers
to coordinate with all of us the ARAB ccTLDs on what standards will be accepted
and which gTLDs and ccTLDs will be approved or not.

7- MINC has to show a non biased attitude for a change, and reclaim
international legitimacy to us MINC founders at least.

Please coordinate all your Arabic related issues with the Arabic Script Committe
that includes the Arab ccTLDs in addition to Iran & Pakistan and do include the
concerned languages representatives to take active and leading role in this.

Regards,

Asaad Alnajjar
CEO Millennium Inc.   ( Home of the Arabic Domain Name )
MINC Founder / AINC Founder
http://www.ArabicDomainName.org










----- Original Message -----
From: "Tan Tin Wee" <[e-mail]>
Sent: Sunday, November 03, 2002 6:18 PM
Subject: [minc-org-member] MINC Press Release on Interoperability Testing for
IDN


>
> FOR IMMEDIATE RELEASE
>
> MINC ANNOUNCES INTEROPERABILITY TESTING FOR INTERNATIONALIZED DOMAIN NAMES
>
> 4 November 2002.
>
> In 2001, MINC announced an initiative to carry out an Interoperability
> Testing of the many solutions for Internationalised Domain Names (IDN)
> currently offered by its members and others. At that time, the
> Interoperability Testing was contingent on the publication of Internet
> standards on IDN by the IDN Working Group of the Internet Engineering
> Task Force (IETF).
>
> As of last week, the Internet Engineering Steering Group IESG has
> announced the publication of proposed IETF standards in IDN. Having had
> more than a year of background work on Interoperability Testing, until
> now being placed on hold, MINC is ideally positioned to coordinate an
> orderly deployment of IDN through the first step of determining conformance
> to IETF standards via its Interoperability Testing.
>
> At the Second meeting (2002/2003 session) of the new MINC Board, including
> six new recently elected board members, MINC passed a resolution to approve
> the Interoperability Testing process, and to endorse the expeditious
> execution of this testing process to ensure that the many solutions offered
> by vendors and providers of IDNs currently in the market not only conform
> to the standards, but can also fully interoperate with each other. This
> is essential for the proper delivery of reliable and robust IDN services
> to the user community.
>
> In proceeding with the Interoperability Testing, MINC shall shortly be
> announcing a call for setting up an Interoperability TestBed, and a
> subsequent call for participation. The testing is expected to be
> multi-faceted, including testing for registries, registrars, user
> applications and will involve enduser testing as well, each
> progressively released subject to stakeholder feedback and
> MINC processes.
>
> In proceeding with this, the new Chairman of MINC, Khaled Fattal, said,
> "The whole IDN community has long awaited this IDN Interoperability Testing.
>
> It will provide a level playing field for all vendors and providers to
> ensure that in their implementation of the IETF standards, that their
> solutions do not break or balkanise the Internet."
>
> "As a founding organisation to pioneer the call for IDNs, MINC has come a
> long way. To me, it is gratifying to see that finally, IDNs are recognised
> officially, from APTLD to ITU, from IETF to ICANN," said the original
> implementor and early champion of IDNs, Tan Tin Wee, a professor from the
> National University
> of Singapore. "These days, everyone seems to be organising
> their IDN committees and working groups - it's about time," he added.
>
> Newly inducted Board Member, Mr Charles Lee declared, "MINC is now taking
> on an industry-led mantle. Going forward, we shall focus on SERVICE to the
> community, ENGAGEMENT of key issues, and COOPERATION with all stakeholders
> and entities dedicated to the promotion, deployment, coordination and
> governance of IDNs."
>
> So far, MINC has contributed its first founding Chairman, Professor SH
> Kyong, to the ICANN Board of Directors. Its new Board member, K Konishi,
> has been the key driver of the Joint Engineering Taskforce (JET). Its
> second Chairman, Professor Shigeki Goto, is also the current chairman of
> the Japan Domain Names Association (JDNA). MINC's board member, S Maniam,
> is a working group chairman from the International Forum for IT in
> Tamil (INFITT). The former MINC CEO, Ms YJ Park, has also been
> active in the Names Council of ICANN, and ambassador extraordinaire for
> MINC to many international organisations. In view of the excellent
> connections  amongst key players in the field, MINC is well placed to
> provide an important service to the community and seeks the cooperation
> and participation of stakeholders in this critical moment of the evolution
> of Internet domain names in all scripts of all languages.
>
>
> About MINC
> --------------
> MINC is the Multilingual Internet Names Consortium, formed in 2000 from
> a wide diversity of stakeholders committed towards the promotion and
> coordination of the deployment of internationalized domain names (IDN)
> and other Internet names in all languages and scripts. As MINC
> increasingly evolves to an industry-led consortium, its key initiative
> is to ensure an orderly deployment of IDNs. MINC has a memorandum of
> understanding with the Tamil international language group, INFITT, and was
> involved in the formation of the Arabic Internet Names Consortium, AINC.
> It has active connections with Russian Cyrillic groups, EUROLINC, the
> European Languages Internet Names Consortium, FIAM, and has cooperated
> with JDNA, ITU, WIPO, ICANN and many others to hold joint meetings to
> popularise the notion of Internet domain names in languages and scripts
> of all nations. Organisational Membership is open to all
> interested organisations. Individual Membership is currently free.
> http://www.minc.org/
>
>
> MEDIA CONTACT:
> MINC Secretariat
> c/o Dr TW Tan [e-mail]
> TEL:  [phone]
>




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA37qacE006778 for <[e-mail]>; Sun, 3 Nov 2002 08:52:36 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gA37qaU8006777 for ietf-provreg-outgoing; Sun, 3 Nov 2002 08:52:36 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA37qZcE006772 for <[e-mail]>; Sun, 3 Nov 2002 08:52:35 +0100 (MET)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id gA37qYb26931 for <[e-mail]>; Sun, 3 Nov 2002 07:52:34 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <VLY1K8HR>; Sun, 3 Nov 2002 02:53:15 -0500
Message-ID: <[e-mail]>
From: "Liu, Hong" <[e-mail]>
To: [e-mail]
Subject: RE: Handling of External Host Objects: Single vs. Multi Copy Solu tions (was: in the context of domain transfer)
Date: Sun, 3 Nov 2002 02:53:14 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk

Jens,

Excellent points. I agree with your analysis. In other words, you went a
step further by stating that there is no way out of the paradox in the case
of 7(b) for the multi-copy model. 

No matter how one argues it being an implementation issue, the host object
handle as exposed in EPP is the hostname. Changing the hostname is
equivalent to deleting the old object and then creating a new one with the
same content. In your analysis, you identified the issue of implicit
deletion of a host object when it is linked to domains. As we all know,
explicit deletion of a linked host object is not allowed in EPP. Your
analysis implied that for the multi-copy model, even the implict deletion of
a linked host object is problematic.

One may argue that a way to get around it is not allowing sharing of
internal host objects as nameservers among registrars. Again we get back to
the issue of server policy. I don't think we should enforce that in the
protocol. What do you think?

Cheers,

--Hong

-----Original Message-----
From: Jens Wagner [mailto:[e-mail]]
Sent: Saturday, November 02, 2002 2:26 PM
To: Liu, Hong; [e-mail]
Subject: Re: Handling of External Host Objects: Single vs. Multi Copy
Solutions (was: in the context of domain transfer)


Hong,

Regarding 7(b), I don't think it is a good idea to let one registrar use
another registrar's private copy of an host object, that's why we call it
private. It would also be inconsistent with the return values of the host
related check and info commands.

Regaring the server policy in (2.):
1. When dom2.tld loses DNS service from ns.dom.ext, this will eventually
render the domain status of dom2.tld from active to inactive. Should
Registrar R1 be allowed/able to deactivate domains from Registrar R2?
2. When the server has to deny a request for changing an internal host to an
external host, how will Registrar R1 be able to know the reason, and how
will R1 be able to resolve that?

Best regards,

-jens

----- Original Message -----
From: "Liu, Hong" <[e-mail]>
To: <[e-mail]>
Sent: Saturday, November 02, 2002 7:32 PM
Subject: RE: Handling of External Host Objects: Single vs. Multi Copy
Solutions (was: in the context of domain transfer)


> Jen,
>
> Please see my comments below. Thanks!
>
> --Hong
>
> -----Original Message-----
> From: Jens Wagner [mailto:[e-mail]]
> Sent: Saturday, November 02, 2002 5:50 AM
> To: Liu, Hong; [e-mail]
> Subject: Re: Handling of External Host Objects: Single vs. Multi Copy
> Solutions (was: in the context of domain transfer)
>
>
>
> ----- Original Message -----
> From: "Liu, Hong" <[e-mail]>
> To: <[e-mail]>
> Sent: Thursday, October 31, 2002 12:37 AM
> Subject: RE: Handling of External Host Objects: Single vs. Multi Copy
> Solutions (was: in the context of domain transfer)
>
>
> ...
> > (7) Internal-to-external. Suppose ISP X has an internal host sponsored
by
> R
> > that is being used as a nameserver of other domains. Now X wants to
> replace
> > that with an external host. There are two cases to consider:
> > (a) R already has a private copy of the external host. Then R cannot
> rename
> > the internal host to the external host. Instead, R will have to update
> each
> > domain one-by-one that uses the internal host as nameserver.
> > (b) R does not have a private copy of the external host. R can rename
the
> > internal host to the external host without any problem since it is the
> > sponsoring registrar, and all domains sponsored by R that are using the
> > internal host as nameserver now points to the external host.
> > In both cases, domains sponsored by other registrars that use the
internal
> > host as nameserver will have to be updated one-by-one. To make things
even
> > worst, in the case of 7(b), before these updates are completed, domains
in
> > other registrars will be pointing to private copy of external host in R.
> > This violates the very principle of the multi-copy model!
> ...
>
> Hong,
>
> Just thought about your point 7(b):
>
> Registrar R1 creates domain dom1.tld
> Registrar R1 creates host ns1.dom1.tld (internal host)
> Registrar R1 updates domain dom1.tld to use nameserver ns1.dom1.tld
> (internal)
> Registrar R2 creates domain dom2.tld with nameserver ns1.dom1.tld
(internal)
> so far, its seems to be ok:
> ----
> dom1.tld managed by R1 has nameserver ns1.dom1.tld
> dom2.tld managed by R2 has nameserver ns1.dom1.tld
> ----
>
> now we apply Scenario 7(b):
> Registrar R1 renames host ns1.dom1.tld (internal) to ns.dom.ext(,R1)
> (external)
>
> What does the Registry DB look like now?
> ----
> dom1.tld managed by R1 has nameserver ns.dom.ext(,R1) (external)
>
> What happens with dom2.tld? Three possibilities:
> 1. dom2.tld managed by R2 has nameserver ns1.dom1.tld (internal)
> 2. dom2.tld managed by R2 has nameserver ns.dom.ext(,R1) (external)
> 3. dom2.tld managed by R2 has nameserver ns.dom.ext(,R2) (external)
> ----
>
> (1.) should not be possible, because R1 removed the internal host
> ns1.dom1.tld by renaming it.
> (2.) should not be possible, because ns.dom.ext(,R1) must not be
accessible
> by R2.
> (3.) should not be possible, because this would mean that R1 created an
> external host object ns.dom.ext(,R2) in the repository of R2.
>
> Or did I get anything wrong?
>
> <HL>
> Your breakdown of the scenario is excellent. Thanks for doing that.
>
> It seems that whether (2.) is possible or not is _not_ specified in the
> current EPP protocol. As such I viewed that as a server policy. 7(b) in my
> case allows one registrar to use another registrar's private copy, while
> your (2.) does not. We were both right on that sense. In fact, the server
> policy in (2.) makes the multi-copy model even less attractive since now
> either dom2.tld loses DNS service from ns.dom.ext or that the server will
> have to deny the initial request for changing an internal host to and an
> external host. What do you think?
> </HL>
>
> Best regards,
>
> Jens Wagner
> Key-Systems GmbH
>
>


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA318IcE004604 for <[e-mail]>; Sun, 3 Nov 2002 02:08:18 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gA318IPa004603 for ietf-provreg-outgoing; Sun, 3 Nov 2002 02:08:18 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA318GcE004598 for <[e-mail]>; Sun, 3 Nov 2002 02:08:17 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id UAA24070 for <[e-mail]>; Sat, 2 Nov 2002 20:08:15 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <V87J408L>; Sat, 2 Nov 2002 20:04:18 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Handling of External Host Objects
Date: Sat, 2 Nov 2002 20:08:13 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

One of the reasons I think that this external host thing continues to be an
issue is because it's a kludge.  I firmly believe that the only objects that
should exist in a repository are objects for which the repository is
authoritative.  Other needed data should exist as attributes of existing
objects.

I suggested this concept related to external hosts back when the topic first
came up.  Some folks had issues with it, but I'll suggest it again as an
alternative.  In a nutshell:

- The only objects that should exist in a repository are objects for which
the repository is authoritative.

- Host objects should only be created in a repository that is authoritative
for the host.  In the case of hosts as name servers, "authoritative" means
that data in the repository (host name and address(es)) is used to publish
DNS glue and the repository is the legitimate source for that data.

- If an external host is needed for delegation purposes, it can be
associated with a domain object as an attribute of the object with no host
object needed in advance.  There's no need to create an external host object
ahead of time, no need to worry about IP addresses, etc.

This solution does not allow object-based management of external hosts,
which means that renaming the external host would need to be done on a
per-name basis.  It may address the other issues that people have talked
about on this thread, though.

I know this means that a domain can be associated with hosts as objects and
host as attributes and some people think that's inconsistent.  I don't think
it is if you agree with the first point above.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA2JQhcE003210 for <[e-mail]>; Sat, 2 Nov 2002 20:26:43 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gA2JQhDc003209 for ietf-provreg-outgoing; Sat, 2 Nov 2002 20:26:43 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mailer.key-systems.net (mailer.key-systems.net [217.6.37.74]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gA2JQgcE003204 for <[e-mail]>; Sat, 2 Nov 2002 20:26:42 +0100 (MET)
Received: (qmail 17051 invoked from network); 2 Nov 2002 19:25:46 -0000
Received: from p508afada.dip.t-dialin.net (HELO jwhome) (80.138.250.218) by mailer.key-systems.net with SMTP; 2 Nov 2002 19:25:46 -0000
Message-ID: <0cae01c282a5$bdda72e0$0201a8c0@jwhome>
From: "Jens Wagner" <[e-mail]>
To: "Liu, Hong" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Handling of External Host Objects: Single vs. Multi Copy Solutions (was: in the context of domain transfer)
Date: Sat, 2 Nov 2002 20:26:27 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

Hong,

Regarding 7(b), I don't think it is a good idea to let one registrar use
another registrar's private copy of an host object, that's why we call it
private. It would also be inconsistent with the return values of the host
related check and info commands.

Regaring the server policy in (2.):
1. When dom2.tld loses DNS service from ns.dom.ext, this will eventually
render the domain status of dom2.tld from active to inactive. Should
Registrar R1 be allowed/able to deactivate domains from Registrar R2?
2. When the server has to deny a request for changing an internal host to an
external host, how will Registrar R1 be able to know the reason, and how
will R1 be able to resolve that?

Best regards,

-jens

----- Original Message -----
From: "Liu, Hong" <[e-mail]>
To: <[e-mail]>
Sent: Saturday, November 02, 2002 7:32 PM
Subject: RE: Handling of External Host Objects: Single vs. Multi Copy
Solutions (was: in the context of domain transfer)


> Jen,
>
> Please see my comments below. Thanks!
>
> --Hong
>
> -----Original Message-----
> From: Jens Wagner [mailto:[e-mail]]
> Sent: Saturday, November 02, 2002 5:50 AM
> To: Liu, Hong; [e-mail]
> Subject: Re: Handling of External Host Objects: Single vs. Multi Copy
> Solutions (was: in the context of domain transfer)
>
>
>
> ----- Original Message -----
> From: "Liu, Hong" <[e-mail]>
> To: <[e-mail]>
> Sent: Thursday, October 31, 2002 12:37 AM
> Subject: RE: Handling of External Host Objects: Single vs. Multi Copy
> Solutions (was: in the context of domain transfer)
>
>
> ...
> > (7) Internal-to-external. Suppose ISP X has an internal host sponsored
by
> R
> > that is being used as a nameserver of other domains. Now X wants to
> replace
> > that with an external host. There are two cases to consider:
> > (a) R already has a private copy of the external host. Then R cannot
> rename
> > the internal host to the external host. Instead, R will have to update
> each
> > domain one-by-one that uses the internal host as nameserver.
> > (b) R does not have a private copy of the external host. R can rename
the
> > internal host to the external host without any problem since it is the
> > sponsoring registrar, and all domains sponsored by R that are using the
> > internal host as nameserver now points to the external host.
> > In both cases, domains sponsored by other registrars that use the
internal
> > host as nameserver will have to be updated one-by-one. To make things
even
> > worst, in the case of 7(b), before these updates are completed, domains
in
> > other registrars will be pointing to private copy of external host in R.
> > This violates the very principle of the multi-copy model!
> ...
>
> Hong,
>
> Just thought about your point 7(b):
>
> Registrar R1 creates domain dom1.tld
> Registrar R1 creates host ns1.dom1.tld (internal host)
> Registrar R1 updates domain dom1.tld to use nameserver ns1.dom1.tld
> (internal)
> Registrar R2 creates domain dom2.tld with nameserver ns1.dom1.tld
(internal)
> so far, its seems to be ok:
> ----
> dom1.tld managed by R1 has nameserver ns1.dom1.tld
> dom2.tld managed by R2 has nameserver ns1.dom1.tld
> ----
>
> now we apply Scenario 7(b):
> Registrar R1 renames host ns1.dom1.tld (internal) to ns.dom.ext(,R1)
> (external)
>
> What does the Registry DB look like now?
> ----
> dom1.tld managed by R1 has nameserver ns.dom.ext(,R1) (external)
>
> What happens with dom2.tld? Three possibilities:
> 1. dom2.tld managed by R2 has nameserver ns1.dom1.tld (internal)
> 2. dom2.tld managed by R2 has nameserver ns.dom.ext(,R1) (external)
> 3. dom2.tld managed by R2 has nameserver ns.dom.ext(,R2) (external)
> ----
>
> (1.) should not be possible, because R1 removed the internal host
> ns1.dom1.tld by renaming it.
> (2.) should not be possible, because ns.dom.ext(,R1) must not be
accessible
> by R2.
> (3.) should not be possible, because this would mean that R1 created an
> external host object ns.dom.ext(,R2) in the repository of R2.
>
> Or did I get anything wrong?
>
> <HL>
> Your breakdown of the scenario is excellent. Thanks for doing that.
>
> It seems that whether (2.) is possible or not is _not_ specified in the
> current EPP protocol. As such I viewed that as a server policy. 7(b) in my
> case allows one registrar to use another registrar's private copy, while
> your (2.) does not. We were both right on that sense. In fact, the server
> policy in (2.) makes the multi-copy model even less attractive since now
> either dom2.tld loses DNS service from ns.dom.ext or that the server will
> have to deny the initial request for changing an internal host to and an
> external host. What do you think?
> </HL>
>
> Best regards,
>
> Jens Wagner
> Key-Systems GmbH
>
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA2IWGcE003036 for <[e-mail]>; Sat, 2 Nov 2002 19:32:16 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gA2IWG1B003035 for ietf-provreg-outgoing; Sat, 2 Nov 2002 19:32:16 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA2IWFcE003030 for <[e-mail]>; Sat, 2 Nov 2002 19:32:15 +0100 (MET)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id gA2IWEb15182 for <[e-mail]>; Sat, 2 Nov 2002 18:32:15 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <VLY1K6YQ>; Sat, 2 Nov 2002 13:32:54 -0500
Message-ID: <[e-mail]>
From: "Liu, Hong" <[e-mail]>
To: [e-mail]
Subject: RE: Handling of External Host Objects: Single vs. Multi Copy Solu tions (was: in the context of domain transfer)
Date: Sat, 2 Nov 2002 13:32:53 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk

Jen,

Please see my comments below. Thanks!

--Hong

-----Original Message-----
From: Jens Wagner [mailto:[e-mail]]
Sent: Saturday, November 02, 2002 5:50 AM
To: Liu, Hong; [e-mail]
Subject: Re: Handling of External Host Objects: Single vs. Multi Copy
Solutions (was: in the context of domain transfer)



----- Original Message -----
From: "Liu, Hong" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, October 31, 2002 12:37 AM
Subject: RE: Handling of External Host Objects: Single vs. Multi Copy
Solutions (was: in the context of domain transfer)


...
> (7) Internal-to-external. Suppose ISP X has an internal host sponsored by
R
> that is being used as a nameserver of other domains. Now X wants to
replace
> that with an external host. There are two cases to consider:
> (a) R already has a private copy of the external host. Then R cannot
rename
> the internal host to the external host. Instead, R will have to update
each
> domain one-by-one that uses the internal host as nameserver.
> (b) R does not have a private copy of the external host. R can rename the
> internal host to the external host without any problem since it is the
> sponsoring registrar, and all domains sponsored by R that are using the
> internal host as nameserver now points to the external host.
> In both cases, domains sponsored by other registrars that use the internal
> host as nameserver will have to be updated one-by-one. To make things even
> worst, in the case of 7(b), before these updates are completed, domains in
> other registrars will be pointing to private copy of external host in R.
> This violates the very principle of the multi-copy model!
...

Hong,

Just thought about your point 7(b):

Registrar R1 creates domain dom1.tld
Registrar R1 creates host ns1.dom1.tld (internal host)
Registrar R1 updates domain dom1.tld to use nameserver ns1.dom1.tld
(internal)
Registrar R2 creates domain dom2.tld with nameserver ns1.dom1.tld (internal)
so far, its seems to be ok:
----
dom1.tld managed by R1 has nameserver ns1.dom1.tld
dom2.tld managed by R2 has nameserver ns1.dom1.tld
----

now we apply Scenario 7(b):
Registrar R1 renames host ns1.dom1.tld (internal) to ns.dom.ext(,R1)
(external)

What does the Registry DB look like now?
----
dom1.tld managed by R1 has nameserver ns.dom.ext(,R1) (external)

What happens with dom2.tld? Three possibilities:
1. dom2.tld managed by R2 has nameserver ns1.dom1.tld (internal)
2. dom2.tld managed by R2 has nameserver ns.dom.ext(,R1) (external)
3. dom2.tld managed by R2 has nameserver ns.dom.ext(,R2) (external)
----

(1.) should not be possible, because R1 removed the internal host
ns1.dom1.tld by renaming it.
(2.) should not be possible, because ns.dom.ext(,R1) must not be accessible
by R2.
(3.) should not be possible, because this would mean that R1 created an
external host object ns.dom.ext(,R2) in the repository of R2.

Or did I get anything wrong?

<HL>
Your breakdown of the scenario is excellent. Thanks for doing that. 

It seems that whether (2.) is possible or not is _not_ specified in the
current EPP protocol. As such I viewed that as a server policy. 7(b) in my
case allows one registrar to use another registrar's private copy, while
your (2.) does not. We were both right on that sense. In fact, the server
policy in (2.) makes the multi-copy model even less attractive since now
either dom2.tld loses DNS service from ns.dom.ext or that the server will
have to deny the initial request for changing an internal host to and an
external host. What do you think?
</HL>

Best regards,

Jens Wagner
Key-Systems GmbH



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA2I6mcE002922 for <[e-mail]>; Sat, 2 Nov 2002 19:06:48 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gA2I6mjx002921 for ietf-provreg-outgoing; Sat, 2 Nov 2002 19:06:48 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA2I6lcE002916 for <[e-mail]>; Sat, 2 Nov 2002 19:06:47 +0100 (MET)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id gA2I6kb14860 for <[e-mail]>; Sat, 2 Nov 2002 18:06:46 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <VLY1K6XM>; Sat, 2 Nov 2002 13:07:26 -0500
Message-ID: <[e-mail]>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Handling of External Host Objects: Single vs. Multi Copy Solu tions (was: in the context of domain transfer)
Date: Sat, 2 Nov 2002 13:07:24 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk

Asbjorn,

Please see my comments in line enclosed with <HL/>. I am using MS Outlook,
-:(.

--Hong

-----Original Message-----
From: Asbjorn Steira [mailto:[e-mail]]
Sent: Thursday, October 31, 2002 12:46 PM
To: Liu, Hong
Cc: '[e-mail]'
Subject: Re: Handling of External Host Objects: Single vs. Multi Copy
Solu tions (was: in the context of domain transfer)


Hong,

please see comments below...

Asbjorn


Liu, Hong wrote:

> In terms of (3), you are making an assumption about server policy in 
> terms of who is eligible to query an external host using . What if the 
> server policy is any client is eligible to query a host object? Will 
> the server return 2303 if the client does not have a private copy 
> while there are many other private copies out there? How can a server 
> return multiple instances of the same external host in an response?
>
> So the only way out is to codify in the protocol that a client can 
> only its private copy for external hosts. This is in effect enforcing 
> a server policy. As discussed on the list many times before, the 
> protocol should be flexible enough to allow different policies, but 
> _not_ to enforce a specific policy. In addition, this is no longer an 
> implementation issue, it now becomes a protocol issue.

I realize that the sponsoring registrar can only view his own copy of 
the host object, and even though this is not perfect, I don't think this 
is a big problem. There is not really any useful information related to 
an external host, the only thing that might be of interest is the status 
of the object.

<HL>
It is a fixed-in of server policy in the protocol, and it is a protocol
issue. And it is a bad fix.

Having multi-copy of the same object but letting these copies be out of sync
in terms of object states is long recognized as a basic flaw in
object-oriented computing. Why are we violating a basic principle to come up
with a kludgy solution to another problem where a simpler solution exists?

Do you think host statii are not interesting or useful? Then why do we keep
them in the protocol in the first place?
</HL>

> As for whois, to avoid confusion, an end user now needs to use both 
> the hostname and the registrarID to query an external host. I would 
> not speculate how many end users really know or care about 
> registrarIDs. They use whois just want to find out if a host exists or 
> not. Plus, most of the whois implementations today do not provide 
> {hostname,registrarID} query capability. Are you suggesting that even 
> the whois part (and user behavior) needs to be modified in order to 
> accommodate the multi-copy model? Is it introducing more problems in 
> order to solve _a_ problem?

This depends on how you implement it - the end user does not necessarily 
need to know the registrar name/id. For .name we simply return all the 
instances of the object, for example:
http://www.nic.name/cgi-bin/whoisweb.cgi?type=public&page=query&d=d&qt=names
erver&q=NS.NEWDREAM.NET

<HL>
Please see my original posting on (3) regarding whois. Yes, you can
enumerate all private copies of an external object. But it is at best
confusing to the end user of whois. In other to make sense out of the
response, the end user will have to sort through which private copy belongs
to which registrar. The end user will be even more confused when the private
copies have different/conflicting statii. It is inconsistent with internal
host query, which means you need to write the whois code differently to deal
with the two cases. Since it returns more data for external hosts, it is
more likely to overload the whois server. Is it introducing more problems in
order to solve _a_ problem?
</HL>

> In terms of the support for reference-based renaming, the 
> server-centric single-copy model does not prohibit such operation. 
> That is, a sponsoring registrar is still capable of renaming any 
> internal host objects created through it. The problem is 
> reference-based renaming for external host objects. In our single-copy 
> approach, this has to be done one-by-one.
> However, for the multi-copy model, reference-based renaming only works 
> for massive external-to-external nameserver updates. For other cases, 
> it has to perform the nameserver updates one-by-one for most of the 
> domains:

> (5) Partial updates. For example, both registrant A and registrant B 
> use ISP X's DNS hosting services. Suppose both A and B register their 
> domains through the same registrar R, using the same set of namesevers 
> provided by X that are external hosts. Now B decides to use ISP Y's 
> DNS hosting service instead. Suppose that the nameservers provided by 
> Y are also external hosts.
> Then registrar R cannot just rename X's nameservers to Y's since A's 
> domains are still using X's nameservers. So R has to update B's 
> domains one-by-one.

This could be done with only one host update command in a multi-copy 
universe.

<HL>
I would like you to explain how you can do that.
</HL>

> (6) External-to-internal. Suppose ISP X is also a registrant of R. It
> creates a set of internal hosts through R. So R is the sponsoring 
> registrar of these hosts. Then X decides to use these hosts as 
> nameservers to provide DNS hosting services to all the domains in the 
> same registry. Then R cannot just rename the external hosts to the 
> internal ones since those internal hosts already exist in the 
> registry. So R will have to update each domain of A and B one-by-one. 

Would be the same for single-copy and multi-copy...

<HL>
That means multi-copy offers no advantage for this case.
</HL>

> Another scenario could be that R implicitly creates these internal 
> hosts by renaming the external hosts. In this case, R does not need to 
> update each domain of A and B one-by-one. However, other registrars 
> will have to update domains one-by-one: they cannot just rename their 
> private copies to the internal hosts since they are not the sponsoring 
> registrar of those internal hosts. 

Would be the same for single-copy and multi-copy...

<HL>
That means multi-copy offers no advantage for this case.
</HL>

> (7) Internal-to-external. Suppose ISP X has an internal host sponsored 
> by R that is being used as a nameserver of other domains. Now X wants 
> to replace that with an external host. There are two cases to consider:
> (a) R already has a private copy of the external host. Then R cannot 
> rename the internal host to the external host. Instead, R will have to 
> update each domain one-by-one that uses the internal host as nameserver.

Would be the same for single-copy and multi-copy...

<HL>
That means multi-copy offers no advantage for this case.
</HL>

> (b) R does not have a private copy of the external host. R can rename 
> the internal host to the external host without any problem since it is 
> the sponsoring registrar, and all domains sponsored by R that are 
> using the internal host as nameserver now points to the external host.
> In both cases, domains sponsored by other registrars that use the 
> internal host as nameserver will have to be updated one-by-one. To 
> make things even worst, in the case of 7(b), before these updates are 
> completed, domains in other registrars will be pointing to private 
> copy of external host in R.
> This violates the very principle of the multi-copy model!

I think this was discussed on the list at some point. And I think this 
is the biggest "problem" we identified with the multi-copy solution.

<HL>
So you agree that this is the biggest problem (note no double quotes). How
are you going to fix it? 

Why are we inventing a model that is basically flawed with inconsistency?
</HL>

> In summary, I would like to get answers from the multi-copy proponents 
> for the following questions:
>
> (i) What are the advantages of the multi-copy model as compared to the
> server-centric single-copy model?

(a) Mass updates (I). In the single-copy model, a registrar potentially 
needs to do x thousand domain update commands when changing a name 
server name from ns1.example.tld to ns2.example.tld. This can be done 
with only one host update command in multi-copy.

<HL>
First, how often will a registrar update THOUSANDS of domains at the same
time? 

Second, until you could explain to me how you can do partial update with one
host update command, I will have to say this is of such low probability that
it should _not_ be used as the key criteria for protocol design
optimization.
</HL>

(b) Mass updates (II). As far as I can see, the single-copy model won't 
support any kind of moving name servers into the zone, you would always 
need to run update commands for all domains. In most cases, this would 
work fine in the multi-copy model.

<HL>
Could you please expand your point further? I am getting lost here?
</HL>

That's the only things I can come up with right now.

I do see that the single-copy model solves the 7b-problem and 
potentially makes the transfer process a bit easier, and I guess it is 
all about if you want that or if you rather wanna make mass updates 
easier. I see strong and weak points with both solutions...

<HL>
As discussed above, maintaining model consistency is very important in
protocol design. Making the transfer process simple and uniform is very
important. Transfer is the most complicated operation in EPP, and the
multi-copy model makes it even more complicated. Plus the <info> and whois
problems, the complication of server logic to specially handles multiple
copies, the waste of storage, the <check> command inconsistency, the risk of
implicit mass update, etc. These are undue cost and complexity incurred by
the multi-copy model.

Is it still justified to keep the multi-copy model just for the convenience
of complete mass update for external-to-external host renaming? I guess the
answer is pretty clear.
</HL>


> (ii) What are the complaints on the former client-centric single-copy 
> model that are not addressed by the server-centric single-copy model, 
> but are solved by the multi-copy model?

Not having dealt with RRP registries, I cannot answer this :-).


(Asbjorn)

-- 
Asbjorn Steira
The Global Name Registry, Limited



Information contained herein is Global Name Registry Proprietary Information
and is made available to you because of your interest in our company.
This information is submitted in confidence and its disclosure to you is not
intended to constitute public disclosure or authorization for disclosure to
other parties.
*****************
What's your .name?
Get one at www.name
*****************


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA2HHKcE002652 for <[e-mail]>; Sat, 2 Nov 2002 18:17:20 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gA2HHK7U002651 for ietf-provreg-outgoing; Sat, 2 Nov 2002 18:17:20 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA2HHIcE002646 for <[e-mail]>; Sat, 2 Nov 2002 18:17:19 +0100 (MET)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id gA2HHIb14049 for <[e-mail]>; Sat, 2 Nov 2002 17:17:18 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <VLY1K6T7>; Sat, 2 Nov 2002 12:17:57 -0500
Message-ID: <[e-mail]>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Handling of External Host Objects: Single vs. Multi Copy Solu tions (was: in the context of domain transfer)
Date: Sat, 2 Nov 2002 12:17:55 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk

Hi, Andy,

Actually we may be talking about the same thing, -:) What I meant by
enumerating (5)-(7) was to show that mass update does not work for
multi-copy model in those scenarios. And as such, it is just as good (or
bad) as the the server-centric single-copy model. In other words, mass
update _only_ work in the case of _complete_ external-to-external host
rename. It is the only advantage that I heard so far, but came with so many
baggages.

--Hong

-----Original Message-----
From: Andrew Sullivan [mailto:[e-mail]]
Sent: Thursday, October 31, 2002 10:22 AM
To: '[e-mail]'
Subject: Re: Handling of External Host Objects: Single vs. Multi Copy
Solu tions (was: in the context of domain transfer)


On Wed, Oct 30, 2002 at 06:37:34PM -0500, Liu, Hong wrote:
> (5) Partial updates. 
[. . .]
> nameservers provided by Y are also external hosts. Then registrar R
> cannot just rename X's nameservers to Y's since A's domains are
> still using X's nameservers. So R has to update B's domains
> one-by-one.

I truly do not understand this objection.  This is no different than
if B decides to change name servers using internal hosts, if someone
else is using the host.  (Objection 6 seems to me to be the same:
it's just not a real objection.  Yes, it's a pain to change the
nameservers of a large number of domains.  There's a reason managers
of large networks avoid doing so.)

A
-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<[e-mail]>                              M2P 2A8
                                         [phone] x110


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA2AoXcE000959 for <[e-mail]>; Sat, 2 Nov 2002 11:50:33 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gA2AoX2O000958 for ietf-provreg-outgoing; Sat, 2 Nov 2002 11:50:33 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mailer.key-systems.net (mailer.key-systems.net [217.6.37.74]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gA2AoWcE000953 for <[e-mail]>; Sat, 2 Nov 2002 11:50:32 +0100 (MET)
Received: (qmail 28710 invoked from network); 2 Nov 2002 10:49:35 -0000
Received: from p508afada.dip.t-dialin.net (HELO jwhome) (80.138.250.218) by mailer.key-systems.net with SMTP; 2 Nov 2002 10:49:35 -0000
Message-ID: <0a5701c2825d$a1b30a70$0201a8c0@jwhome>
From: "Jens Wagner" <[e-mail]>
To: "Liu, Hong" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Handling of External Host Objects: Single vs. Multi Copy Solutions (was: in the context of domain transfer)
Date: Sat, 2 Nov 2002 11:50:16 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

----- Original Message -----
From: "Liu, Hong" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, October 31, 2002 12:37 AM
Subject: RE: Handling of External Host Objects: Single vs. Multi Copy
Solutions (was: in the context of domain transfer)


...
> (7) Internal-to-external. Suppose ISP X has an internal host sponsored by
R
> that is being used as a nameserver of other domains. Now X wants to
replace
> that with an external host. There are two cases to consider:
> (a) R already has a private copy of the external host. Then R cannot
rename
> the internal host to the external host. Instead, R will have to update
each
> domain one-by-one that uses the internal host as nameserver.
> (b) R does not have a private copy of the external host. R can rename the
> internal host to the external host without any problem since it is the
> sponsoring registrar, and all domains sponsored by R that are using the
> internal host as nameserver now points to the external host.
> In both cases, domains sponsored by other registrars that use the internal
> host as nameserver will have to be updated one-by-one. To make things even
> worst, in the case of 7(b), before these updates are completed, domains in
> other registrars will be pointing to private copy of external host in R.
> This violates the very principle of the multi-copy model!
...

Hong,

Just thought about your point 7(b):

Registrar R1 creates domain dom1.tld
Registrar R1 creates host ns1.dom1.tld (internal host)
Registrar R1 updates domain dom1.tld to use nameserver ns1.dom1.tld
(internal)
Registrar R2 creates domain dom2.tld with nameserver ns1.dom1.tld (internal)
so far, its seems to be ok:
----
dom1.tld managed by R1 has nameserver ns1.dom1.tld
dom2.tld managed by R2 has nameserver ns1.dom1.tld
----

now we apply Scenario 7(b):
Registrar R1 renames host ns1.dom1.tld (internal) to ns.dom.ext(,R1)
(external)

What does the Registry DB look like now?
----
dom1.tld managed by R1 has nameserver ns.dom.ext(,R1) (external)

What happens with dom2.tld? Three possibilities:
1. dom2.tld managed by R2 has nameserver ns1.dom1.tld (internal)
2. dom2.tld managed by R2 has nameserver ns.dom.ext(,R1) (external)
3. dom2.tld managed by R2 has nameserver ns.dom.ext(,R2) (external)
----

(1.) should not be possible, because R1 removed the internal host
ns1.dom1.tld by renaming it.
(2.) should not be possible, because ns.dom.ext(,R1) must not be accessible
by R2.
(3.) should not be possible, because this would mean that R1 created an
external host object ns.dom.ext(,R2) in the repository of R2.

Or did I get anything wrong?

Best regards,

Jens Wagner
Key-Systems GmbH




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA20m9cE026643 for <[e-mail]>; Sat, 2 Nov 2002 01:48:09 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gA20m9X0026642 for ietf-provreg-outgoing; Sat, 2 Nov 2002 01:48:09 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA20m8cE026637 for <[e-mail]>; Sat, 2 Nov 2002 01:48:08 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id TAA01183; Fri, 1 Nov 2002 19:48:06 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <V87J4WTG>; Fri, 1 Nov 2002 19:44:11 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, [e-mail]
Subject: RE: more comments from the IESG
Date: Fri, 1 Nov 2002 19:48:05 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id gA20m8cE026638
Sender: [e-mail]
Precedence: bulk

Got it; thanks, Ed.

-Scott-

> -----Original Message-----
> From: Edward Lewis [mailto:[e-mail]]
> Sent: Wednesday, October 30, 2002 12:32 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: more comments from the IESG
> 
> 
> Due to a snafu these comments were separated from the original list. 
> (It's not like the IESG is piling on comments, these were meant to be 
> part of the previous list sent to the list).
> 
> >  From: Allison Mankin <[e-mail]>
> >  Date: mån okt 21, 2002  20:20:55 Europe/Stockholm
> >  To: [e-mail], [e-mail], 
> [e-mail], [e-mail]
> >  Subject: Discuss on provreg-epp and provreg-epp-tcp
> >
> >  ********
> >  ISSUES with draft-ietf-provreg-epp-07.txt
> >  1.
> >       The transport mapping MUST manage congestion.
> >
> >    This wording would be better replaced by the following (and
> >    my comment takes into account both Scott's request and
> >    the fact that the transport mapping may be over SMTP or
> >    something other than a "transport" such as TCP or SCTP.
> >
> >       The transport mapping MUST be onto a transport such
> >       as TCP or SCTP that provides congestion avoidance that
> >       follows RFC 2914, or if it maps onto a protocol such
> >       as SMTP or BEEP, then the performance issues need to
> >       take into account issues of overload, server availability
> >       and so forth.
> 
> I know that the above addresses my concerns.  (That's about all I 
> will add as a comment as it's up to the WG to determine.)
> 
> >
> >  2.
> >
> >  Within the optional dcp (data collection policy) element:
> >  there is a non-technical spin in at least the
> >  following label definition, what kind of marketing is meant?
> >
> >         <contact/>: Contact for marketing purposes.
> >
> >  Please add more to this definition so that is more neutral in
> >  in its terminology.
> >
> >  About the recipient and data retention
> >  elements - how would they provide a means to allow provisioning
> >  a strick privacy policy in some use of EPP (they are not used
> >  in one of the companion documents? The author is asked to
> >  give a few sentences to encourage a view that they have teeth
> >  (more so than their parent P3P) in EPP.
> 
> This will be discussed at the Atlanta meeting.  But don't hold back 
> on dicussing this in email ('cause not everyone will be making it to 
> Atlanta).
> 
> >  3.
> >
> >  This is a general question, but I would like the author, as
> >  an expert on the topic, to send an written answer to the IESG,
> >  not to make a change to this document set:
> >
> >     How does IESG and the community check the extensive XML in a
> >     specification like this (analogous to the ABNF and MIB
> >     checking described that is done regularly...)?  How did you
> >     check what's here?  Why might it not matter?
> >
> >  ******
> >  ISSUES with  draft-ietf-provreg-epp-tcp-05.txt
> >  1.
> >    An EPP client streams EPP commands to an EPP server on 
> an established
> >    TCP connection.  A client MAY establish multiple TCP 
> connections to
> >    create multiple command exchange channels.  A server MAY limit a
> >    client to a maximum number of TCP connections based on server
> >    capabilities and operational load.
> >
> >  It is not a good thing for the net for services to choose
> >  this approach.  A MAY like this is problematic for congestion
> >  control reasons.  I would like to change this language from
> >  "MAY establish" to "MAY but SHOULD NOT" and from "A server MAY
> >  limit" to "A server SHOULD limit"
> >
> >
> >  2.
> >
> >  For references to TCP, besides RFC 793, you need:
> >
> >      RFC 2581, 2914.
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                          [phone]
> ARIN Research Engineer
> 



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA1KvHcE025026 for <[e-mail]>; Fri, 1 Nov 2002 21:57:17 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gA1KvHnE025025 for ietf-provreg-outgoing; Fri, 1 Nov 2002 21:57:17 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA1KvGcE025020 for <[e-mail]>; Fri, 1 Nov 2002 21:57:16 +0100 (MET)
Received: from dev3.int.libertyrms.com ([10.1.2.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 187iqq-0004fZ-00; Fri, 01 Nov 2002 15:57:08 -0500
Message-ID: <[e-mail]>
Date: Fri, 01 Nov 2002 16:02:51 -0500
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3custom i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Asbjorn Steira <[e-mail]>
CC: "Liu, Hong" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Handling of External Host Objects: Single vs. Multi Copy Solutions  (was: in the context of domain transfer)
References: <[e-mail]> <[e-mail]>
Content-Type: multipart/alternative; boundary="------------8D1B10F3372B48254A8DCF1C"
Sender: [e-mail]
Precedence: bulk

--------------8D1B10F3372B48254A8DCF1C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Asbjorn,

please see comments below ...

Asbjorn Steira wrote:

> (a) Mass updates (I). In the single-copy model, a registrar potentially
> needs to do x thousand domain update commands when changing a name
> server name from ns1.example.tld to ns2.example.tld. This can be done
> with only one host update command in multi-copy.
>
> (b) Mass updates (II). As far as I can see, the single-copy model won't
> support any kind of moving name servers into the zone, you would always
> need to run update commands for all domains. In most cases, this would
> work fine in the multi-copy model.
>
> That's the only things I can come up with right now.

I can see ability to do mass updates as a double edged sword. It is easy to trigger a massive database update and DNS glue records generation by a mistake with host update. It also opens big window of opportunities for DoS attacks.

Regards,

Janusz Sienkiewicz


> Hong,
>
> please see comments below...
>
> Asbjorn
>
> Liu, Hong wrote:
>
> > In terms of (3), you are making an assumption about server policy in
> > terms of who is eligible to query an external host using . What if the
> > server policy is any client is eligible to query a host object? Will
> > the server return 2303 if the client does not have a private copy
> > while there are many other private copies out there? How can a server
> > return multiple instances of the same external host in an response?
> >
> > So the only way out is to codify in the protocol that a client can
> > only its private copy for external hosts. This is in effect enforcing
> > a server policy. As discussed on the list many times before, the
> > protocol should be flexible enough to allow different policies, but
> > _not_ to enforce a specific policy. In addition, this is no longer an
> > implementation issue, it now becomes a protocol issue.
>
> I realize that the sponsoring registrar can only view his own copy of
> the host object, and even though this is not perfect, I don't think this
> is a big problem. There is not really any useful information related to
> an external host, the only thing that might be of interest is the status
> of the object.
>
> > As for whois, to avoid confusion, an end user now needs to use both
> > the hostname and the registrarID to query an external host. I would
> > not speculate how many end users really know or care about
> > registrarIDs. They use whois just want to find out if a host exists or
> > not. Plus, most of the whois implementations today do not provide
> > {hostname,registrarID} query capability. Are you suggesting that even
> > the whois part (and user behavior) needs to be modified in order to
> > accommodate the multi-copy model? Is it introducing more problems in
> > order to solve _a_ problem?
>
> This depends on how you implement it - the end user does not necessarily
> need to know the registrar name/id. For .name we simply return all the
> instances of the object, for example:
> http://www.nic.name/cgi-bin/whoisweb.cgi?type=public&page=query&d=d&qt=nameserver&q=NS.NEWDREAM.NET
>
> > In terms of the support for reference-based renaming, the
> > server-centric single-copy model does not prohibit such operation.
> > That is, a sponsoring registrar is still capable of renaming any
> > internal host objects created through it. The problem is
> > reference-based renaming for external host objects. In our single-copy
> > approach, this has to be done one-by-one.
> > However, for the multi-copy model, reference-based renaming only works
> > for massive external-to-external nameserver updates. For other cases,
> > it has to perform the nameserver updates one-by-one for most of the
> > domains:
>
> > (5) Partial updates. For example, both registrant A and registrant B
> > use ISP X's DNS hosting services. Suppose both A and B register their
> > domains through the same registrar R, using the same set of namesevers
> > provided by X that are external hosts. Now B decides to use ISP Y's
> > DNS hosting service instead. Suppose that the nameservers provided by
> > Y are also external hosts.
> > Then registrar R cannot just rename X's nameservers to Y's since A's
> > domains are still using X's nameservers. So R has to update B's
> > domains one-by-one.
>
> This could be done with only one host update command in a multi-copy
> universe.
>
> > (6) External-to-internal. Suppose ISP X is also a registrant of R. It
> > creates a set of internal hosts through R. So R is the sponsoring
> > registrar of these hosts. Then X decides to use these hosts as
> > nameservers to provide DNS hosting services to all the domains in the
> > same registry. Then R cannot just rename the external hosts to the
> > internal ones since those internal hosts already exist in the
> > registry. So R will have to update each domain of A and B one-by-one.
>
> Would be the same for single-copy and multi-copy...
>
> > Another scenario could be that R implicitly creates these internal
> > hosts by renaming the external hosts. In this case, R does not need to
> > update each domain of A and B one-by-one. However, other registrars
> > will have to update domains one-by-one: they cannot just rename their
> > private copies to the internal hosts since they are not the sponsoring
> > registrar of those internal hosts.
>
> Would be the same for single-copy and multi-copy...
>
> > (7) Internal-to-external. Suppose ISP X has an internal host sponsored
> > by R that is being used as a nameserver of other domains. Now X wants
> > to replace that with an external host. There are two cases to consider:
> > (a) R already has a private copy of the external host. Then R cannot
> > rename the internal host to the external host. Instead, R will have to
> > update each domain one-by-one that uses the internal host as nameserver.
>
> Would be the same for single-copy and multi-copy...
>
> > (b) R does not have a private copy of the external host. R can rename
> > the internal host to the external host without any problem since it is
> > the sponsoring registrar, and all domains sponsored by R that are
> > using the internal host as nameserver now points to the external host.
> > In both cases, domains sponsored by other registrars that use the
> > internal host as nameserver will have to be updated one-by-one. To
> > make things even worst, in the case of 7(b), before these updates are
> > completed, domains in other registrars will be pointing to private
> > copy of external host in R.
> > This violates the very principle of the multi-copy model!
>
> I think this was discussed on the list at some point. And I think this
> is the biggest "problem" we identified with the multi-copy solution.
>
> > In summary, I would like to get answers from the multi-copy proponents
> > for the following questions:
> >
> > (i) What are the advantages of the multi-copy model as compared to the
> > server-centric single-copy model?
>
> (a) Mass updates (I). In the single-copy model, a registrar potentially
> needs to do x thousand domain update commands when changing a name
> server name from ns1.example.tld to ns2.example.tld. This can be done
> with only one host update command in multi-copy.
>
> (b) Mass updates (II). As far as I can see, the single-copy model won't
> support any kind of moving name servers into the zone, you would always
> need to run update commands for all domains. In most cases, this would
> work fine in the multi-copy model.
>
> That's the only things I can come up with right now.
>
> I do see that the single-copy model solves the 7b-problem and
> potentially makes the transfer process a bit easier, and I guess it is
> all about if you want that or if you rather wanna make mass updates
> easier. I see strong and weak points with both solutions...
>
> > (ii) What are the complaints on the former client-centric single-copy
> > model that are not addressed by the server-centric single-copy model,
> > but are solved by the multi-copy model?
>
> Not having dealt with RRP registries, I cannot answer this :-).
>
> (Asbjorn)
>
> --
> Asbjorn Steira
> The Global Name Registry, Limited
>
> Information contained herein is Global Name Registry Proprietary Information and is made available to you because of your interest in our company.    This information is submitted in confidence and its disclosure to you is not intended to constitute public disclosure or authorization for disclosure to other parties.
> *****************
> What's your .name?
> Get one at www.name
> *****************

--------------8D1B10F3372B48254A8DCF1C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Asbjorn,
<p>please see comments below ...
<p>Asbjorn Steira wrote:
<p>> (a) Mass updates (I). In the single-copy model, a registrar potentially
<br>> needs to do x thousand domain update commands when changing a name
<br>> server name from ns1.example.tld to ns2.example.tld. This can be
done
<br>> with only one host update command in multi-copy.
<br>>
<br>> (b) Mass updates (II). As far as I can see, the single-copy model
won't
<br>> support any kind of moving name servers into the zone, you would
always
<br>> need to run update commands for all domains. In most cases, this
would
<br>> work fine in the multi-copy model.
<br>>
<br>> That's the only things I can come up with right now.
<p>I can see ability to do mass updates as a double edged sword. It is
easy to trigger a massive database update and DNS glue records generation
by a mistake with host update. It also opens big window of opportunities
for DoS attacks.
<p>Regards,
<p>Janusz Sienkiewicz
<br>&nbsp;
<blockquote TYPE=CITE>Hong,
<p>please see comments below...
<p>Asbjorn
<p>Liu, Hong wrote:
<p>> In terms of (3), you are making an assumption about server policy
in
<br>> terms of who is eligible to query an external host using . What if
the
<br>> server policy is any client is eligible to query a host object? Will
<br>> the server return 2303 if the client does not have a private copy
<br>> while there are many other private copies out there? How can a server
<br>> return multiple instances of the same external host in an response?
<br>>
<br>> So the only way out is to codify in the protocol that a client can
<br>> only its private copy for external hosts. This is in effect enforcing
<br>> a server policy. As discussed on the list many times before, the
<br>> protocol should be flexible enough to allow different policies, but
<br>> _not_ to enforce a specific policy. In addition, this is no longer
an
<br>> implementation issue, it now becomes a protocol issue.
<p>I realize that the sponsoring registrar can only view his own copy of
<br>the host object, and even though this is not perfect, I don't think
this
<br>is a big problem. There is not really any useful information related
to
<br>an external host, the only thing that might be of interest is the status
<br>of the object.
<p>> As for whois, to avoid confusion, an end user now needs to use both
<br>> the hostname and the registrarID to query an external host. I would
<br>> not speculate how many end users really know or care about
<br>> registrarIDs. They use whois just want to find out if a host exists
or
<br>> not. Plus, most of the whois implementations today do not provide
<br>> {hostname,registrarID} query capability. Are you suggesting that
even
<br>> the whois part (and user behavior) needs to be modified in order
to
<br>> accommodate the multi-copy model? Is it introducing more problems
in
<br>> order to solve _a_ problem?
<p>This depends on how you implement it - the end user does not necessarily
<br>need to know the registrar name/id. For .name we simply return all
the
<br>instances of the object, for example:
<br><a href="http://www.nic.name/cgi-bin/whoisweb.cgi?type=public&page=query&d=d&qt=nameserver&q=NS.NEWDREAM.NET">http://www.nic.name/cgi-bin/whoisweb.cgi?type=public&amp;page=query&amp;d=d&amp;qt=nameserver&amp;q=NS.NEWDREAM.NET</a>
<p>> In terms of the support for reference-based renaming, the
<br>> server-centric single-copy model does not prohibit such operation.
<br>> That is, a sponsoring registrar is still capable of renaming any
<br>> internal host objects created through it. The problem is
<br>> reference-based renaming for external host objects. In our single-copy
<br>> approach, this has to be done one-by-one.
<br>> However, for the multi-copy model, reference-based renaming only
works
<br>> for massive external-to-external nameserver updates. For other cases,
<br>> it has to perform the nameserver updates one-by-one for most of the
<br>> domains:
<p>> (5) Partial updates. For example, both registrant A and registrant
B
<br>> use ISP X's DNS hosting services. Suppose both A and B register their
<br>> domains through the same registrar R, using the same set of namesevers
<br>> provided by X that are external hosts. Now B decides to use ISP Y's
<br>> DNS hosting service instead. Suppose that the nameservers provided
by
<br>> Y are also external hosts.
<br>> Then registrar R cannot just rename X's nameservers to Y's since
A's
<br>> domains are still using X's nameservers. So R has to update B's
<br>> domains one-by-one.
<p>This could be done with only one host update command in a multi-copy
<br>universe.
<p>> (6) External-to-internal. Suppose ISP X is also a registrant of R.
It
<br>> creates a set of internal hosts through R. So R is the sponsoring
<br>> registrar of these hosts. Then X decides to use these hosts as
<br>> nameservers to provide DNS hosting services to all the domains in
the
<br>> same registry. Then R cannot just rename the external hosts to the
<br>> internal ones since those internal hosts already exist in the
<br>> registry. So R will have to update each domain of A and B one-by-one.
<p>Would be the same for single-copy and multi-copy...
<p>> Another scenario could be that R implicitly creates these internal
<br>> hosts by renaming the external hosts. In this case, R does not need
to
<br>> update each domain of A and B one-by-one. However, other registrars
<br>> will have to update domains one-by-one: they cannot just rename their
<br>> private copies to the internal hosts since they are not the sponsoring
<br>> registrar of those internal hosts.
<p>Would be the same for single-copy and multi-copy...
<p>> (7) Internal-to-external. Suppose ISP X has an internal host sponsored
<br>> by R that is being used as a nameserver of other domains. Now X wants
<br>> to replace that with an external host. There are two cases to consider:
<br>> (a) R already has a private copy of the external host. Then R cannot
<br>> rename the internal host to the external host. Instead, R will have
to
<br>> update each domain one-by-one that uses the internal host as nameserver.
<p>Would be the same for single-copy and multi-copy...
<p>> (b) R does not have a private copy of the external host. R can rename
<br>> the internal host to the external host without any problem since
it is
<br>> the sponsoring registrar, and all domains sponsored by R that are
<br>> using the internal host as nameserver now points to the external
host.
<br>> In both cases, domains sponsored by other registrars that use the
<br>> internal host as nameserver will have to be updated one-by-one. To
<br>> make things even worst, in the case of 7(b), before these updates
are
<br>> completed, domains in other registrars will be pointing to private
<br>> copy of external host in R.
<br>> This violates the very principle of the multi-copy model!
<p>I think this was discussed on the list at some point. And I think this
<br>is the biggest "problem" we identified with the multi-copy solution.
<p>> In summary, I would like to get answers from the multi-copy proponents
<br>> for the following questions:
<br>>
<br>> (i) What are the advantages of the multi-copy model as compared to
the
<br>> server-centric single-copy model?
<p>(a) Mass updates (I). In the single-copy model, a registrar potentially
<br>needs to do x thousand domain update commands when changing a name
<br>server name from ns1.example.tld to ns2.example.tld. This can be done
<br>with only one host update command in multi-copy.
<p>(b) Mass updates (II). As far as I can see, the single-copy model won't
<br>support any kind of moving name servers into the zone, you would always
<br>need to run update commands for all domains. In most cases, this would
<br>work fine in the multi-copy model.
<p>That's the only things I can come up with right now.
<p>I do see that the single-copy model solves the 7b-problem and
<br>potentially makes the transfer process a bit easier, and I guess it
is
<br>all about if you want that or if you rather wanna make mass updates
<br>easier. I see strong and weak points with both solutions...
<p>> (ii) What are the complaints on the former client-centric single-copy
<br>> model that are not addressed by the server-centric single-copy model,
<br>> but are solved by the multi-copy model?
<p>Not having dealt with RRP registries, I cannot answer this :-).
<p>(Asbjorn)
<p>--
<br>Asbjorn Steira
<br>The Global Name Registry, Limited
<p>Information contained herein is Global Name Registry Proprietary Information
and is made available to you because of your interest in our company.&nbsp;&nbsp;&nbsp;
This information is submitted in confidence and its disclosure to you is
not intended to constitute public disclosure or authorization for disclosure
to other parties.
<br>*****************
<br>What's your .name?
<br>Get one at www.name
<br>*****************</blockquote>
</html>

--------------8D1B10F3372B48254A8DCF1C--



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA1FAWcE022049 for <[e-mail]>; Fri, 1 Nov 2002 16:10:32 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gA1FAWu7022048 for ietf-provreg-outgoing; Fri, 1 Nov 2002 16:10:32 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gA1FAUcE022043 for <[e-mail]>; Fri, 1 Nov 2002 16:10:31 +0100 (MET)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id gA1F9llU048682 for <[e-mail]>; Fri, 1 Nov 2002 10:09:47 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: FYI: I-D ACTION:draft-brunner-epp-data-considerations-00.txt
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 01 Nov 2002 10:09:47 -0500
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

------- Forwarded Message

Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-brunner-epp-data-considerations-00.txt
Date: Fri, 01 Nov 2002 08:41:19 -0500
Sender: [e-mail]
Precedence: bulk

- --NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: EPP Data Considerations
	Author(s)	: E. Brunner-Williams
	Filename	: draft-brunner-epp-data-considerations-00.txt
	Pages		: 16
	Date		: 2002-10-31
	
This memo discusses data collection considerations and EPP. It is
far from complete, but deadlines press.
Distribution of this document is unlimited.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-brunner-epp-data-considerations-00.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-brunner-epp-data-considerations-00.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-brunner-epp-data-considerations-00.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-brunner-epp-data-considerations-00.txt

- --OtherAccess
Content-Type: Message/External-body;
	name="draft-brunner-epp-data-considerations-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

- --OtherAccess--

- --NextPart--




------- End of Forwarded Message