Re: Handling of External Host Objects: Single vs. Multi Copy Solu tions (was: in the context of domain transfer)

[Mike Lampson <[e-mail]>]

Dear all,

As a consumer of EPP and RRP, I'm not happy with this change but can live
with it if necessary.

However, I do not see any discussion in sections 3.1.1 of either the
draft-ietf-provreg-epp-domain-05.txt or draft-ietf-provreg-epp-host-05.txt
specs on the <check> command.

I believe that the spec should explicitly state that the <check> command
will return "1" (available) if an external host object has not been
previously created by this client.  This will bring to the the attention of
the client that they need to issue an <add> host command prior to modifying
a domain to use this external host object.  This behavior is distinctly
different from the result returned to a <check> domain on an internal host
object.

I apologize in advance if I missed this information in the current specs.

Regards,

Mike Lampson
The Registry at Info Avenue, LLC





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 g9VIkBcE012728 for <[e-mail]>; Thu, 31 Oct 2002 19:46:11 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9VIkBcd012727 for ietf-provreg-outgoing; Thu, 31 Oct 2002 19:46:11 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp01.infoave.net (smtp01.infoave.net [165.166.0.26]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g9VIkAcE012722 for <[e-mail]>; Thu, 31 Oct 2002 19:46:10 +0100 (MET)
Received: from ML ([165.166.145.85]) by SMTP00.InfoAve.Net (PMDF V6.1-1X1 #38777) with SMTP id <[e-mail]> for [e-mail]; Thu, 31 Oct 2002 13:43:30 -0500 (EST)
Date: Thu, 31 Oct 2002 13:43:29 -0500
From: Mike Lampson <[e-mail]>
Subject: Re: Handling of External Host Objects: Single vs. Multi Copy Solu tions (was: in the context of domain transfer)
To: "'ietf-provregcafaxse'" <[e-mail]>
Cc: Liu Hong <[e-mail]>
Message-id: <01a301c2810d$67cf6c00$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Dear all,

As a consumer of EPP and RRP, I'm not happy with this change but can live
with it if necessary.

However, I do not see any discussion in sections 3.1.1 of either the
draft-ietf-provreg-epp-domain-05.txt or draft-ietf-provreg-epp-host-05.txt
specs on the <check> command.

I believe that the spec should explicitly state that the <check> command
will return "1" (available) if an external host object has not been
previously created by this client.  This will bring to the the attention of
the client that they need to issue an <add> host command prior to modifying
a domain to use this external host object.  This behavior is distinctly
different from the result returned to a <check> domain on an internal host
object.

I apologize in advance if I missed this information in the current specs.

Regards,

Mike Lampson
The Registry at Info Avenue, LLC




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 g9VHjncE012123 for <[e-mail]>; Thu, 31 Oct 2002 18:45:49 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9VHjnaH012122 for ietf-provreg-outgoing; Thu, 31 Oct 2002 18:45:49 +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 g9VHjlcE012117 for <[e-mail]>; Thu, 31 Oct 2002 18:45:48 +0100 (MET)
Received: (qmail 7482 invoked by alias); 31 Oct 2002 17:45:46 -0000
Received: from unknown (HELO gnr-mailsweeper.gnr.com) (213.105.192.220) by muk-gnrmx-01.gnr.com with SMTP; 31 Oct 2002 17:45:46 -0000
Received: from gnr-exch01.gnr.com (unverified) by gnr-mailsweeper.gnr.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]>; Thu, 31 Oct 2002 17:50:13 +0000
Received: from gnr.com ([192.168.3.23]) by gnr-exch01.gnr.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 31 Oct 2002 17:45:46 +0000
Message-ID: <[e-mail]>
Date: Thu, 31 Oct 2002 17:46:16 +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: "Liu, Hong" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Handling of External Host Objects: Single vs. Multi Copy Solu tions (was: in the context of domain transfer)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 31 Oct 2002 17:45:46.0133 (UTC) FILETIME=[576C4C50:01C28105]
Sender: [e-mail]
Precedence: bulk

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



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 g9VFMTcE010283 for <[e-mail]>; Thu, 31 Oct 2002 16:22:29 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9VFMT5Z010282 for ietf-provreg-outgoing; Thu, 31 Oct 2002 16:22:29 +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 g9VFMRcE010277 for <[e-mail]>; Thu, 31 Oct 2002 16:22:28 +0100 (MET)
Received: from andrew by mail.libertyrms.com with local (Exim 3.22 #3 (Debian)) id 187H9P-0006VB-00 for <[e-mail]>; Thu, 31 Oct 2002 10:22:27 -0500
Date: Thu, 31 Oct 2002 10:22:27 -0500
From: Andrew Sullivan <[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)
Message-ID: <[e-mail]>
Mail-Followup-To: Andrew Sullivan <[e-mail]>, "'[e-mail]'" <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Oct 30, 2002 at 06:37:34PM -0500
Sender: [e-mail]
Precedence: bulk

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 g9UNbDcE002620 for <[e-mail]>; Thu, 31 Oct 2002 00:37:13 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9UNbDLf002619 for ietf-provreg-outgoing; Thu, 31 Oct 2002 00:37:13 +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 g9UNbBcE002611 for <[e-mail]>; Thu, 31 Oct 2002 00:37:12 +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 g9UNbAb02663 for <[e-mail]>; Wed, 30 Oct 2002 23:37:11 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <VLY1K218>; Wed, 30 Oct 2002 18:37:45 -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: Wed, 30 Oct 2002 18:37:34 -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

Jim,

The issue at hand is _not_ what is technically feasible at all cost, but
what requires the least amount of work to get the job done. The
server-centric single-copy approach can accomplish the same goal without
incurring those extra works 1)-4), and other issues described in this email.

In terms of (3), you are making an assumption about server policy in terms
of who is eligible to query an external host using <info>. 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 <info> response?

So the only way out is to codify in the protocol that a client can only
<info> 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.

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?

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.

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

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. 

(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!

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?

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

I would really like to be convinced that the multi-copy model is justified
in spite of all the problems uncovered in this and previous emails.

--Hong

-----Original Message-----
From: Gould, James [mailto:[e-mail]]
Sent: Wednesday, October 30, 2002 3:48 PM
To: '[e-mail]'; 'Liu, Hong'
Subject: RE: Handling of External Host Objects: Single vs. Multi Copy
Solu tions (was: in the context of domain transfer)


Hong,

I understand the motivation for supporting multi-copy external hosts.  Let
me address each one of your concerns:

1) Waste of storage space - An external host is light weight and supporting
a set of external hosts per registrar has not been an area of concern in the
registries that I've worked on.  

2) management on a per client basis - Supporting multi-copy external hosts
is extra effort when you have to consider host name changes and transfers,
but it is technically feasible.

3) keeping the state consistent - I don't understand the issue with
consistency, since the information that is presented should be based on the
context of the current EPP session.  If registrar A starts an EPP session,
than any host info commands should respond with registrar A's external host
information.  If registrar A does not have the external host, than the
response should be 2303 "Object does not exist".  It is up to you how you
want to present the information in whois.  You could allow for the passing
of the registrar id, provide back a list of hosts including the registrar
id, etc..    

4) complexity of transfers - Supporting multi-copy external hosts does
represent more effort when it comes to implementing transfer, but it is
technically feasible.  The ability to rename a host which automatically
changes the domain references is an important requirement/feature.  I don't
know of any requests for partial renames.  

I don't believe the only advantage is to "facilitate the massive renaming of
external nameservers", since the support for reference based renaming is a
core requirement with a single copy or multi-copy approach.   I believe that
the single copy approach was a significant complaint with RRP and providing
support for multi-copy external hosts was hammered out a long while back.  

After implementing multi-copy external hosts along with transfer, I do
appreciate the extra effort involved, but I believe this is an
implementation issue and not a protocol issue.  

Jim 

> facilitate the
> massive renaming of external nameservers
> ----------
> From: 	Liu, Hong
> Sent: 	Wednesday, October 30, 2002 2:23 PM
> To: 	'[e-mail]'
> Subject: 	RE: Handling of External Host Objects: Single vs. Multi Copy
> Solu tions (was: in the context of domain transfer)
> 
> Jim, Asbjorn,
> 
> I would like to focus this thread on the advantages and disadvantages of
> Single vs. Multi- copy solutions for external host objects.
> 
> To recap the discussion on the list, the motivation of dealing with
> external
> host objects on a per-client basis is the ownership problem. Since
> external
> hosts are outside of the registry namespace, no one, including the
> registry
> itself, has exact knowledge about the external hosts. In a word, nobody
> actually "owns" an external host as far as the registry is concerned.  
> 
> The only use of an external host object in EPP is as a nameserver for
> domains of the registry. It merely serves as a pointer to an external
> entity. External host objects are not transferred as a result of
> associated
> domain transfer.
> 
> Before epp domain mapping -04, external host objects are created by
> clients
> on a FCFS basis. There is a single-copy of an external host in the
> registry.
> Whoever registrar first created an external host becomes the sponsoring
> registrar of that object. As such, no other registrars will be able to do
> much on the external host object except using it as a nameserver. There
> are
> various headaches stem out of this client-centric single-copy ownership
> model. Specifically, when the sponsoring registrar rename the external
> host
> object, all domains that use it as nameserver are changed implicitly. This
> has very undesirable effects on domains that are sponsored by other
> registrars but use the external host as a nameserver. First, these other
> registrars do not know such a change, and some domains may not want to
> change to the new nameserver. Second, once the change is discovered after
> the fact, these registrars will have to undo the change for all these
> affected domains one-by-one.  
> 
> To resolve this problem, in epp domain mapping -04, a client-centric
> multi-copy ownership model was adopted, and the model was carried over to
> the latest epp domain mapping -05. However, after careful study, we find
> the
> multi-copy ownership model only partially solves the update problem. In
> addition, it introduces a whole lot of complexity into external host
> handling, such as:
> 
> (1) Waste of storage space on the server side. Imagine that a registry has
> 100 registars, and each has a private copy of an external host. Then there
> will be 100 private copies of host objects in the registry serving as
> pointers to a single external entity. It is not uncommon in many
> registries
> other than com/net/org where the majority of the nameservers are external
> host objects.
> 
> (2) For all these private copies, the server has to specially manage them
> on
> a per-client basis, i.e., {hostname, clID} pairs. This undoubtly and
> unnessarily complicates the server software.
> 
> (3) Since each client updates its private copy individually, it is very
> difficult to keep the state of these objects consistent. Of particular
> difficulty is the presentation of such information to queries based only
> on
> hostname. 
> 
> For example, in Whois, what result will be returned for a query on an
> external object? All of the instances, none, randomly one? It is extremely
> confusing, especially when different instances have different statii, say
> one is "ok" while the other is "clientUpdateProhibited", the third is
> "linked", and the forth is without "linked" status. 
> 
> Similarly, what will be the rules for response to the <info> command from
> a
> client, only its private copy? What happen if the client does not have a
> private copy? Should the server return all, none, randomly one? Note that
> the current <info> response is not equipped with returning information for
> multiple instances.
> 
> (4) It introduces undue complexity involving domain transfer, as we have
> discussed in some details already. External hosts are not in-zone hosts,
> as
> such they should not be involved in domain transfer. With the multi-copy
> model, it requires special handling of external hosts used as nameservers,
> as side-effects of domain transfer.
> 
> Most importantly, the multi-copy model does not solve the external host
> rename problem completely. It just limits the problem from registry-wide
> to
> registrar-wide. It is true that a single rename of the private copy will
> result in all domains pointing to a different external host as a
> nameserver.
> But what happen for partial update within the same registrar? If some of
> the
> domains want to retain the old external host namesever, the registrar will
> still have to do the update one-by-one. There is no other way around. Note
> that this only covers massive renaming from the external to external case,
> for external to internal or internal to external, the registrar will still
> have to do it one-by-one if the internal host is not sponsored by the
> registrar.
> 
> So if the only advantage of the multi-copy model is to facilitate the
> massive renaming of external nameservers, then I would say that the cost
> is
> too high to warrant such convenience. On the contrary, a server-centric
> single-copy model solves the ownership problem in a much simpler and more
> effective fashion, and yet does not introduce those undue complexity
> mentioned above.
> 
> Cheers,
> 
> --Hong
> 
> 


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 g9UKmQcE001041 for <[e-mail]>; Wed, 30 Oct 2002 21:48:26 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9UKmQlr001040 for ietf-provreg-outgoing; Wed, 30 Oct 2002 21:48: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 g9UKmPcE001035 for <[e-mail]>; Wed, 30 Oct 2002 21:48:25 +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 PAA13370; Wed, 30 Oct 2002 15:48:24 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <V87JTHP9>; Wed, 30 Oct 2002 15:44:34 -0500
Message-ID: <[e-mail]>
From: "Gould, James" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Liu, Hong'" <[e-mail]>
Subject: RE: Handling of External Host Objects: Single vs. Multi Copy Solu tions (was: in the context of domain transfer)
Date: Wed, 30 Oct 2002 15:48:23 -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

Hong,

I understand the motivation for supporting multi-copy external hosts.  Let
me address each one of your concerns:

1) Waste of storage space - An external host is light weight and supporting
a set of external hosts per registrar has not been an area of concern in the
registries that I've worked on.  

2) management on a per client basis - Supporting multi-copy external hosts
is extra effort when you have to consider host name changes and transfers,
but it is technically feasible.

3) keeping the state consistent - I don't understand the issue with
consistency, since the information that is presented should be based on the
context of the current EPP session.  If registrar A starts an EPP session,
than any host info commands should respond with registrar A's external host
information.  If registrar A does not have the external host, than the
response should be 2303 "Object does not exist".  It is up to you how you
want to present the information in whois.  You could allow for the passing
of the registrar id, provide back a list of hosts including the registrar
id, etc..    

4) complexity of transfers - Supporting multi-copy external hosts does
represent more effort when it comes to implementing transfer, but it is
technically feasible.  The ability to rename a host which automatically
changes the domain references is an important requirement/feature.  I don't
know of any requests for partial renames.  

I don't believe the only advantage is to "facilitate the massive renaming of
external nameservers", since the support for reference based renaming is a
core requirement with a single copy or multi-copy approach.   I believe that
the single copy approach was a significant complaint with RRP and providing
support for multi-copy external hosts was hammered out a long while back.  

After implementing multi-copy external hosts along with transfer, I do
appreciate the extra effort involved, but I believe this is an
implementation issue and not a protocol issue.  

Jim 

> facilitate the
> massive renaming of external nameservers
> ----------
> From: 	Liu, Hong
> Sent: 	Wednesday, October 30, 2002 2:23 PM
> To: 	'[e-mail]'
> Subject: 	RE: Handling of External Host Objects: Single vs. Multi Copy
> Solu tions (was: in the context of domain transfer)
> 
> Jim, Asbjorn,
> 
> I would like to focus this thread on the advantages and disadvantages of
> Single vs. Multi- copy solutions for external host objects.
> 
> To recap the discussion on the list, the motivation of dealing with
> external
> host objects on a per-client basis is the ownership problem. Since
> external
> hosts are outside of the registry namespace, no one, including the
> registry
> itself, has exact knowledge about the external hosts. In a word, nobody
> actually "owns" an external host as far as the registry is concerned.  
> 
> The only use of an external host object in EPP is as a nameserver for
> domains of the registry. It merely serves as a pointer to an external
> entity. External host objects are not transferred as a result of
> associated
> domain transfer.
> 
> Before epp domain mapping -04, external host objects are created by
> clients
> on a FCFS basis. There is a single-copy of an external host in the
> registry.
> Whoever registrar first created an external host becomes the sponsoring
> registrar of that object. As such, no other registrars will be able to do
> much on the external host object except using it as a nameserver. There
> are
> various headaches stem out of this client-centric single-copy ownership
> model. Specifically, when the sponsoring registrar rename the external
> host
> object, all domains that use it as nameserver are changed implicitly. This
> has very undesirable effects on domains that are sponsored by other
> registrars but use the external host as a nameserver. First, these other
> registrars do not know such a change, and some domains may not want to
> change to the new nameserver. Second, once the change is discovered after
> the fact, these registrars will have to undo the change for all these
> affected domains one-by-one.  
> 
> To resolve this problem, in epp domain mapping -04, a client-centric
> multi-copy ownership model was adopted, and the model was carried over to
> the latest epp domain mapping -05. However, after careful study, we find
> the
> multi-copy ownership model only partially solves the update problem. In
> addition, it introduces a whole lot of complexity into external host
> handling, such as:
> 
> (1) Waste of storage space on the server side. Imagine that a registry has
> 100 registars, and each has a private copy of an external host. Then there
> will be 100 private copies of host objects in the registry serving as
> pointers to a single external entity. It is not uncommon in many
> registries
> other than com/net/org where the majority of the nameservers are external
> host objects.
> 
> (2) For all these private copies, the server has to specially manage them
> on
> a per-client basis, i.e., {hostname, clID} pairs. This undoubtly and
> unnessarily complicates the server software.
> 
> (3) Since each client updates its private copy individually, it is very
> difficult to keep the state of these objects consistent. Of particular
> difficulty is the presentation of such information to queries based only
> on
> hostname. 
> 
> For example, in Whois, what result will be returned for a query on an
> external object? All of the instances, none, randomly one? It is extremely
> confusing, especially when different instances have different statii, say
> one is "ok" while the other is "clientUpdateProhibited", the third is
> "linked", and the forth is without "linked" status. 
> 
> Similarly, what will be the rules for response to the <info> command from
> a
> client, only its private copy? What happen if the client does not have a
> private copy? Should the server return all, none, randomly one? Note that
> the current <info> response is not equipped with returning information for
> multiple instances.
> 
> (4) It introduces undue complexity involving domain transfer, as we have
> discussed in some details already. External hosts are not in-zone hosts,
> as
> such they should not be involved in domain transfer. With the multi-copy
> model, it requires special handling of external hosts used as nameservers,
> as side-effects of domain transfer.
> 
> Most importantly, the multi-copy model does not solve the external host
> rename problem completely. It just limits the problem from registry-wide
> to
> registrar-wide. It is true that a single rename of the private copy will
> result in all domains pointing to a different external host as a
> nameserver.
> But what happen for partial update within the same registrar? If some of
> the
> domains want to retain the old external host namesever, the registrar will
> still have to do the update one-by-one. There is no other way around. Note
> that this only covers massive renaming from the external to external case,
> for external to internal or internal to external, the registrar will still
> have to do it one-by-one if the internal host is not sponsored by the
> registrar.
> 
> So if the only advantage of the multi-copy model is to facilitate the
> massive renaming of external nameservers, then I would say that the cost
> is
> too high to warrant such convenience. On the contrary, a server-centric
> single-copy model solves the ownership problem in a much simpler and more
> effective fashion, and yet does not introduce those undue complexity
> mentioned above.
> 
> Cheers,
> 
> --Hong
> 
> 


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 g9UJMYcE029785 for <[e-mail]>; Wed, 30 Oct 2002 20:22:34 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9UJMYmk029784 for ietf-provreg-outgoing; Wed, 30 Oct 2002 20:22:34 +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 g9UJMXcE029779 for <[e-mail]>; Wed, 30 Oct 2002 20:22:33 +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 g9UJMWb25656 for <[e-mail]>; Wed, 30 Oct 2002 19:22:32 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <VLY1KF3Y>; Wed, 30 Oct 2002 14:23:07 -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: Wed, 30 Oct 2002 14:23:01 -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

Jim, Asbjorn,

I would like to focus this thread on the advantages and disadvantages of
Single vs. Multi- copy solutions for external host objects.

To recap the discussion on the list, the motivation of dealing with external
host objects on a per-client basis is the ownership problem. Since external
hosts are outside of the registry namespace, no one, including the registry
itself, has exact knowledge about the external hosts. In a word, nobody
actually "owns" an external host as far as the registry is concerned.  

The only use of an external host object in EPP is as a nameserver for
domains of the registry. It merely serves as a pointer to an external
entity. External host objects are not transferred as a result of associated
domain transfer.

Before epp domain mapping -04, external host objects are created by clients
on a FCFS basis. There is a single-copy of an external host in the registry.
Whoever registrar first created an external host becomes the sponsoring
registrar of that object. As such, no other registrars will be able to do
much on the external host object except using it as a nameserver. There are
various headaches stem out of this client-centric single-copy ownership
model. Specifically, when the sponsoring registrar rename the external host
object, all domains that use it as nameserver are changed implicitly. This
has very undesirable effects on domains that are sponsored by other
registrars but use the external host as a nameserver. First, these other
registrars do not know such a change, and some domains may not want to
change to the new nameserver. Second, once the change is discovered after
the fact, these registrars will have to undo the change for all these
affected domains one-by-one.  

To resolve this problem, in epp domain mapping -04, a client-centric
multi-copy ownership model was adopted, and the model was carried over to
the latest epp domain mapping -05. However, after careful study, we find the
multi-copy ownership model only partially solves the update problem. In
addition, it introduces a whole lot of complexity into external host
handling, such as:

(1) Waste of storage space on the server side. Imagine that a registry has
100 registars, and each has a private copy of an external host. Then there
will be 100 private copies of host objects in the registry serving as
pointers to a single external entity. It is not uncommon in many registries
other than com/net/org where the majority of the nameservers are external
host objects.

(2) For all these private copies, the server has to specially manage them on
a per-client basis, i.e., {hostname, clID} pairs. This undoubtly and
unnessarily complicates the server software.

(3) Since each client updates its private copy individually, it is very
difficult to keep the state of these objects consistent. Of particular
difficulty is the presentation of such information to queries based only on
hostname. 

For example, in Whois, what result will be returned for a query on an
external object? All of the instances, none, randomly one? It is extremely
confusing, especially when different instances have different statii, say
one is "ok" while the other is "clientUpdateProhibited", the third is
"linked", and the forth is without "linked" status. 

Similarly, what will be the rules for response to the <info> command from a
client, only its private copy? What happen if the client does not have a
private copy? Should the server return all, none, randomly one? Note that
the current <info> response is not equipped with returning information for
multiple instances.

(4) It introduces undue complexity involving domain transfer, as we have
discussed in some details already. External hosts are not in-zone hosts, as
such they should not be involved in domain transfer. With the multi-copy
model, it requires special handling of external hosts used as nameservers,
as side-effects of domain transfer.

Most importantly, the multi-copy model does not solve the external host
rename problem completely. It just limits the problem from registry-wide to
registrar-wide. It is true that a single rename of the private copy will
result in all domains pointing to a different external host as a nameserver.
But what happen for partial update within the same registrar? If some of the
domains want to retain the old external host namesever, the registrar will
still have to do the update one-by-one. There is no other way around. Note
that this only covers massive renaming from the external to external case,
for external to internal or internal to external, the registrar will still
have to do it one-by-one if the internal host is not sponsored by the
registrar.

So if the only advantage of the multi-copy model is to facilitate the
massive renaming of external nameservers, then I would say that the cost is
too high to warrant such convenience. On the contrary, a server-centric
single-copy model solves the ownership problem in a much simpler and more
effective fashion, and yet does not introduce those undue complexity
mentioned above.

Cheers,

--Hong




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 g9UHWWcE028188 for <[e-mail]>; Wed, 30 Oct 2002 18:32:32 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9UHWWvI028187 for ietf-provreg-outgoing; Wed, 30 Oct 2002 18:32:32 +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 g9UHWUcE028182 for <[e-mail]>; Wed, 30 Oct 2002 18:32:31 +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 g9UHWUYm022381 for <[e-mail]>; Wed, 30 Oct 2002 12:32:30 -0500 (EST)
Received: from [192.35.167.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA25123; Wed, 30 Oct 2002 12:32:28 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b09b9e5c728fbd3@[192.35.167.226]>
Date: Wed, 30 Oct 2002 09:32:26 -0800
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: more comments from the IESG
Cc: [e-mail]
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id g9UHWVcE028183
Sender: [e-mail]
Precedence: bulk

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 g9UFqZcE026747 for <[e-mail]>; Wed, 30 Oct 2002 16:52:35 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9UFqYix026746 for ietf-provreg-outgoing; Wed, 30 Oct 2002 16:52:34 +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 g9UFqWcE026741 for <[e-mail]>; Wed, 30 Oct 2002 16:52:33 +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 g9UFqVb17562 for <[e-mail]>; Wed, 30 Oct 2002 15:52:32 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <VLY1KDCY>; Wed, 30 Oct 2002 10:53:07 -0500
Message-ID: <[e-mail]>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Handling of External Host Objects (in the context of domain t ransfer) 
Date: Wed, 30 Oct 2002 10:53:03 -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

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 [mailto:[e-mail]]
Sent: Wednesday, October 30, 2002 9:13 AM
To: '[e-mail]'; 'Liu, Hong'
Subject: RE: Handling of External Host Objects (in the context of domain
t ransfer) 


Hong,

[snip]
> 
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

> ----------
> From: 	Liu, Hong
> Sent: 	Tuesday, October 29, 2002 8:09 PM
> To: 	'[e-mail]'
> 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?
[snip]


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 g9UEDLcE025588 for <[e-mail]>; Wed, 30 Oct 2002 15:13:21 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9UEDLWP025587 for ietf-provreg-outgoing; Wed, 30 Oct 2002 15:13:21 +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 g9UEDKcE025582 for <[e-mail]>; Wed, 30 Oct 2002 15:13:20 +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 JAA19160; Wed, 30 Oct 2002 09:13:19 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <V5C2KQ5Y>; Wed, 30 Oct 2002 09:13:18 -0500
Message-ID: <[e-mail]>
From: "Gould, James" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Liu, Hong'" <[e-mail]>
Subject: RE: Handling of External Host Objects (in the context of domain t ransfer) 
Date: Wed, 30 Oct 2002 09:13:18 -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

Hong,

	I've dealt with this issue, it is more straight forward than what
you have described.  To address your question of  "why registrar A can avoid
> massive update on all 1267 domains at the EPP protocol level", is because
> the host name should not be the foreign key from the domains in the
> Registry database.  Changing a host name (external to external, external
> to internal, internal to external) should not change the database
> relationships.  The changing of name servers in RRP does not require
> explicit or implicit updates to the delegating domains, and this is also
> the case with EPP.  This is truly an implementation issue and not a
> protocol issue.  Implementation of the registry database and associated
> business rules can accomplish the intent of the protocol without impacting
> registrars.  
> 
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

> ----------
> From: 	Liu, Hong
> Sent: 	Tuesday, October 29, 2002 8:09 PM
> To: 	'[e-mail]'
> 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?
> Quote:
> "The problem with this is that when registrar A in the (for example)
> dotInfo
> registry later wants to rename his host ns1.example.com to for example
> ns1.example.info (i.e., moving it into the zone), he would have to first
> create the new host, and then update all the 1267 domains using
> ns1.example.com to use the new host. This is not a problem in the current
> solution. "
> Answer:
> Yes, this can be inconvenient, but with good reasons. If this is the only
> problem, then I believe the benefits of the single copy solution far
> outweights the multi-copy one.
>  First and foremost, I would like you to explain why registrar A can avoid
> massive update on all 1267 domains at the EPP protocol level  (not at the
> registry DB level). Host objects are associated with domains via the <ns>
> element, and the value of that element is the host name. Are you saying
> that
> the 1267 domains using ns1.example.com as a nameserver do not need to be
> changed to ns1.example.info in the corresponding <ns> field, while the
> host
> object ns1.example.com is renamed to ns1.example.info? 
> Note that we are talking about explicit client-initiated operations, not
> implicit registry server operations. Scott has said many times on this
> list
> that implicit server operations are bad, and I agree. I don't think that
> renaming an external host should implicitly trigger the registry server to
> update all the domains using that host as nameserver.
> Most importantly, renaming a host object (internal or external) while it
> is
> linked with other domains is a _very bad_ idea since doing so creates all
> sorts of inconsistency problems for domains that reference the host
> object.
> Host objects are identified externally by hostnames in EPP. Changing a
> hostname is equivalent to creating another object, since the external
> handle
> of the object has changed. 
> I would not go as far to ban such operation in EPP, but the best common
> practice should RECOMMEND NOT DOING SO.
> --Hong
> 
> [1] http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00102.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 g9UE66cE025484 for <[e-mail]>; Wed, 30 Oct 2002 15:06:06 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9UE65cp025483 for ietf-provreg-outgoing; Wed, 30 Oct 2002 15:06:05 +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 g9UE64cE025478 for <[e-mail]>; Wed, 30 Oct 2002 15:06:05 +0100 (MET)
Received: (qmail 24959 invoked by alias); 30 Oct 2002 14:05:58 -0000
Received: from unknown (HELO gnr-mailsweeper.gnr.com) (213.105.192.220) by muk-gnrmx-01.gnr.com with SMTP; 30 Oct 2002 14:05:58 -0000
Received: from gnr-exch01.gnr.com (unverified) by gnr-mailsweeper.gnr.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]>; Wed, 30 Oct 2002 12:28:17 +0000
Received: from gnr.com ([192.168.3.23]) by gnr-exch01.gnr.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 30 Oct 2002 12:23:50 +0000
Message-ID: <[e-mail]>
Date: Wed, 30 Oct 2002 12:24: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: "Liu, Hong" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Handling of External Host Objects (in the context of domain t ransfer)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Oct 2002 12:23:50.0427 (UTC) FILETIME=[33F3B6B0:01C2800F]
Sender: [e-mail]
Precedence: bulk

Hi Hong,


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


It might not be 100% clear, but my understanding of the sentence is 
*not* that the external host object must be owned by the (potentially) 
gaining registrar, but that he must have an external host object with 
the same name server name in his name space.

> [SNIP] First and foremost, I would like you to explain why registrar A 
> can avoid massive update on all 1267 domains at the EPP protocol level 
>  (not at the registry DB level). Host objects are associated with 
> domains via the element, and the value of that element is the host 
> name. Are you saying that the 1267 domains using ns1.example.com as a 
> nameserver do not need to be changed to ns1.example.info in the 
> corresponding  field, while the host object ns1.example.com is renamed 
> to ns1.example.info? 


Yes, host objects are in a sense associated with domains names using the 
host name, but it links to the host object, not the host name directly. 
So by changing the name of a host from for example ns1.example.tld to 
ns2.example.tld, all the 1267 domain names will be automatically updated 
to use the new name name server, which to me makes perfect sense.

> Note that we are talking about explicit client-initiated operations, 
> not implicit registry server operations. Scott has said many times on 
> this list that implicit server operations are bad, and I agree. I 
> don't think that renaming an external host should implicitly trigger 
> the registry server to update all the domains using that host as 
> nameserver.


If one views hosts as separate objects, and domains as separate objects 
linking to host objects, a change of host name only changes the name of 
*one* object, it does not trigger a registry server to update domains. 
But the change will be reflected in all domains linking to the name 
server object we updated. So, to me this is not implicit registry server 
operations.

> Most importantly, renaming a host object (internal or external) while 
> it is linked with other domains is a _very bad_ idea since doing so 
> creates all sorts of inconsistency problems for domains that reference 
> the host object.
> Host objects are identified externally by hostnames in EPP. Changing a
> hostname is equivalent to creating another object, since the external 
> handle of the object has changed.
> I would not go as far to ban such operation in EPP, but the best 
> common practice should RECOMMEND NOT DOING SO.


I beg to differ :-). I think renaming a host object is very powerful for 
corporations/people handling numerous domain names. Being able to change 
host name only once instead of 1267 times makes life much simpler.


Asbjorn


PS  "Why 1267?"



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 g9U3LLcE021079 for <[e-mail]>; Wed, 30 Oct 2002 04:21:21 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9U3LLGe021078 for ietf-provreg-outgoing; Wed, 30 Oct 2002 04:21:21 +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 g9U3LFcE021073 for <[e-mail]>; Wed, 30 Oct 2002 04:21:15 +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 g9U3L5lU032897; Tue, 29 Oct 2002 22:21:05 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Julian Mack <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: Internationalized vs. localized 
In-Reply-To: Your message of "Tue, 29 Oct 2002 14:46:49 GMT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 29 Oct 2002 22:21:05 -0500
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> Imagine you've sent a letter addressed to a contact.

OK. I've imagined a 3 and 5/8th by 6 1/2 inch (9.2 x 16.5 cm) envelope,
with a cheery seasonal note card inside, addressed to Ms. Ima Spook.

> A letter with an "Internationalized" address (in ASCII) can be read and
> delivered by any mailman in the world.

Hmm. I've used characters in the set [A-Z][a-z][0-9][-,.], but as they are
on a paper medium, I've really no idea how they are encoded. My IBM Selectric
may be partial to EBCDIC, it does have a sense of mechanical humor, or it may
consider characters on paper to be an uncoded character set.

I forgot to ask my letter carrier if he can read ASCII. I wonder if he is
more comfortable with binary, octal, hex, or decimal?

> A letter with a "Localized" address (in full UTF-8) can only be read by
> mailmen who can read the local script.

I've never actually encountered a person, regardless of profession, outside
of the handful that make up the UTC, who can read UTF-8. I used to hang up
all the bit patterns for each multi-octet sequence for EUC and HP15 in my
offices at Building 5 (Sun) and at COSL (HP), and even so, I never could
"read" with any facility. Maybe they have better letter carriers in the UK.

Cheers,
Eric


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 g9U1vlcE019743 for <[e-mail]>; Wed, 30 Oct 2002 02:57:47 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9U1vlfU019742 for ietf-provreg-outgoing; Wed, 30 Oct 2002 02:57:47 +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 g9U1vfcE019737 for <[e-mail]>; Wed, 30 Oct 2002 02:57:41 +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 g9U1vYHe027497 for <[e-mail]>; Wed, 30 Oct 2002 02:57:34 +0100 (CET) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id g9U1vXYG027496 for [e-mail]; Wed, 30 Oct 2002 02:57:34 +0100 (CET)
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g9TEkrcE013056 for <[e-mail]>; Tue, 29 Oct 2002 15:46:53 +0100 (MET)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <VQ7L75X9>; Tue, 29 Oct 2002 14:46:41 -0000
Message-ID: <[e-mail]>
From: Julian Mack <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Internationalized vs. localized
Date: Tue, 29 Oct 2002 14:46:49 -0000
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

A good way of not getting the two confused is this:

Imagine you've sent a letter addressed to a contact.

A letter with an "Internationalized" address (in ASCII) can be read and
delivered by any mailman in the world.

A letter with a "Localized" address (in full UTF-8) can only be read by
mailmen who can read the local script.

---------------------------------------
Julian Mack
Developer

Poptel Ltd.
The ISP with a mission to: connect * inform * empower

www.poptel.coop

---------------------------------------



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 g9U18pcE019342 for <[e-mail]>; Wed, 30 Oct 2002 02:08:51 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9U18psc019341 for ietf-provreg-outgoing; Wed, 30 Oct 2002 02:08:51 +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 g9U18ncE019336 for <[e-mail]>; Wed, 30 Oct 2002 02:08:50 +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 g9U18mb31259 for <[e-mail]>; Wed, 30 Oct 2002 01:08:48 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <VLY1J029>; Tue, 29 Oct 2002 20:09:22 -0500
Message-ID: <[e-mail]>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Re: Handling of External Host Objects (in the context of domain t ransfer) 
Date: Tue, 29 Oct 2002 20:09:12 -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, 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?
Quote:
"The problem with this is that when registrar A in the (for example) dotInfo
registry later wants to rename his host ns1.example.com to for example
ns1.example.info (i.e., moving it into the zone), he would have to first
create the new host, and then update all the 1267 domains using
ns1.example.com to use the new host. This is not a problem in the current
solution. "
Answer:
Yes, this can be inconvenient, but with good reasons. If this is the only
problem, then I believe the benefits of the single copy solution far
outweights the multi-copy one.
 First and foremost, I would like you to explain why registrar A can avoid
massive update on all 1267 domains at the EPP protocol level  (not at the
registry DB level). Host objects are associated with domains via the <ns>
element, and the value of that element is the host name. Are you saying that
the 1267 domains using ns1.example.com as a nameserver do not need to be
changed to ns1.example.info in the corresponding <ns> field, while the host
object ns1.example.com is renamed to ns1.example.info? 
Note that we are talking about explicit client-initiated operations, not
implicit registry server operations. Scott has said many times on this list
that implicit server operations are bad, and I agree. I don't think that
renaming an external host should implicitly trigger the registry server to
update all the domains using that host as nameserver.
Most importantly, renaming a host object (internal or external) while it is
linked with other domains is a _very bad_ idea since doing so creates all
sorts of inconsistency problems for domains that reference the host object.
Host objects are identified externally by hostnames in EPP. Changing a
hostname is equivalent to creating another object, since the external handle
of the object has changed. 
I would not go as far to ban such operation in EPP, but the best common
practice should RECOMMEND NOT DOING SO.
--Hong

[1] http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00102.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 g9TLKocE017356 for <[e-mail]>; Tue, 29 Oct 2002 22:20:50 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9TLKnvA017355 for ietf-provreg-outgoing; Tue, 29 Oct 2002 22:20:49 +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 g9TLKkcE017350 for <[e-mail]>; Tue, 29 Oct 2002 22:20:47 +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 QAA22832; Tue, 29 Oct 2002 16:20:45 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <V5C2J72D>; Tue, 29 Oct 2002 16:20:44 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Stephane Bortzmeyer'" <[e-mail]>, [e-mail]
Subject: RE: Internationalized vs. localized
Date: Tue, 29 Oct 2002 16:20:41 -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 vocabulary is very strange: the international form should be the
> encoding allowing full use of Unicode (here, UTF-8). Because it is the
> form that works in every country.
> 
> A form restricted to US-ASCII should be named "local" because it will
> work only in some countries. I suggest to swap "internationalized" and
> "localized" in the above text. Or to use less ambiguous words like
> "Full repertoire" and "Subset".

Nope.  "Internationalized" in this context refers to global readability and
"localized" refers to local readability.  Think of this in the context of
international business and the reason you wrote your note in English as an
example.

-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 g9THWUcE015223 for <[e-mail]>; Tue, 29 Oct 2002 18:32:30 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9THWUTt015222 for ietf-provreg-outgoing; Tue, 29 Oct 2002 18:32:30 +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 g9THWScE015217 for <[e-mail]>; Tue, 29 Oct 2002 18:32:29 +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 g9THWKlU030183; Tue, 29 Oct 2002 12:32:20 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: proposed agenda 
In-Reply-To: Your message of "Tue, 29 Oct 2002 09:05:21 PST." <a05111b0ab9e46d7f9be8@[192.35.167.226]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 29 Oct 2002 12:32:20 -0500
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ed,

I don't plan to attend the Atlanta meeting. That can shave 40 minutes off
the face-to-face schedule.

Eric


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 g9TH5IcE014928 for <[e-mail]>; Tue, 29 Oct 2002 18:05:18 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9TH5IKG014927 for ietf-provreg-outgoing; Tue, 29 Oct 2002 18:05:18 +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 g9TH5GcE014921 for <[e-mail]>; Tue, 29 Oct 2002 18:05:17 +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 g9TH5FYm086514 for <[e-mail]>; Tue, 29 Oct 2002 12:05:15 -0500 (EST)
Received: from [192.35.167.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA24977; Tue, 29 Oct 2002 12:05:13 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b0ab9e46d7f9be8@[192.35.167.226]>
Date: Tue, 29 Oct 2002 09:05:21 -0800
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: proposed agenda
Cc: Edward Lewis <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

I need to turn this over quick, just so there's something available. 
No matter what goes into the sec., it can be changed, but let's try 
this for starters:

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

2. IESG issues with base
       Congestion control 15 mins.
       Reliability        15 mins.
       Privacy
          Intro           10 mins. (Setting the "tone")
          Text fr. Scott  20 mins.
          Text fr. Eric   20 mins. (I haven't retrieved and read his ref. yet.)

3. SOAP individ submission
       20 mins.

4. SMTP individ submission
       20 mins.

That's 5+15+15+10+20+20+20+20 = 35+30+60 = 2:05 of a 2:30 slot 
(assuming we aren't reassigned).

5. Extensions guidelines draft...

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

(Who said there was nothing to cover in Atlanta. ;))

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 g9TG19cE014145 for <[e-mail]>; Tue, 29 Oct 2002 17:01:09 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9TG19V7014144 for ietf-provreg-outgoing; Tue, 29 Oct 2002 17:01:09 +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 g9TG18cE014139 for <[e-mail]>; Tue, 29 Oct 2002 17:01:08 +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 g9TG14lU029771; Tue, 29 Oct 2002 11:01:04 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Stephane Bortzmeyer <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: Internationalized vs. localized 
In-Reply-To: Your message of "Tue, 29 Oct 2002 15:16:36 +0100." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 29 Oct 2002 11:01:04 -0500
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Stephen,

We've got

    <simpleType name="postalInfoEnumType">
      <restriction base="token">
        <enumeration value="loc"/>
        <enumeration value="int"/>
      </restriction>
    </simpleType>

I wanted to leave open the possibility of using something other than
ASCII (or UTF-8) for Postal information. So I requested a change which
is the addition of the "type" option to the <postalInfo> element. Some
others in the WG saw use in this, so we have it circa -05.

My idea of the use-case is a postal address encoded in Big5 for some
registrant in Taiwan, as an example.

What string is used to designate each value in the enum set I left to
the editor.

Is the non-normative text in draft-ietf-provreg-epp-contact-05.txt, 3.1.2,
correct? Every instance of interoperability is compromise.

It is simply wrong where it suggests that an XML conformant parser is going
to fail if the charset isn't UTF-8. Fortunately, if implementors assume the
language of 3.1.2 is controlling, that simply means they will be doing a
codeset conversion before emitting data, which wouldn't bother implementors
strictly following the XML standard for charsets.

Incidently, I don't agree with the statement that "Unicode (here, UTF-8)
is the form that works in every country". My time in Beijing with the CDNC
and JET was fairly corrosive of that belief-system, as was time spent with
Nii Quanor on African Languages, or time spent on Indigenous Languages of
the Americas. Mind, these aren't all exactly "DNS growth markets", but I
do care about one in particular.

The better distinction, in my mind, is between 7bit, and 8bit, which may
or may not be identical to some particular 7bit when restricted to just
7bits. Viz.,

    <simpleType name="postalInfoEnumType">
      <restriction base="token">
        <enumeration value="7bits"/>
        <enumeration value="8bits"/>
      </restriction>
    </simpleType>

Anyway, who cares what color the bikeshed is painted, so long as it fits
an ASCII bike for the bitwise handicapped, a UTF-8 bike for the Universalists,
and an 8-bit bike for bicyclists?

Scott,

The "MUST" on lines 610 and 931 and 1322 can be changed to "MAY", and be in
accord with the "MAY" at lines 297 (Individual and Organizational Names),
306 (Address), 612 (ibid). As these aren't normative, its discretionary to
the as editor as far as I'm concerned.

Cheers,
Eric


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 g9TEGmcE012784 for <[e-mail]>; Tue, 29 Oct 2002 15:16:48 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9TEGmJH012783 for ietf-provreg-outgoing; Tue, 29 Oct 2002 15:16:48 +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 g9TEGicE012778 for <[e-mail]>; Tue, 29 Oct 2002 15:16:47 +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 g9TEGchA1032966 for <[e-mail]>; Tue, 29 Oct 2002 15:16:38 +0100 (CET)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id 0CDBFFF88; Tue, 29 Oct 2002 15:16:36 +0100 (CET)
Date: Tue, 29 Oct 2002 15:16:36 +0100
From: Stephane Bortzmeyer <[e-mail]>
To: [e-mail]
Subject: Internationalized vs. localized
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

In draft-ietf-provreg-epp-contact-05.txt, one can read:

  - One or two <contact:postalInfo> elements that contain postal address
  information.  Two elements are provided so that address information
  can be provided in both internationalized and localized forms; a
  "type" attribute is used to identify the two forms.  If an
  internationalized form (type="int") is provided, element content MUST
  be represented in a subset of UTF-8 that can be represented in the 7-
  bit US-ASCII character set.  If a localized form (type="loc") is
  provided, element content MAY be represented in unrestricted UTF-8.

The vocabulary is very strange: the international form should be the
encoding allowing full use of Unicode (here, UTF-8). Because it is the
form that works in every country.

A form restricted to US-ASCII should be named "local" because it will
work only in some countries. I suggest to swap "internationalized" and
"localized" in the above text. Or to use less ambiguous words like
"Full repertoire" and "Subset".




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 g9TAPOcE010786 for <[e-mail]>; Tue, 29 Oct 2002 11:25:24 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9TAPOXm010785 for ietf-provreg-outgoing; Tue, 29 Oct 2002 11:25:24 +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 g9TAPNcE010780 for <[e-mail]>; Tue, 29 Oct 2002 11:25:23 +0100 (MET)
Received: (qmail 14057 invoked by alias); 29 Oct 2002 10:25:20 -0000
Received: from unknown (HELO gnr-mailsweeper.gnr.com) (213.105.192.220) by muk-gnrmx-01.gnr.com with SMTP; 29 Oct 2002 10:25:20 -0000
Received: from gnr-exch01.gnr.com (unverified) by gnr-mailsweeper.gnr.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]>; Tue, 29 Oct 2002 10:29:47 +0000
Received: from gnr.com ([192.168.3.23]) by gnr-exch01.gnr.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 29 Oct 2002 10:25:19 +0000
Message-ID: <[e-mail]>
Date: Tue, 29 Oct 2002 10:26:14 +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: "Liu, Hong" <[e-mail]>
CC: [e-mail]
Subject: Re: Handling of External Host Objects (in the context of domain trans fer)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 Oct 2002 10:25:19.0294 (UTC) FILETIME=[7AF92DE0:01C27F35]
Sender: [e-mail]
Precedence: bulk

[Time to unlurk]

Hi Liu,

please see below for comments...




Liu, Hong wrote:

> Ed, Scott, et al,
>
[SNIP]

>
> Here are the issues with EPP-07:
>
> (1) External host objects are managed on a per-registrar basis in a
> regsitry. There could be more than one instances of the same external host
> object in the registry. In reality,  uniquely identifies an
> external host object. This requires special handling of external hosts at
> the registry DB level. It also complicates registrar admin to deal 
> with all
> these external objects.

Yes, it does require some special handling of external hosts, but I am 
not sure it complicates things too much for registrars. Instead of 
having to worry and deal with other registrars' external hosts, they 
merely have to think about their own set of external hosts.

[SNIP]

> This implies that in order to do a domain transfer, the registrant 
> must first ask the current registrar (i.e., the losing registrar) to 
> remove the link to the external object, then ask the gaining registrar 
> to create one if it does not exist. The only problem is that if all 
> domain nameservers are external objects. The registrant will lose DNS 
> service during the transfer pending period, and thus be discouraged 
> from doing transfer at all. 

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.


> (A) At most one instance of an external object is allowed in a registry.
> (B) The registry is the neutral owner of all external objects, i.e.,
> is the registry, not any registrar.
> (C) A registrar can create an external host if the host does not exists in
> the registry. The registrar will be recorded in  of the external host
> object.
> (D) A registrar cannot delete or update an external host. To change a
> nameserver to another external host, just create one or point to another
> existing one.
> (E) The registry may perform garbage collection on those external 
> hosts that
> are not linked by a server-defined period of time.
> (F) As for transfer, the links to external hosts remain unchanged. No 
> extra
> work needs to be done, by the registry, or by the two registrars involved.
>
> Since most of the problems regarding handling of external host objects 
> are related to who owns the data, centralizing the management to the 
> registry eliminates the ownership controversy and its raminifications, 
> allowing external host objects be handled in a uniform and simple fashion.

The problem with this is that when registrar A in the (for example) 
dotInfo registry later wants to rename his host ns1.example.com to for 
example ns1.example.info (i.e., moving it into the zone), he would have 
to first create the new host, and then update all the 1267 domains using 
ns1.example.com to use the new host. This is not a problem in the 
current solution.



Regards,

Asbjorn

-- 
Asbjorn Steira
Senior Developer
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 g9SMRncE005446 for <[e-mail]>; Mon, 28 Oct 2002 23:27:49 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9SMRme4005445 for ietf-provreg-outgoing; Mon, 28 Oct 2002 23:27: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 g9SMRlcE005440 for <[e-mail]>; Mon, 28 Oct 2002 23:27:48 +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 g9SMRlb24706 for <[e-mail]>; Mon, 28 Oct 2002 22:27:47 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <VLY1JWHC>; Mon, 28 Oct 2002 17:28:19 -0500
Message-ID: <[e-mail]>
From: "Liu, Hong" <[e-mail]>
To: [e-mail]
Subject: Handling of External Host Objects (in the context of domain trans fer)
Date: Mon, 28 Oct 2002 17:28:08 -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, Scott, et al,

As indicated in my previous posting, I would like to bring up this topic
again to the list. I understand that that the related texts were introduced
in EPP-06, and related topics were heavily debated before EPP-06. However,
there are still lingering issues in the specs. This email serves two
purposes: to identify the problems in current spec, and to present a
strawman proposal to fix these problems.

I apologize in advance for this long email. I have tried to keep the
description short for these complicated issues without losing the details.

Here are the issues with EPP-07:

(1) External host objects are managed on a per-registrar basis in a
regsitry. There could be more than one instances of the same external host
object in the registry. In reality, <hostname, clID> uniquely identifies an
external host object. This requires special handling of external hosts at
the registry DB level. It also complicates registrar admin to deal with all
these external objects.

(2) To transfer a domain, if a domain contains a link to an external host
object as one of its nameserver, the following condition MUST be met in
order for a transfer request to be accepted by the server:
(a) The domain cannot refer to the external object of the losing registrar,
and
(b) A copy of the external object must exist in the gaining registrar.
The same conditions MUST also hold at the time the transfer is approved.
See
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-05.txt,
Section 3.2.4 EPP <transfer> Command, page 25, last paragraph.

This implies that in order to do a domain transfer, the registrant must
first ask the current registrar (i.e., the losing registrar) to remove the
link to the external object, then ask the gaining registrar to create one if
it does not exist. The only problem is that if all domain nameservers are
external objects. The registrant will lose DNS service during the transfer
pending period, and thus be discouraged from doing transfer at all. 

One may say that removing condition (a) will solve the problem. Yes, it
solves the problem if the standard specifies that by the time of transfer is
completed, the registry should do the switch-over of pointers to external
hosts from the losing registrar to the gaining registrar in one DB
transaction before approving the request.

I think that the multi-copy solution is kludgy for both registries and
registrars. I have a simpler one-copy proposal: 
[NOTE: I understand that it is late in the process. I just want to make sure
that solution works and it is simple.] 

(A) At most one instance of an external object is allowed in a registry.
(B) The registry is the neutral owner of all external objects, i.e., <clID>
is the registry, not any registrar.
(C) A registrar can create an external host if the host does not exists in
the registry. The registrar will be recorded in <crID> of the external host
object.
(D) A registrar cannot delete or update an external host. To change a
nameserver to another external host, just create one or point to another
existing one.
(E) The registry may perform garbage collection on those external hosts that
are not linked by a server-defined period of time.
(F) As for transfer, the links to external hosts remain unchanged. No extra
work needs to be done, by the registry, or by the two registrars involved.

Since most of the problems regarding handling of external host objects are
related to who owns the data, centralizing the management to the registry
eliminates the ownership controversy and its raminifications, allowing
external host objects be handled in a uniform and simple fashion.

--Hong


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 g9SM67cE005257 for <[e-mail]>; Mon, 28 Oct 2002 23:06:07 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9SM66rP005256 for ietf-provreg-outgoing; Mon, 28 Oct 2002 23:06:06 +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 g9SM65cE005251 for <[e-mail]>; Mon, 28 Oct 2002 23:06:06 +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 g9SM64b24184 for <[e-mail]>; Mon, 28 Oct 2002 22:06:04 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <VLY1JWCA>; Mon, 28 Oct 2002 17:06:37 -0500
Message-ID: <[e-mail]>
From: "Liu, Hong" <[e-mail]>
To: [e-mail]
Subject: RE: we are meeting in atlanta
Date: Mon, 28 Oct 2002 17:06: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

Ed,

I would like to add one more topic to the discussion in Atlanta: handling of
external host objects.

We identified some issues with the current spec, primarily in the context of
domain transfer. However, this has other implications as well. I will shoot
out an email to the list shortly.

--Hong

-----Original Message-----
From: Edward Lewis [mailto:[e-mail]]
Sent: Monday, October 28, 2002 11:59 AM
To: [e-mail]
Cc: Edward Lewis
Subject: we are meeting in atlanta


Given the discussion following the IESG comments on the core 
documents, a request was made to meet in Atlanta.  I asked (at the 
11th hour) and there was a spot for us.  We have a 2.5 hour slot, 
which should be more than enough to discuss what we *need* to cover.

Now I need to send in an agenda.  The primary topic will be, of 
course, the IESG comments, specifically the privacy comment and maybe 
some other issue that is slipping my mind right now.  Other possible 
topics are:

the guidelines document (a wg item now)
the SOAP mapping document (an individual item)
the SMTP mapping document (an individual item)

Other implementation issues that might be popping up.

Please send suggestions as soon as you can.

 From the draft agenda:

>AS OF OCTOBER 28, 2002
>
>DRAFT Agenda of the Fifty-fifth IETF
>TUESDAY, November 19, 2002
>0900-1130 Morning Sessions
>APP     provreg     Provisioning Registry Protocol WG
>APP     xmpp        Extensible Messaging and Presence Protocol BOF
>INT     zerouter    Zeroconf Router BOF
>SEC     msec        Multicast Security WG
>SEC     secsh       Secure Shell WG
>SUB     mpls        Multiprotocol Label Switching WG
>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 g9SLmgcE004999 for <[e-mail]>; Mon, 28 Oct 2002 22:48:42 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9SLmg7K004998 for ietf-provreg-outgoing; Mon, 28 Oct 2002 22:48:42 +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 g9SLmecE004993 for <[e-mail]>; Mon, 28 Oct 2002 22:48: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 QAA22715; Mon, 28 Oct 2002 16:48:39 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <V5C2244B>; Mon, 28 Oct 2002 16:48:38 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, [e-mail]
Subject: RE: we are meeting in atlanta
Date: Mon, 28 Oct 2002 16:48: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

> Please send suggestions as soon as you can.

I'd also like to see a discussion of Rick's "lastVerified" suggestion.

-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 g9SKaQcE004326 for <[e-mail]>; Mon, 28 Oct 2002 21:36:26 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9SKaQCG004325 for ietf-provreg-outgoing; Mon, 28 Oct 2002 21:36:26 +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 g9SKaOcE004320 for <[e-mail]>; Mon, 28 Oct 2002 21:36:25 +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 g9SKaNb20784; Mon, 28 Oct 2002 20:36:24 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <VLY1JVD2>; Mon, 28 Oct 2002 15:36:56 -0500
Message-ID: <[e-mail]>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: [Ietf-not43] Re: Last-Verified Date Contact Element
Date: Mon, 28 Oct 2002 15:36: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

Rick,

I have similar concerns. I still don't know what this new element is for and
how it is going to be used.

I specifically quote Eric's email as important to note:

"It is true these elements are managed by the registry, but they are done so
in response to client-initiated events."

In particular, without getting a clear explanation on what "verification"
means, I assume that it is the registrars' responsibility to do whatever
"verification" required, since it is the registrars that interface with the
registrants.

I don't mean to bring policy issues into this discussion. I just don't know
if we can address this issue in a vacuum.

--Hong

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:[e-mail]]
Sent: Sunday, October 27, 2002 9:29 AM
To: Rick Wesson
Cc: Eric Brunner-Williams in Portland Maine; [e-mail];
'[e-mail]'; [e-mail];
[e-mail]; [e-mail]
Subject: [Ietf-not43] Re: Last-Verified Date Contact Element


Rick,

I asked:

> > What prevents a client providing some authInfo from also attempting to
set
> > upID and set or modify upDate?

You replied:

> the updated date and last-modified date are managed by the registry.

Here's what I ment:

The <contact:upID> is an <info> response element that contains the
identifier
of the client that last updated the contact object. The <contact:clID>
element
that contains the identifier of the sponsoring client. This client has the
valid authInfo, and can perform an <update> on the contact object in
question.
If that client wants to date-stamp/touch a client object for the purpose of
associating some temporal identifier to "verification" (and I still don't
know wha that means), isn't this the recipie? This either sets or modifies
the <contact:upID> and sets or modifies the <contact:upDate>.

It is true these elements are managed by the registry, but they are done so
in response to client-initiated events.

I guess I'm still in the dark about the mechanism, as well as the purpose,
and utility.

Color me clueless,
Eric
_______________________________________________
Ietf-not43 mailing list
[e-mail]
http://lists.verisignlabs.com/mailman/listinfo/ietf-not43


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 g9SJbUcE003669 for <[e-mail]>; Mon, 28 Oct 2002 20:37:30 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9SJbUdw003668 for ietf-provreg-outgoing; Mon, 28 Oct 2002 20:37:30 +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 g9SJbScE003663 for <[e-mail]>; Mon, 28 Oct 2002 20:37:29 +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 g9SJbYlU025032; Mon, 28 Oct 2002 14:37:34 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: we are meeting in atlanta 
In-Reply-To: Your message of "Mon, 28 Oct 2002 08:59:05 PST." <a05111b06b9e31a3a13a4@[192.35.167.226]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 28 Oct 2002 14:37:34 -0500
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ed,

I thought traditionally the ultra-delayed and miscreants had Friday morning
to themselves.

In no particular order, there is:

Rick's garbage collection note (protocol),
Patrik's/Scott's congestion control considered manditory note (transport),
Patrik's reliability considered manditory note (transport),
Randy's/Patrik's/Scott's element-wise binary toggle note (protocol),
Hong's soap I-D (transport),
Eric's smtp I-D (transport),
Eric's little note on the element-wise binary toggle note (protocol),

As the author of two of these, I don't mind if they aren't on your agenda.

Cheers,
Eric


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 g9SH5QcE002230 for <[e-mail]>; Mon, 28 Oct 2002 18:05:26 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9SH5Qqp002229 for ietf-provreg-outgoing; Mon, 28 Oct 2002 18:05:26 +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 g9SH5PcE002224 for <[e-mail]>; Mon, 28 Oct 2002 18:05:25 +0100 (MET)
Received: from repligate ([67.36.182.14]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20021028170524.MNDR19775.mailhost.chi1.ameritech.net@repligate>; Mon, 28 Oct 2002 11:05:24 -0600
Message-ID: <03af01c27ea4$41b7dc20$0100a8c0@repligate>
From: "Jim Fleming" <[e-mail]>
To: <[e-mail]>, "Edward Lewis" <[e-mail]>
References: <a05111b06b9e31a3a13a4@[192.35.167.226]>
Subject: Re: we are meeting in atlanta
Date: Mon, 28 Oct 2002 11:05:45 -0600
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: "Edward Lewis" <[e-mail]>
 a request was made to meet in Atlanta. 
===

What does "Various Registries" indicate ?

http://www.iana.org/assignments/ipv4-address-space
(last updated 2002-10-25)
"Various Registries"

===
Are "Various Registries" included in "we" ?

Jim Fleming
128-bit DNS is closer than you think...
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




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 g9SGx8cE002135 for <[e-mail]>; Mon, 28 Oct 2002 17:59:08 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9SGx8u1002134 for ietf-provreg-outgoing; Mon, 28 Oct 2002 17:59:08 +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 g9SGx6cE002129 for <[e-mail]>; Mon, 28 Oct 2002 17:59:07 +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 g9SGx4Ym035913 for <[e-mail]>; Mon, 28 Oct 2002 11:59:04 -0500 (EST)
Received: from [192.35.167.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA13705; Mon, 28 Oct 2002 11:59:03 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b06b9e31a3a13a4@[192.35.167.226]>
Date: Mon, 28 Oct 2002 08:59:05 -0800
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: we are meeting in atlanta
Cc: Edward Lewis <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Given the discussion following the IESG comments on the core 
documents, a request was made to meet in Atlanta.  I asked (at the 
11th hour) and there was a spot for us.  We have a 2.5 hour slot, 
which should be more than enough to discuss what we *need* to cover.

Now I need to send in an agenda.  The primary topic will be, of 
course, the IESG comments, specifically the privacy comment and maybe 
some other issue that is slipping my mind right now.  Other possible 
topics are:

the guidelines document (a wg item now)
the SOAP mapping document (an individual item)
the SMTP mapping document (an individual item)

Other implementation issues that might be popping up.

Please send suggestions as soon as you can.

 From the draft agenda:

>AS OF OCTOBER 28, 2002
>
>DRAFT Agenda of the Fifty-fifth IETF
>TUESDAY, November 19, 2002
>0900-1130 Morning Sessions
>APP     provreg     Provisioning Registry Protocol WG
>APP     xmpp        Extensible Messaging and Presence Protocol BOF
>INT     zerouter    Zeroconf Router BOF
>SEC     msec        Multicast Security WG
>SEC     secsh       Secure Shell WG
>SUB     mpls        Multiprotocol Label Switching WG
>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 g9SEjKcE000747 for <[e-mail]>; Mon, 28 Oct 2002 15:45:20 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9SEjKxq000746 for ietf-provreg-outgoing; Mon, 28 Oct 2002 15:45:20 +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 g9SEjIcE000741 for <[e-mail]>; Mon, 28 Oct 2002 15:45:19 +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 g9SEjTlU023741; Mon, 28 Oct 2002 09:45:29 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
cc: [e-mail]
Subject: data collection considerations and EPP
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 28 Oct 2002 09:45:28 -0500
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Again, this somewhat 1/2 baked, but comments are welcome.

Available via ftp from [216.220.241.233]
        user=anonymous
        pswd=guest (or whatever, prizes for the inventive)
        file=pub/draft-brunner-epp-data-considerations-00.txt,html

Comments to me please, I like writing acknowledgements.

Eric


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 g9S6D0cE026079 for <[e-mail]>; Mon, 28 Oct 2002 07:13:00 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9S6Cxs8026078 for ietf-provreg-outgoing; Mon, 28 Oct 2002 07:12:59 +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 g9S6CwcE026072 for <[e-mail]>; Mon, 28 Oct 2002 07:12:58 +0100 (MET)
Received: from bean (bean [66.123.187.68]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g9S6CvFP025475; Sun, 27 Oct 2002 22:12:58 -0800 (PST)
Date: Sun, 27 Oct 2002 22:12:57 -0800 (PST)
From: Rick Wesson <[e-mail]>
To: "Liu, Hong" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Last-Verified Date Contact Element
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

the utility of the last-verified attribute does have dual purposes that a
registry could apply to contacts that are linked or not; i don't know of a
registry that garbage collects any contact data, today, its up to the
registrar to do that function.

as i've stated before, i'd like to keep the politics and policy out of the
ietf and leave it to the responsible party.

-rick

On Sun, 27 Oct 2002, Liu, Hongwrote:

> Rick,
> 
> Maybe I am slow in catching up with your thoughts here. So let me try to
> break down the issue into a series of questions. My goal is to understand
> exactly how that new element is going to be used.
> 
> What type of contact object you have in your mind? Are you talking about
> contact objects that are linked to domains with outdated contact information
> or contact objects that are _not_ linked to any domains? If you are talking
> about the latter type, that is the garbage collection I mentioned in my
> previous emails.
> 
> Your answer to this question will help clarify what this element is going to
> be used for.
> 
> Thanks!
> 
> --Hong
>  
> -----Original Message-----
> From: Rick Wesson [mailto:[e-mail]]
> Sent: Sunday, October 27, 2002 5:36 PM
> To: Liu, Hong
> Cc: '[e-mail]'
> Subject: RE: Last-Verified Date Contact Element
> 
> 
> 
> Hong,
> 
> as i stated before "verification" is a policy that is up to the registry
> to describe. i'm just talking about protocol elements not about how you 
> as a tld manager should implement it.
> 
> -rick
> 
> On Sun, 27 Oct 2002, Liu, Hong wrote:
> 
> > Rick,
> > 
> > I admit that I don't know all the activities going on with many other
> groups
> > and what requirements are there for this new element. Maybe you could
> share
> > with us how this element will be used and what exactly verification means.
> > Thanks!
> > 
> > --Hong
> > 
> > -----Original Message-----
> > From: Rick Wesson [mailto:[e-mail]]
> > Sent: Sunday, October 27, 2002 11:54 AM
> > To: Liu, Hong
> > Cc: '[e-mail]'
> > Subject: RE: Last-Verified Date Contact Element
> > 
> > 
> > 
> > the thought is not only garbage collection, but that we have the element
> > in the protocol to comply with future recomendations which many groups are
> > pulling for at the moment.
> > 
> > 
> > On Sun, 27 Oct 2002, Liu, Hong wrote:
> > 
> > > Rick,
> > > 
> > > I think you raise a good question about registry object maintenance. A
> > > similar problem also exists for host objects. However, I would like to
> > > understand why the new field is needed. If the sole purpose is for
> garbage
> > > collection in the registry, it can be done through registry internal
> > > book-keeping. What do you think?
> > > 
> > > --Hong
> > > 
> > > -----Original Message-----
> > > From: Rick Wesson [mailto:[e-mail]]
> > > Sent: Wednesday, October 23, 2002 11:35 AM
> > > To: [e-mail]
> > > Cc: '[e-mail]'; [e-mail];
> > > [e-mail]
> > > Subject: [Ietf-not43] Last-Verified Date Contact Element
> > > 
> > > 
> > > 
> > > Scott && IESG,
> > > 
> > > I realized that there is an item we have overlooked in the wg. In
> private
> > > conversations, myself and others have noted that there is no way to
> > > identify the last time a contact object was verified.
> > > 
> > > I propose that we add a "Last-Verified" date element to the contact
> object
> > > so that registries/registrars may express the last time the object was
> > > verified. Since contacts have no expiration date and the "last-modified"
> > > date is irreverent to verification.
> > > 
> > > I believe that this will aid in identifying old, stale and irreverent
> data
> > > within a registry and if the element is published in CRISP or whois to
> the
> > > community in general.
> > > 
> > > I know it is late in the game for identifing issues with the epp
> proposals
> > > so I have CCed the IESG.
> > > 
> > > -rick
> > > 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Ietf-not43 mailing list
> > > [e-mail]
> > > http://lists.verisignlabs.com/mailman/listinfo/ietf-not43
> > > 
> > 
> 



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 g9S49UcE025578 for <[e-mail]>; Mon, 28 Oct 2002 05:09:30 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9S49UVM025577 for ietf-provreg-outgoing; Mon, 28 Oct 2002 05:09: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 g9S49TcE025572 for <[e-mail]>; Mon, 28 Oct 2002 05:09: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 g9S49QYm001179; Sun, 27 Oct 2002 23:09:27 -0500 (EST)
Received: from [192.35.167.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id XAA12787; Sun, 27 Oct 2002 23:09:25 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b07b9e2682f2179@[192.35.167.226]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Sun, 27 Oct 2002 20:08:13 -0800
To: "Hollenbeck, Scott" <[e-mail]>, "'Edward Lewis'" <[e-mail]>, [e-mail]
From: Edward Lewis <[e-mail]>
Subject: RE: Guidelines doc
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 20:13 -0500 10/27/02, Hollenbeck, Scott wrote:
>>  This document seems to border on being a guideline vs. a
>>  requirement document.
>
>It's supposed to be a guidelines document.  Are you saying that it reads
>more like a requirements document?  If so, I could probably rephrase the way
>the 2119 directives are used to make the focus more clear.

Somewhat.  I don't have the paper on me at the moment to cite what 
passage gave me that idea.  (Try a search for "MUST" or "SHOULD". 
Telltale signs of requirements.)

>>  Section 2.3
>>
>>  Allowing a server to deny to a client access to an extension probably
>>  should migrate to the base spec.  Would this impact the state diagram?
>
>I don't think so as it's all part of the <login>
>authentication/authorization process.

Okay, but my coinciveness is only about 85% right now. ;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 g9S3AgcE025363 for <[e-mail]>; Mon, 28 Oct 2002 04:10:42 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9S3Agvr025362 for ietf-provreg-outgoing; Mon, 28 Oct 2002 04:10:42 +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 g9S3AecE025357 for <[e-mail]>; Mon, 28 Oct 2002 04:10:40 +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 g9S3Adb27498 for <[e-mail]>; Mon, 28 Oct 2002 03:10:39 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <VLY1JPFP>; Sun, 27 Oct 2002 22:11:10 -0500
Message-ID: <[e-mail]>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Last-Verified Date Contact Element
Date: Sun, 27 Oct 2002 22:11:03 -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

Rick,

Maybe I am slow in catching up with your thoughts here. So let me try to
break down the issue into a series of questions. My goal is to understand
exactly how that new element is going to be used.

What type of contact object you have in your mind? Are you talking about
contact objects that are linked to domains with outdated contact information
or contact objects that are _not_ linked to any domains? If you are talking
about the latter type, that is the garbage collection I mentioned in my
previous emails.

Your answer to this question will help clarify what this element is going to
be used for.

Thanks!

--Hong
 
-----Original Message-----
From: Rick Wesson [mailto:[e-mail]]
Sent: Sunday, October 27, 2002 5:36 PM
To: Liu, Hong
Cc: '[e-mail]'
Subject: RE: Last-Verified Date Contact Element



Hong,

as i stated before "verification" is a policy that is up to the registry
to describe. i'm just talking about protocol elements not about how you 
as a tld manager should implement it.

-rick

On Sun, 27 Oct 2002, Liu, Hong wrote:

> Rick,
> 
> I admit that I don't know all the activities going on with many other
groups
> and what requirements are there for this new element. Maybe you could
share
> with us how this element will be used and what exactly verification means.
> Thanks!
> 
> --Hong
> 
> -----Original Message-----
> From: Rick Wesson [mailto:[e-mail]]
> Sent: Sunday, October 27, 2002 11:54 AM
> To: Liu, Hong
> Cc: '[e-mail]'
> Subject: RE: Last-Verified Date Contact Element
> 
> 
> 
> the thought is not only garbage collection, but that we have the element
> in the protocol to comply with future recomendations which many groups are
> pulling for at the moment.
> 
> 
> On Sun, 27 Oct 2002, Liu, Hong wrote:
> 
> > Rick,
> > 
> > I think you raise a good question about registry object maintenance. A
> > similar problem also exists for host objects. However, I would like to
> > understand why the new field is needed. If the sole purpose is for
garbage
> > collection in the registry, it can be done through registry internal
> > book-keeping. What do you think?
> > 
> > --Hong
> > 
> > -----Original Message-----
> > From: Rick Wesson [mailto:[e-mail]]
> > Sent: Wednesday, October 23, 2002 11:35 AM
> > To: [e-mail]
> > Cc: '[e-mail]'; [e-mail];
> > [e-mail]
> > Subject: [Ietf-not43] Last-Verified Date Contact Element
> > 
> > 
> > 
> > Scott && IESG,
> > 
> > I realized that there is an item we have overlooked in the wg. In
private
> > conversations, myself and others have noted that there is no way to
> > identify the last time a contact object was verified.
> > 
> > I propose that we add a "Last-Verified" date element to the contact
object
> > so that registries/registrars may express the last time the object was
> > verified. Since contacts have no expiration date and the "last-modified"
> > date is irreverent to verification.
> > 
> > I believe that this will aid in identifying old, stale and irreverent
data
> > within a registry and if the element is published in CRISP or whois to
the
> > community in general.
> > 
> > I know it is late in the game for identifing issues with the epp
proposals
> > so I have CCed the IESG.
> > 
> > -rick
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Ietf-not43 mailing list
> > [e-mail]
> > http://lists.verisignlabs.com/mailman/listinfo/ietf-not43
> > 
> 


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 g9S1DucE023972 for <[e-mail]>; Mon, 28 Oct 2002 02:13:56 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9S1DuUP023971 for ietf-provreg-outgoing; Mon, 28 Oct 2002 02:13:56 +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 g9S1DscE023960 for <[e-mail]>; Mon, 28 Oct 2002 02:13:54 +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 UAA06510; Sun, 27 Oct 2002 20:13:53 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <TF9X8TXV>; Sun, 27 Oct 2002 20:13:53 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, [e-mail]
Subject: RE: Guidelines doc
Date: Sun, 27 Oct 2002 20:13:45 -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 document seems to border on being a guideline vs. a 
> requirement document.

It's supposed to be a guidelines document.  Are you saying that it reads
more like a requirements document?  If so, I could probably rephrase the way
the 2119 directives are used to make the focus more clear.

> Section 2.1
> 
> Besides an extension being "informational" it can also be 
> "experimental."

Sure, good point.

> Section 2.3
> 
> Allowing a server to deny to a client access to an extension probably 
> should migrate to the base spec.  Would this impact the state diagram?

I don't think so as it's all part of the <login>
authentication/authorization process.

-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 g9RMZncE023203 for <[e-mail]>; Sun, 27 Oct 2002 23:35:49 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9RMZnB4023202 for ietf-provreg-outgoing; Sun, 27 Oct 2002 23:35:49 +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 g9RMZmcE023196 for <[e-mail]>; Sun, 27 Oct 2002 23:35:48 +0100 (MET)
Received: from bean (bean [66.123.187.68]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g9RMZlFP007071; Sun, 27 Oct 2002 14:35:48 -0800 (PST)
Date: Sun, 27 Oct 2002 14:35:47 -0800 (PST)
From: Rick Wesson <[e-mail]>
To: "Liu, Hong" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Last-Verified Date Contact Element
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Hong,

as i stated before "verification" is a policy that is up to the registry
to describe. i'm just talking about protocol elements not about how you 
as a tld manager should implement it.

-rick

On Sun, 27 Oct 2002, Liu, Hong wrote:

> Rick,
> 
> I admit that I don't know all the activities going on with many other groups
> and what requirements are there for this new element. Maybe you could share
> with us how this element will be used and what exactly verification means.
> Thanks!
> 
> --Hong
> 
> -----Original Message-----
> From: Rick Wesson [mailto:[e-mail]]
> Sent: Sunday, October 27, 2002 11:54 AM
> To: Liu, Hong
> Cc: '[e-mail]'
> Subject: RE: Last-Verified Date Contact Element
> 
> 
> 
> the thought is not only garbage collection, but that we have the element
> in the protocol to comply with future recomendations which many groups are
> pulling for at the moment.
> 
> 
> On Sun, 27 Oct 2002, Liu, Hong wrote:
> 
> > Rick,
> > 
> > I think you raise a good question about registry object maintenance. A
> > similar problem also exists for host objects. However, I would like to
> > understand why the new field is needed. If the sole purpose is for garbage
> > collection in the registry, it can be done through registry internal
> > book-keeping. What do you think?
> > 
> > --Hong
> > 
> > -----Original Message-----
> > From: Rick Wesson [mailto:[e-mail]]
> > Sent: Wednesday, October 23, 2002 11:35 AM
> > To: [e-mail]
> > Cc: '[e-mail]'; [e-mail];
> > [e-mail]
> > Subject: [Ietf-not43] Last-Verified Date Contact Element
> > 
> > 
> > 
> > Scott && IESG,
> > 
> > I realized that there is an item we have overlooked in the wg. In private
> > conversations, myself and others have noted that there is no way to
> > identify the last time a contact object was verified.
> > 
> > I propose that we add a "Last-Verified" date element to the contact object
> > so that registries/registrars may express the last time the object was
> > verified. Since contacts have no expiration date and the "last-modified"
> > date is irreverent to verification.
> > 
> > I believe that this will aid in identifying old, stale and irreverent data
> > within a registry and if the element is published in CRISP or whois to the
> > community in general.
> > 
> > I know it is late in the game for identifing issues with the epp proposals
> > so I have CCed the IESG.
> > 
> > -rick
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Ietf-not43 mailing list
> > [e-mail]
> > http://lists.verisignlabs.com/mailman/listinfo/ietf-not43
> > 
> 



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 g9RKfccE022624 for <[e-mail]>; Sun, 27 Oct 2002 21:41:38 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9RKfc0w022623 for ietf-provreg-outgoing; Sun, 27 Oct 2002 21:41:38 +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 g9RKfbcE022618 for <[e-mail]>; Sun, 27 Oct 2002 21:41:37 +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 g9RKfab21496 for <[e-mail]>; Sun, 27 Oct 2002 20:41:36 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <VLY1J32H>; Sun, 27 Oct 2002 15:42:07 -0500
Message-ID: <[e-mail]>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Last-Verified Date Contact Element
Date: Sun, 27 Oct 2002 15:41:56 -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

Rick,

I admit that I don't know all the activities going on with many other groups
and what requirements are there for this new element. Maybe you could share
with us how this element will be used and what exactly verification means.
Thanks!

--Hong

-----Original Message-----
From: Rick Wesson [mailto:[e-mail]]
Sent: Sunday, October 27, 2002 11:54 AM
To: Liu, Hong
Cc: '[e-mail]'
Subject: RE: Last-Verified Date Contact Element



the thought is not only garbage collection, but that we have the element
in the protocol to comply with future recomendations which many groups are
pulling for at the moment.


On Sun, 27 Oct 2002, Liu, Hong wrote:

> Rick,
> 
> I think you raise a good question about registry object maintenance. A
> similar problem also exists for host objects. However, I would like to
> understand why the new field is needed. If the sole purpose is for garbage
> collection in the registry, it can be done through registry internal
> book-keeping. What do you think?
> 
> --Hong
> 
> -----Original Message-----
> From: Rick Wesson [mailto:[e-mail]]
> Sent: Wednesday, October 23, 2002 11:35 AM
> To: [e-mail]
> Cc: '[e-mail]'; [e-mail];
> [e-mail]
> Subject: [Ietf-not43] Last-Verified Date Contact Element
> 
> 
> 
> Scott && IESG,
> 
> I realized that there is an item we have overlooked in the wg. In private
> conversations, myself and others have noted that there is no way to
> identify the last time a contact object was verified.
> 
> I propose that we add a "Last-Verified" date element to the contact object
> so that registries/registrars may express the last time the object was
> verified. Since contacts have no expiration date and the "last-modified"
> date is irreverent to verification.
> 
> I believe that this will aid in identifying old, stale and irreverent data
> within a registry and if the element is published in CRISP or whois to the
> community in general.
> 
> I know it is late in the game for identifing issues with the epp proposals
> so I have CCed the IESG.
> 
> -rick
> 
> 
> 
> 
> _______________________________________________
> Ietf-not43 mailing list
> [e-mail]
> http://lists.verisignlabs.com/mailman/listinfo/ietf-not43
> 


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 g9RJx7cE022392 for <[e-mail]>; Sun, 27 Oct 2002 20:59:07 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9RJx75p022391 for ietf-provreg-outgoing; Sun, 27 Oct 2002 20:59:07 +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 g9RJx5cE022386 for <[e-mail]>; Sun, 27 Oct 2002 20:59:06 +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 g9RJx4Ym083367 for <[e-mail]>; Sun, 27 Oct 2002 14:59:04 -0500 (EST)
Received: from [192.35.167.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA29399; Sun, 27 Oct 2002 14:59:03 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b08b9e1f528f3e1@[192.35.167.226]>
Date: Sun, 27 Oct 2002 11:59:03 -0800
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: Guidelines doc
Cc: Edward Lewis <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

This document seems to border on being a guideline vs. a requirement document.

Section 2.1

Besides an extension being "informational" it can also be "experimental."

Section 2.3

Allowing a server to deny to a client access to an extension probably 
should migrate to the base spec.  Would this impact the state diagram?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 g9RGrwcE021525 for <[e-mail]>; Sun, 27 Oct 2002 17:53:58 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9RGrw1t021524 for ietf-provreg-outgoing; Sun, 27 Oct 2002 17:53: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 g9RGrucE021519 for <[e-mail]>; Sun, 27 Oct 2002 17:53:56 +0100 (MET)
Received: from bean (bean [66.123.187.68]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g9RGrtFP023675; Sun, 27 Oct 2002 08:53:55 -0800 (PST)
Date: Sun, 27 Oct 2002 08:53:55 -0800 (PST)
From: Rick Wesson <[e-mail]>
To: "Liu, Hong" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Last-Verified Date Contact Element
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

the thought is not only garbage collection, but that we have the element
in the protocol to comply with future recomendations which many groups are
pulling for at the moment.


On Sun, 27 Oct 2002, Liu, Hong wrote:

> Rick,
> 
> I think you raise a good question about registry object maintenance. A
> similar problem also exists for host objects. However, I would like to
> understand why the new field is needed. If the sole purpose is for garbage
> collection in the registry, it can be done through registry internal
> book-keeping. What do you think?
> 
> --Hong
> 
> -----Original Message-----
> From: Rick Wesson [mailto:[e-mail]]
> Sent: Wednesday, October 23, 2002 11:35 AM
> To: [e-mail]
> Cc: '[e-mail]'; [e-mail];
> [e-mail]
> Subject: [Ietf-not43] Last-Verified Date Contact Element
> 
> 
> 
> Scott && IESG,
> 
> I realized that there is an item we have overlooked in the wg. In private
> conversations, myself and others have noted that there is no way to
> identify the last time a contact object was verified.
> 
> I propose that we add a "Last-Verified" date element to the contact object
> so that registries/registrars may express the last time the object was
> verified. Since contacts have no expiration date and the "last-modified"
> date is irreverent to verification.
> 
> I believe that this will aid in identifying old, stale and irreverent data
> within a registry and if the element is published in CRISP or whois to the
> community in general.
> 
> I know it is late in the game for identifing issues with the epp proposals
> so I have CCed the IESG.
> 
> -rick
> 
> 
> 
> 
> _______________________________________________
> Ietf-not43 mailing list
> [e-mail]
> http://lists.verisignlabs.com/mailman/listinfo/ietf-not43
> 



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 g9RESicE020746 for <[e-mail]>; Sun, 27 Oct 2002 15:28:44 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9RESidM020745 for ietf-provreg-outgoing; Sun, 27 Oct 2002 15:28:44 +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 g9REShcE020740 for <[e-mail]>; Sun, 27 Oct 2002 15:28:43 +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 g9RET3lU018119; Sun, 27 Oct 2002 09:29:03 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Rick Wesson <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, [e-mail], "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: Last-Verified Date Contact Element
In-Reply-To: Your message of "Wed, 23 Oct 2002 09:32:15 PDT." <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Sun, 27 Oct 2002 09:29:03 -0500
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Rick,

I asked:

> > What prevents a client providing some authInfo from also attempting to set
> > upID and set or modify upDate?

You replied:

> the updated date and last-modified date are managed by the registry.

Here's what I ment:

The <contact:upID> is an <info> response element that contains the identifier
of the client that last updated the contact object. The <contact:clID> element
that contains the identifier of the sponsoring client. This client has the
valid authInfo, and can perform an <update> on the contact object in question.
If that client wants to date-stamp/touch a client object for the purpose of
associating some temporal identifier to "verification" (and I still don't
know wha that means), isn't this the recipie? This either sets or modifies
the <contact:upID> and sets or modifies the <contact:upDate>.

It is true these elements are managed by the registry, but they are done so
in response to client-initiated events.

I guess I'm still in the dark about the mechanism, as well as the purpose,
and utility.

Color me clueless,
Eric


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 g9RCoDcE020375 for <[e-mail]>; Sun, 27 Oct 2002 13:50:13 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9RCoDWc020374 for ietf-provreg-outgoing; Sun, 27 Oct 2002 13:50:13 +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 g9RCoCcE020369 for <[e-mail]>; Sun, 27 Oct 2002 13:50:12 +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 g9RCoBb13902 for <[e-mail]>; Sun, 27 Oct 2002 12:50:11 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <VLY1JN1Y>; Sun, 27 Oct 2002 07:50:41 -0500
Message-ID: <[e-mail]>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Last-Verified Date Contact Element
Date: Sun, 27 Oct 2002 07:50: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

Rick,

I think you raise a good question about registry object maintenance. A
similar problem also exists for host objects. However, I would like to
understand why the new field is needed. If the sole purpose is for garbage
collection in the registry, it can be done through registry internal
book-keeping. What do you think?

--Hong

-----Original Message-----
From: Rick Wesson [mailto:[e-mail]]
Sent: Wednesday, October 23, 2002 11:35 AM
To: [e-mail]
Cc: '[e-mail]'; [e-mail];
[e-mail]
Subject: [Ietf-not43] Last-Verified Date Contact Element



Scott && IESG,

I realized that there is an item we have overlooked in the wg. In private
conversations, myself and others have noted that there is no way to
identify the last time a contact object was verified.

I propose that we add a "Last-Verified" date element to the contact object
so that registries/registrars may express the last time the object was
verified. Since contacts have no expiration date and the "last-modified"
date is irreverent to verification.

I believe that this will aid in identifying old, stale and irreverent data
within a registry and if the element is published in CRISP or whois to the
community in general.

I know it is late in the game for identifing issues with the epp proposals
so I have CCed the IESG.

-rick




_______________________________________________
Ietf-not43 mailing list
[e-mail]
http://lists.verisignlabs.com/mailman/listinfo/ietf-not43


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 g9PJb6cE015476 for <[e-mail]>; Fri, 25 Oct 2002 21:37:06 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9PJb6eK015475 for ietf-provreg-outgoing; Fri, 25 Oct 2002 21:37:06 +0200 (MEST)
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 g9PJb0cE015470 for <[e-mail]>; Fri, 25 Oct 2002 21:37:01 +0200 (MEST)
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 g9PJbllU006215; Fri, 25 Oct 2002 15:37:47 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Stephane Bortzmeyer <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, [e-mail], [e-mail]
Subject: Re: FYI: I-D ACTION:draft-brunner-epp-smtp-00.txt 
In-Reply-To: Your message of "Wed, 23 Oct 2002 16:05:43 +0200." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 25 Oct 2002 15:37:47 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> I believe it would be better to call it "EPP transport mapping for
> E-mail".

Is there something I can point to that defines "email"? This sounds goofy
to me (my own question I mean), since we find this kind of stuff everywhere:

	BCPs and other RFCs may be obtained using HTTP, FTP, or email.
	See the RFC Editor Web page http://www.rfc-editor.org.

(From the RFC/BCP/STD boilerplate)

Eric


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 g9OIBscE019358 for <[e-mail]>; Thu, 24 Oct 2002 20:11:54 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9OIBsUW019357 for ietf-provreg-outgoing; Thu, 24 Oct 2002 20:11:54 +0200 (MEST)
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 g9OIBocE019345 for <[e-mail]>; Thu, 24 Oct 2002 20:11:51 +0200 (MEST)
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 g9OICb44004858; Thu, 24 Oct 2002 14:12:37 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Stephane Bortzmeyer <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, [e-mail], [e-mail]
Subject: Re: FYI: I-D ACTION:draft-brunner-epp-smtp-00.txt 
In-Reply-To: Your message of "Thu, 24 Oct 2002 13:01:35 +0200." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 24 Oct 2002 14:12:37 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> [I clearly have a problem with English. Let me say the same thing in a
> different way.]

Thank you for making the effort.

> I never asked that. I suggested to *rename* the draft (not changing
> its actual content) from "EPP over SMTP" to "EPP over e-mail".

Understood. Now.

> Rationale: you do not use SMTP at all and your mapping will work as
> well over any e-mail transport, UUCP, SMTP, X400, etc.

Actually that was my intent, though I hadn't thought of X.400, and it
was one of the little reasons why I prefer 821/822 over 2821/2822, the
reference to X.25 -- openness to something other than TCP as transport.

Thanks for the uucp-in-action (1m air gap). This is the class of use I
had in mind, for registrars using dial-up (non-ICANN applications of EPP).

> Of course, I would not do EPP that way, but my idea was we should not
> limit to SMTP when the draft makes no use of any SMTP feature.

I guess I was recalling sendmail's MAILER(uucp) and MAILER(smtp) and
UUCP_RELAY, rulesets for address mapping  ...

Mea culpa.

Dave suggested moving all of the MIME security to another document. Any
comment?

Thanks again.

Eric


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 g9OB1hcE015056 for <[e-mail]>; Thu, 24 Oct 2002 13:01:43 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9OB1hLg015055 for ietf-provreg-outgoing; Thu, 24 Oct 2002 13:01:43 +0200 (MEST)
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 g9OB1ecE015050 for <[e-mail]>; Thu, 24 Oct 2002 13:01:42 +0200 (MEST)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id g9OB1ZhA888167; Thu, 24 Oct 2002 13:01:36 +0200 (CEST)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id 3928010F2C; Thu, 24 Oct 2002 13:01:35 +0200 (CEST)
Date: Thu, 24 Oct 2002 13:01:35 +0200
From: Stephane Bortzmeyer <[e-mail]>
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
Cc: Stephane Bortzmeyer <[e-mail]>, [e-mail]
Subject: Re: FYI: I-D ACTION:draft-brunner-epp-smtp-00.txt
Message-ID: <[e-mail]>
References: <[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

[I clearly have a problem with English. Let me say the same thing in a
different way.]

On Wed, Oct 23, 2002 at 01:48:55PM -0400,
 Eric Brunner-Williams in Portland Maine <[e-mail]> wrote 
 a message of 24 lines which said:

> > I believe it would be better to call it "EPP transport mapping for
> > E-mail". You do not seem to use any SMTP feature in the draft, thus
> > allowing EPP over UUCP as well.
> 
> I didn't intend for this memo to specify transport directly over UUCP,

I never asked that. I suggested to *rename* the draft (not changing
its actual content) from "EPP over SMTP" to "EPP over e-mail".

Rationale: you do not use SMTP at all and your mapping will work as
well over any e-mail transport, UUCP, SMTP, X400, etc.

> Thanks for reading the draft. If you want to toss me some tidbits on
> modern uucp use near you, I'd appreciate it. I'm always curious.

I know a computer security company where the Internet email server is
not connected physically to the LAN. Mail is spooled by UUCP, put on a
floppy and travel to the internal mail server one meter (but without
any network link) away.

Of course, I would not do EPP that way, but my idea was we should not
limit to SMTP when the draft makes no use of any SMTP feature.



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 g9NHm1cE005775 for <[e-mail]>; Wed, 23 Oct 2002 19:48:01 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9NHm1Eb005774 for ietf-provreg-outgoing; Wed, 23 Oct 2002 19:48:01 +0200 (MEST)
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 g9NHm0cE005769 for <[e-mail]>; Wed, 23 Oct 2002 19:48:00 +0200 (MEST)
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 g9NHmt44000413; Wed, 23 Oct 2002 13:49:00 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Stephane Bortzmeyer <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, [e-mail], [e-mail]
Subject: Re: FYI: I-D ACTION:draft-brunner-epp-smtp-00.txt 
In-Reply-To: Your message of "Wed, 23 Oct 2002 16:05:43 +0200." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 23 Oct 2002 13:48:55 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> I believe it would be better to call it "EPP transport mapping for
> E-mail". You do not seem to use any SMTP feature in the draft, thus
> allowing EPP over UUCP as well.

I didn't intend for this memo to specify transport directly over UUCP,
that is using uux and uuxqt daemons, e.g.,

	ub % uux -z pseudo-random!rmail epp+uucp < `cat domain_create.xml`
 
	(execute "rmail epp+uucp" on pseudo-random, with domain_create.xml
	 as the text to be mailed, from utterly-bogus, nic-name "ub")

so that is my oversight.

> (BTW, there are some places in the draft when you say 822 when you
> probably mean 2822.)

Yup.

Thanks for reading the draft. If you want to toss me some tidbits on
modern uucp use near you, I'd appreciate it. I'm always curious.

TiA,
Eric


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 g9NGfEcE004725 for <[e-mail]>; Wed, 23 Oct 2002 18:41:14 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9NGfEoL004724 for ietf-provreg-outgoing; Wed, 23 Oct 2002 18:41:14 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail1-0.chcgil.ameritech.net (mail1-0.chcgil.ameritech.net [206.141.192.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g9NGdicE004699 for <[e-mail]>; Wed, 23 Oct 2002 18:39:45 +0200 (MEST)
Received: from repligate ([65.43.113.42]) by mail1-0.chcgil.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20021023163942.FXFY23046.mail1-0.chcgil.ameritech.net@repligate>; Wed, 23 Oct 2002 11:39:42 -0500
Message-ID: <03a801c27ab2$dff3f630$0100a8c0@repligate>
From: "Jim Fleming" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "Elisabeth Porteneuve" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, "@quasar Internet Solutions, Inc." <[e-mail]>, "Bruce Young" <[e-mail]>, <[e-mail]>, <[e-mail]>, "Joanna Lane" <[e-mail]>, "Joe Baptista" <[e-mail]>, "Joop Teernstra" <[e-mail]>, "Judith Oppenheimer" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, "Richard Henderson" <[e-mail]>, "Richard J. Sexton" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Last-Verified Date Contact Element 
Date: Wed, 23 Oct 2002 11:40:16 -0500
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: "Rick Wesson" <[e-mail]>
Subject: Re: Last-Verified Date Contact Element 


> >
> > What prevents a client providing some authInfo from also attempting to set
> > upID and set or modify upDate?
> 
> the updated date and last-modified date are managed by the registry.
> 

"the registry" ?

With 100% of 128-bit DNS .COM Registrations flowing thru the 4 companies below,
they can collectively be viewed as "the registry". They have many fields and a lot of whois
information. More fields can of course be added by the 128-bit DNS .COM Registry.
http://www.domainnameconference.com

Average wholesale cost...$7.735
======= Example 4 RegisTRA Model =======
http://www.cashbackalliance.com/domain/domainsfor619.aspx
$6.19
http://www.wildwestdomains.com/pricelist.asp
$6.75
http://www.srsplus.com/en-def-5d142899df19/en/srsplus/partners_pricing.shtml
$8.00
http://resellers.tucows.com/opensrs/
$10.00
======================================================

Jim Fleming
128-bit DNS is closer than you think...
0:201 .COM
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





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 g9NGY6cE004566 for <[e-mail]>; Wed, 23 Oct 2002 18:34:06 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9NGY6Sp004565 for ietf-provreg-outgoing; Wed, 23 Oct 2002 18:34:06 +0200 (MEST)
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 g9NGY4cE004556 for <[e-mail]>; Wed, 23 Oct 2002 18:34:05 +0200 (MEST)
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 g9NGYMtE016791; Wed, 23 Oct 2002 12:34:24 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Rick Wesson <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, [e-mail], "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: Last-Verified Date Contact Element 
In-Reply-To: Your message of "Wed, 23 Oct 2002 09:32:15 PDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 23 Oct 2002 12:34:22 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> > What prevents a client providing some authInfo from also attempting to set
> > upID and set or modify upDate?
> 
> the updated date and last-modified date are managed by the registry.

You mean that the sponsoring client can't set upID or set or modify upDate?

I didn't know that.


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 g9NGWHcE004510 for <[e-mail]>; Wed, 23 Oct 2002 18:32:17 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9NGWHnj004509 for ietf-provreg-outgoing; Wed, 23 Oct 2002 18:32:17 +0200 (MEST)
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 g9NGWFcE004504 for <[e-mail]>; Wed, 23 Oct 2002 18:32:16 +0200 (MEST)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g9NGWDFP001948; Wed, 23 Oct 2002 09:32:13 -0700 (PDT)
Date: Wed, 23 Oct 2002 09:32:15 -0700 (PDT)
From: Rick Wesson <[e-mail]>
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
cc: <[e-mail]>, "'[e-mail]'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Last-Verified Date Contact Element 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>
> What prevents a client providing some authInfo from also attempting to set
> upID and set or modify upDate?

the updated date and last-modified date are managed by the registry.

-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 g9NGLZcE004359 for <[e-mail]>; Wed, 23 Oct 2002 18:21:35 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9NGLZ1d004358 for ietf-provreg-outgoing; Wed, 23 Oct 2002 18:21:35 +0200 (MEST)
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 g9NGLYcE004353 for <[e-mail]>; Wed, 23 Oct 2002 18:21:34 +0200 (MEST)
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 g9NGLstE016716; Wed, 23 Oct 2002 12:21:54 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Rick Wesson <[e-mail]>
cc: [e-mail], "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: Last-Verified Date Contact Element 
In-Reply-To: Your message of "Wed, 23 Oct 2002 08:34:31 PDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 23 Oct 2002 12:21:54 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Rick,

> I propose that we add a "Last-Verified" date element to the contact object
> so that registries/registrars may express the last time the object was
> verified. Since contacts have no expiration date and the "last-modified"
> date is irreverent to verification.

What does "verified" mean?

> I believe that this will aid in identifying old, stale and irreverent data
> within a registry and if the element is published in CRISP or whois to the
> community in general.

How?
Why?

What prevents a client providing some authInfo from also attempting to set
upID and set or modify upDate?

Eric


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 g9NG3RcE004063 for <[e-mail]>; Wed, 23 Oct 2002 18:03:27 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9NG3RB4004062 for ietf-provreg-outgoing; Wed, 23 Oct 2002 18:03:27 +0200 (MEST)
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 g9NG3PcE004057 for <[e-mail]>; Wed, 23 Oct 2002 18:03:25 +0200 (MEST)
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 g9NG3mtE016630; Wed, 23 Oct 2002 12:03:48 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Stephane Bortzmeyer <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: "private" Element Attribute 
In-Reply-To: Your message of "Wed, 23 Oct 2002 14:26:29 +0200." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 23 Oct 2002 12:03:47 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> I was not there and I find nothing in the mailing list archive.

Some was via voca during the WG face-to-face. Scott's provided pointers to
the WG list archive.

> <dcp> has exactly the same problem: while it acknowledges the work of
> the P3P WG, it tries to reinvent P3P, instead of using it.

We took some of the vocabulary. We didn't take the binding of p3p to
http, either in the URI (WKL) form, or in the subsequent forms for a
p3p header (I'm co-author of that in the p3p spec), nor in the later
forms (html link tag, xhtml link tag xform (pending CR)).

We took something quite close to the application of p3p's vocabulary to
cookies (compact policies) -- policy-on-apdu, not policy-on-uri, and put
<dcp>-on-session (sessionlessly on-object, I think).

> Why not use <POLICY> and not <dcp>?

For everyone's benefit, and this may not be current (shame Eric, shame!):
(from: http://www.w3.org/2000/10/XMLSchema.dtd)
<!-- ************* POLICY ************* -->
 <element name='POLICY'>
  <complexType>
   <sequence>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
    <element ref='p3p:TEST' minOccurs='0'/>
    <element ref='p3p:EXPIRY' minOccurs='0'/>
    <element ref='p3p:DATASCHEMA' minOccurs='0'/>
    <element ref='p3p:ENTITY'/>
    <element ref='p3p:ACCESS'/>
    <element ref='p3p:DISPUTES-GROUP' minOccurs='0'/>
    <element ref='p3p:STATEMENT' minOccurs='0' maxOccurs='unbounded'/>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
   <attribute name='discuri' type='uriReference' use='required'/>
   <attribute name='opturi' type='uriReference' use='optional'/>
   <attribute name='name' type='ID' use='optional'/>
  </complexType>
 </element>

Meta-Issues:

a. Personally I don't think it helps us to mandate UTF-8 for a portion
   of the data between EPP endpoints,

b. We haven't mandated genuine P3P at the initial (to onward-transport
   via EPP) data-collection (registrar, or re-seller, or more
   generally, agent) site, and mandated getting the P3P at that point
   consistent with the DCP at the registrar.

c. We haven't mandated genuine P3P at the registry (recall, registries
   don't "talk" to registrants),

c. We haven't (yet) provided for transparent, or transparent subsetting
   of an instance of P3P to the EPP client from the EPP server, or
   the reverse in the case of APPEL-esque thingies I still haven't looked
   at.

<POLICY> Element Issues:

Numerous.

Please see <dcp>.

Eric


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 g9NFYXcE003575 for <[e-mail]>; Wed, 23 Oct 2002 17:34:33 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9NFYXW9003574 for ietf-provreg-outgoing; Wed, 23 Oct 2002 17:34:33 +0200 (MEST)
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 g9NFYWcE003568 for <[e-mail]>; Wed, 23 Oct 2002 17:34:32 +0200 (MEST)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g9NFYSFP029410; Wed, 23 Oct 2002 08:34:29 -0700 (PDT)
Date: Wed, 23 Oct 2002 08:34:31 -0700 (PDT)
From: Rick Wesson <[e-mail]>
To: <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Last-Verified Date Contact Element
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Scott && IESG,

I realized that there is an item we have overlooked in the wg. In private
conversations, myself and others have noted that there is no way to
identify the last time a contact object was verified.

I propose that we add a "Last-Verified" date element to the contact object
so that registries/registrars may express the last time the object was
verified. Since contacts have no expiration date and the "last-modified"
date is irreverent to verification.

I believe that this will aid in identifying old, stale and irreverent data
within a registry and if the element is published in CRISP or whois to the
community in general.

I know it is late in the game for identifing issues with the epp proposals
so I have CCed the IESG.

-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 g9NE5jcE002037 for <[e-mail]>; Wed, 23 Oct 2002 16:05:45 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9NE5jYF002036 for ietf-provreg-outgoing; Wed, 23 Oct 2002 16:05:45 +0200 (MEST)
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 g9NE5hcE002031 for <[e-mail]>; Wed, 23 Oct 2002 16:05:43 +0200 (MEST)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id g9NE5hhA558205; Wed, 23 Oct 2002 16:05:43 +0200 (CEST)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id 44D6810F2C; Wed, 23 Oct 2002 16:05:43 +0200 (CEST)
Date: Wed, 23 Oct 2002 16:05:43 +0200
From: Stephane Bortzmeyer <[e-mail]>
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
Cc: [e-mail]
Subject: Re: FYI: I-D ACTION:draft-brunner-epp-smtp-00.txt
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 Wed, Oct 23, 2002 at 09:44:15AM -0400,
 Eric Brunner-Williams in Portland Maine <[e-mail]> wrote 
 a message of 115 lines which said:

> 	Title		: EPP transport mapping for SMTP
> 	Author(s)	: E. Brunner-Williams
> 	Filename	: draft-brunner-epp-smtp-00.txt

I believe it would be better to call it "EPP transport mapping for
E-mail". You do not seem to use any SMTP feature in the draft, thus
allowing EPP over UUCP as well.

(BTW, there are some places in the draft when you say 822 when you
probably mean 2822.)





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 g9NDhqcE001722 for <[e-mail]>; Wed, 23 Oct 2002 15:43:52 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9NDhqgC001721 for ietf-provreg-outgoing; Wed, 23 Oct 2002 15:43:52 +0200 (MEST)
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 g9NDhocE001716 for <[e-mail]>; Wed, 23 Oct 2002 15:43:51 +0200 (MEST)
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 g9NDiFtE016022 for <[e-mail]>; Wed, 23 Oct 2002 09:44:15 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: FYI: I-D ACTION:draft-brunner-epp-smtp-00.txt
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 23 Oct 2002 09:44:15 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

------- Forwarded Message

Return-Path: [e-mail]
Delivery-Date: Wed Oct 23 09:16:00 2002
Delivery-Date: Wed, 23 Oct 2002 09:16:00 -0400
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nic-naa.net (8.12.6/8.12.6) with ESMTP id g9NDFxtE015912
	for <[e-mail]>; Wed, 23 Oct 2002 09:15:59 -0400 (EDT)
	(envelope-from [e-mail])
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA06515
	for [e-mail]; Wed, 23 Oct 2002 08:35:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA05969
	for <[e-mail]>; Wed, 23 Oct 2002 07:38:39 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13986
	for <[e-mail]>; Wed, 23 Oct 2002 07:36:22 -0400 (EDT)
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-smtp-00.txt
Date: Wed, 23 Oct 2002 07:36:22 -0400
Sender: [e-mail]

- --NextPart

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


	Title		: EPP transport mapping for SMTP
	Author(s)	: E. Brunner-Williams
	Filename	: draft-brunner-epp-smtp-00.txt
	Pages		: 31
	Date		: 2002-10-22
	
This document describes how to exchange EPP content using SMTP
transport.  The data is packaged using standard MIME content-types.
Authentication and data security are obtained by using OpenPGP
security body parts or Cryptographic Message Syntax (S/MIME).
Authenticated acknowledgements make use of multipart/signed replies
to the original SMTP message.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-brunner-epp-smtp-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-smtp-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-smtp-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-smtp-00.txt

- --OtherAccess
Content-Type: Message/External-body;
	name="draft-brunner-epp-smtp-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



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 g9NCnYcE000919 for <[e-mail]>; Wed, 23 Oct 2002 14:49:34 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9NCnYSQ000917 for ietf-provreg-outgoing; Wed, 23 Oct 2002 14:49:34 +0200 (MEST)
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 g9NCnWcE000912 for <[e-mail]>; Wed, 23 Oct 2002 14:49:32 +0200 (MEST)
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 IAA19868; Wed, 23 Oct 2002 08:49:30 -0400 (EDT)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <TF9XZZZM>; Wed, 23 Oct 2002 08:49:30 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Stephane Bortzmeyer'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: "private" Element Attribute
Date: Wed, 23 Oct 2002 08:49:17 -0400
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, Oct 22, 2002 at 09:50:57AM -0400,
>  Eric Brunner-Williams in Portland Maine <[e-mail]> wrote 
>  a message of 68 lines which said:
> 
> > Please see the discussion of the data collection policy 
> <dcp> element,
> > in the -07 draft. This stuff got formalized for us around the London
> > meeting.
> 
> I was not there and I find nothing in the mailing list archive.

You need to look a little bit deeper.  Here are some pointers:

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

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

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

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

There's more, but I'm sure you can find them yourself if you look towards
the end of 2001 more closely.

> <dcp> has exactly the same problem: while it acknowledges the work of
> the P3P WG, it tries to reinvent P3P, instead of using it. At the cost
> of great complexity, EPP uses the whole XML zoo, including the ability
> to add any XML element (not just those specified in EPP) in an EPP
> element. Why not use <POLICY> and not <dcp>?

It's not trying to reinvent P3P at all -- it uses a subset of P3P that makes
sense in a different (that is, not web-based) operating environment.  All of
P3P just isn't appropriate for what we're doing.

"dcp" is an acronym for "Data Collection Policy".  "policy" by itself is too
vague a term to use in this context.

-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 g9NCZDcE000677 for <[e-mail]>; Wed, 23 Oct 2002 14:35:13 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9NCZDcE000676 for ietf-provreg-outgoing; Wed, 23 Oct 2002 14:35:13 +0200 (MEST)
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 g9NCZCcE000669 for <[e-mail]>; Wed, 23 Oct 2002 14:35:12 +0200 (MEST)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id g9NCZChA988790; Wed, 23 Oct 2002 14:35:12 +0200 (CEST)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id CE0AC10F2C; Wed, 23 Oct 2002 14:35:11 +0200 (CEST)
Date: Wed, 23 Oct 2002 14:35:11 +0200
From: Stephane Bortzmeyer <[e-mail]>
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
Cc: Stephane Bortzmeyer <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: "private" Element Attribute
Message-ID: <[e-mail]>
References: <[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, Oct 22, 2002 at 10:55:48AM -0400,
 Eric Brunner-Williams in Portland Maine <[e-mail]> wrote 
 a message of 51 lines which said:

> In October 2000 the P3P Spec WG decided to split the APPEL draft out from
> the P3P Spec.
...
> Its a data collection practice announcement format specification, intended
> for data collection implementors and policy evaluation implementors. It is
> not a user preference announcement language,

P3P, yes. Not APPEL.

> In all the discussion I've had with data collectors and policy evaluation
> engine implementors in 2000, 2001, and 2002 I can't recall anyone making
> the case that a use-case for APPEL was communicating between the data
> source and the data sink.

It was discussed on the W3C P3P-policy mailing lists. See the archives
at <URL:http://lists.w3.org/Archives/Public/www-p3p-policy/> for
instance the thread "Policy for an Internet registry".




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 g9NCQZcE000519 for <[e-mail]>; Wed, 23 Oct 2002 14:26:35 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9NCQZp2000518 for ietf-provreg-outgoing; Wed, 23 Oct 2002 14:26:35 +0200 (MEST)
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 g9NCQYcE000512 for <[e-mail]>; Wed, 23 Oct 2002 14:26:34 +0200 (MEST)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id g9NCQUhA562289; Wed, 23 Oct 2002 14:26:30 +0200 (CEST)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id F420B10F2C; Wed, 23 Oct 2002 14:26:29 +0200 (CEST)
Date: Wed, 23 Oct 2002 14:26:29 +0200
From: Stephane Bortzmeyer <[e-mail]>
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
Cc: Stephane Bortzmeyer <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: "private" Element Attribute
Message-ID: <[e-mail]>
References: <[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, Oct 22, 2002 at 09:50:57AM -0400,
 Eric Brunner-Williams in Portland Maine <[e-mail]> wrote 
 a message of 68 lines which said:

> Please see the discussion of the data collection policy <dcp> element,
> in the -07 draft. This stuff got formalized for us around the London
> meeting.

I was not there and I find nothing in the mailing list archive.

<dcp> has exactly the same problem: while it acknowledges the work of
the P3P WG, it tries to reinvent P3P, instead of using it. At the cost
of great complexity, EPP uses the whole XML zoo, including the ability
to add any XML element (not just those specified in EPP) in an EPP
element. Why not use <POLICY> and not <dcp>?



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 g9NCFMcE000399 for <[e-mail]>; Wed, 23 Oct 2002 14:15:22 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9NCFLa4000398 for ietf-provreg-outgoing; Wed, 23 Oct 2002 14:15:21 +0200 (MEST)
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 g9NCFLcE000393 for <[e-mail]>; Wed, 23 Oct 2002 14:15:21 +0200 (MEST)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id g9NCFK7I1515144; Wed, 23 Oct 2002 14:15:20 +0200 (CEST)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id 9686410F2C; Wed, 23 Oct 2002 14:15:20 +0200 (CEST)
Date: Wed, 23 Oct 2002 14:15:20 +0200
From: Stephane Bortzmeyer <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
Cc: "'Stephane Bortzmeyer'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: "private" Element Attribute
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, Oct 22, 2002 at 04:26:22PM -0400,
 Hollenbeck, Scott <[e-mail]> wrote 
 a message of 14 lines which said:

> As far as I can tell this doesn't get us to element-level preference
> specification unless APPEL-like elements are added to _every_ object
> element.  That seems unworkable.

Yes, it is a difficult issue. We should work at a higher level: when
performing a <contact:create>, the user (probably a registrar acting
on behalf of a registrant which sent to the registrar a set of
preferences) adds *one* APPEL element to the EPP flow (not one to
every <contact:something>).

The registry then tries to map the preferences expressed in APPEL to
its own data schema. More realistic, although a bit ambiguous since
EPP-contact-mapping schema may not be the same as the APPEL base
schema (actually, it is the P3P base schema).



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 g9NC55cE000273 for <[e-mail]>; Wed, 23 Oct 2002 14:05:05 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9NC55Pt000272 for ietf-provreg-outgoing; Wed, 23 Oct 2002 14:05:05 +0200 (MEST)
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 g9NC54cE000267 for <[e-mail]>; Wed, 23 Oct 2002 14:05:05 +0200 (MEST)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id g9NC547I1514139; Wed, 23 Oct 2002 14:05:04 +0200 (CEST)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id 06A0310F2C; Wed, 23 Oct 2002 14:05:03 +0200 (CEST)
Date: Wed, 23 Oct 2002 14:05:03 +0200
From: Stephane Bortzmeyer <[e-mail]>
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
Cc: "Hollenbeck, Scott" <[e-mail]>, "'Stephane Bortzmeyer'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: "private" Element Attribute
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, Oct 22, 2002 at 05:11:18PM -0400,
 Eric Brunner-Williams in Portland Maine <[e-mail]> wrote 
 a message of 39 lines which said:

> What problem are we trying to solve?
> 
> a. Providing a mechanism for users to announce their preferences?
> 
> b. Providing a mechanism for collectors to announce their practices?
> 
> c. Providing a mechanism for the expression of applicable law?
> 
> d. Providing a mechanism for policy expression which is capable of
> test, hence enforcement?
> 
> e. Other
> 
> I was pretty sure we settled on (c), hence (b), and not on (a). 

I had a very different feeling. I thought we were trying to work
mostly on a) and secondary on b) (BTW, c) is just a subpart of b). d)
is just impossible.



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 g9NBe9cE029955 for <[e-mail]>; Wed, 23 Oct 2002 13:40:09 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9NBe8sW029954 for ietf-provreg-outgoing; Wed, 23 Oct 2002 13:40:08 +0200 (MEST)
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 g9NBe7cE029949 for <[e-mail]>; Wed, 23 Oct 2002 13:40:07 +0200 (MEST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14261; Wed, 23 Oct 2002 07:37:48 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-provreg-epp-ext-00.txt
Date: Wed, 23 Oct 2002 07:37:47 -0400
Sender: [e-mail]
Precedence: bulk

--NextPart

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

	Title		: Guidelines for Extending the Extensible Provisioning 
                          Protocol
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-ext-00.txt
	Pages		: 15
	Date		: 2002-10-22
	
The Extensible Provisioning Protocol (EPP) is an application layer
client-server protocol for the provisioning and management of objects
stored in a shared central repository.  Specified in XML, the
protocol defines generic object management operations and an
extensible framework that maps protocol operations to objects.  This
document presents guidelines for use of EPP's extension mechanisms to
define new features and object management capabilities.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-ext-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-ietf-provreg-epp-ext-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-ietf-provreg-epp-ext-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-ietf-provreg-epp-ext-00.txt

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

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

--OtherAccess--

--NextPart--




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 g9N2GdcE025802 for <[e-mail]>; Wed, 23 Oct 2002 04:16:39 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9N2GdvP025801 for ietf-provreg-outgoing; Wed, 23 Oct 2002 04:16:39 +0200 (MEST)
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 g9N2GccE025796 for <[e-mail]>; Wed, 23 Oct 2002 04:16:38 +0200 (MEST)
Received: from andrew by mail.libertyrms.com with local (Exim 3.22 #3 (Debian)) id 184B4X-0007Mh-00 for <[e-mail]>; Tue, 22 Oct 2002 22:16:37 -0400
Date: Tue, 22 Oct 2002 22:16:37 -0400
From: Andrew Sullivan <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Re: "private" Element Attribute
Message-ID: <[e-mail]>
Mail-Followup-To: Andrew Sullivan <[e-mail]>, "'[e-mail]'" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Oct 22, 2002 at 11:18:57AM -0400
Sender: [e-mail]
Precedence: bulk

On Tue, Oct 22, 2002 at 11:18:57AM -0400, Eric Brunner-Williams in
Portland Maine wrote:

> Earlier Dan asked if anyone was implementing <dcp>. I haven't looked at your
> client code in ages, are you?

I understand from the relevant developers (I'm just a lowly database
guy) that there has been some implementation work on this in the most
recent server iterations.  We're working on getting the server to
work first; the client will follow, I suppose.  

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 g9N07UcE023913 for <[e-mail]>; Wed, 23 Oct 2002 02:07:30 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9N07UiW023912 for ietf-provreg-outgoing; Wed, 23 Oct 2002 02:07:30 +0200 (MEST)
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 g9N07ScE023907 for <[e-mail]>; Wed, 23 Oct 2002 02:07:28 +0200 (MEST)
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 g9N080tE012815; Tue, 22 Oct 2002 20:08:00 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: "private" Element Attribute 
In-Reply-To: Your message of "Tue, 22 Oct 2002 19:40:19 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 22 Oct 2002 20:08:00 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> I'm not sure how or why you concluded that we settled on (c) in the context
> of this thread.

I think we're discussing as the authors of -07 and -05, some new external
requirement statement, which may or may not be techncally sophistcated.
Our drafts, -07 in particular, provide a mechanism for (b), and for those
who deploy EPP implementations in ICANN private-law, or public-law, TLDs,
that means a mechanism that allows expression of policy consistent with
applicable law, (c).

> My understanding of the IESG comments is that they were focused on (a).

That's their problem. Randy wouldn't be the first menber of the IESG to
assert he knows more about the problem domain than I do, but I don't think
he will.

What (a) implies is that a registrant can create enforceable policies on
registries. Now we look to the space created by all values of policy and
all values of policied objects.

Actually, I can live with the IESG making the "Internet Standard" (or ICANN)
protocol hideously baroque. The ccTLD and delegated registries can ignore
the damage and route around it.

Having consulted to the _other_ IAB on choice and its consequences, and to
MicroSquash on the same subject, whether in IE or in MS's CDN, I can say
it is as endearing as RSVP and keeping arbitrary amounts of arbitrary state.

Element-wise semantics, but not necessarily distinct semantics for each
element.

I'm thinking.

Goodnight.
Eric


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 g9MNeTcE023617 for <[e-mail]>; Wed, 23 Oct 2002 01:40:29 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9MNeTIh023616 for ietf-provreg-outgoing; Wed, 23 Oct 2002 01:40:29 +0200 (MEST)
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 g9MNeScE023609 for <[e-mail]>; Wed, 23 Oct 2002 01:40:28 +0200 (MEST)
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 TAA05377; Tue, 22 Oct 2002 19:40:26 -0400 (EDT)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <TF9XZP1Y>; Tue, 22 Oct 2002 19:40:25 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Eric Brunner-Williams in Portland Maine'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: "private" Element Attribute 
Date: Tue, 22 Oct 2002 19:40:19 -0400
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

> What problem are we trying to solve?
> 
> a. Providing a mechanism for users to announce their preferences?
> 
> b. Providing a mechanism for collectors to announce their practices?
> 
> c. Providing a mechanism for the expression of applicable law?
> 
> d. Providing a mechanism for policy expression which is capable of
> test, hence enforcement?
> 
> e. Other
> 
> I was pretty sure we settled on (c), hence (b), and not on (a). Adding
> (d) is interesting. Replacing (b), hence (c), with (a) isn't, 
> IMO. I know
> at least one contributor prefered (a) to (b).

I'm not sure how or why you concluded that we settled on (c) in the context
of this thread.  My understanding of the IESG comments is that they were
focused on (a).

-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 g9MLApcE022145 for <[e-mail]>; Tue, 22 Oct 2002 23:10:51 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9MLAptL022144 for ietf-provreg-outgoing; Tue, 22 Oct 2002 23:10:51 +0200 (MEST)
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 g9MLAlcE022135 for <[e-mail]>; Tue, 22 Oct 2002 23:10:48 +0200 (MEST)
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 g9MLBItE012136; Tue, 22 Oct 2002 17:11:18 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Stephane Bortzmeyer'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: "private" Element Attribute 
In-Reply-To: Message from "Hollenbeck, Scott" <[e-mail]>  of "Tue, 22 Oct 2002 16:26:22 EDT." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 22 Oct 2002 17:11:18 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Hmm.

	IE	IIS	EPP-C	EPP-S
or
	Mz	Apache	EPP-C	EPP-S

P3P "native" (before we embraced and extended it) sits ONLY on the IIS and
Apache parts of the onward-transport. With our E+O, it now sits between the
C and S, but not elsewhere. We could MANDATE transparency between the EPP-S
and the instance of IIS-or-Apache so the IE-or-Mz browser could evaluate the
EPP-S policy. I think I know how to do that.

APPEL "native" (?) sits ONLY on the IE/Mz parts of the onward-transport
picture. I'm sure that until I re-read the APPEL spec and talk to Marc
that I don't know enough to usefully apply APPEL to reverse direction.

What problem are we trying to solve?

a. Providing a mechanism for users to announce their preferences?

b. Providing a mechanism for collectors to announce their practices?

c. Providing a mechanism for the expression of applicable law?

d. Providing a mechanism for policy expression which is capable of
test, hence enforcement?

e. Other

I was pretty sure we settled on (c), hence (b), and not on (a). Adding
(d) is interesting. Replacing (b), hence (c), with (a) isn't, IMO. I know
at least one contributor prefered (a) to (b).

Eric








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 g9MKQYcE021615 for <[e-mail]>; Tue, 22 Oct 2002 22:26:34 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9MKQXuO021614 for ietf-provreg-outgoing; Tue, 22 Oct 2002 22:26:33 +0200 (MEST)
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 g9MKQWcE021609 for <[e-mail]>; Tue, 22 Oct 2002 22:26:32 +0200 (MEST)
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 QAA26771; Tue, 22 Oct 2002 16:26:30 -0400 (EDT)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <TF9XZJPL>; Tue, 22 Oct 2002 16:26:30 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Stephane Bortzmeyer'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: "private" Element Attribute
Date: Tue, 22 Oct 2002 16:26:22 -0400
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

> Eric provided one. To summary, APPEL can be seen as the "export
> format" of the privacy preferences that you configured in your Web
> browser. They could be sent to the registry in an EPP flow. Then, the
> registry will have a detailed (much more detailed than a binary
> public/private) knowledge of the user's preferences.

As far as I can tell this doesn't get us to element-level preference
specification unless APPEL-like elements are added to _every_ object
element.  That seems unworkable.

I'll have to poke this concept back at Patrik and Randy to see if a
higher-level preference expression like APPEL addresses their concern.

-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 g9MKDNcE021447 for <[e-mail]>; Tue, 22 Oct 2002 22:13:23 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9MKDNfS021446 for ietf-provreg-outgoing; Tue, 22 Oct 2002 22:13:23 +0200 (MEST)
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 g9MKDMcE021441 for <[e-mail]>; Tue, 22 Oct 2002 22:13:22 +0200 (MEST)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id g9MKDK7I1477061; Tue, 22 Oct 2002 22:13:21 +0200 (CEST)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id C858D10F2C; Tue, 22 Oct 2002 22:13:20 +0200 (CEST)
Date: Tue, 22 Oct 2002 22:13:20 +0200
From: Stephane Bortzmeyer <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
Cc: "'Stephane Bortzmeyer'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: "private" Element Attribute
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, Oct 22, 2002 at 12:56:54PM -0400,
 Hollenbeck, Scott <[e-mail]> wrote 
 a message of 27 lines which said:

> in the core protocol.  I'm not familiar with APPEL; could you provide a
> pointer?

Eric provided one. To summary, APPEL can be seen as the "export
format" of the privacy preferences that you configured in your Web
browser. They could be sent to the registry in an EPP flow. Then, the
registry will have a detailed (much more detailed than a binary
public/private) knowledge of the user's preferences.

> My biggest concern in reopening this debate is that we don't get bogged down
> again in debates about how one jurisdiction's privacy policy has to be
> ingrained in the protocol. 

I agree but I do not see the connection with P3P which *is*
policy-neutral. P3P (and APPEL) is a protocol to *express* privacy
policies or requirments, it does not dictate them (unless you think
that no language is neutral, which is also true of EPP).




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 g9MHU0cE019886 for <[e-mail]>; Tue, 22 Oct 2002 19:30:00 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9MHU0v4019885 for ietf-provreg-outgoing; Tue, 22 Oct 2002 19:30:00 +0200 (MEST)
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 g9MHTxcE019877 for <[e-mail]>; Tue, 22 Oct 2002 19:29:59 +0200 (MEST)
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 g9MHUJtE011188; Tue, 22 Oct 2002 13:30:24 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Stephane Bortzmeyer'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: "private" Element Attribute 
In-Reply-To: Your message of "Tue, 22 Oct 2002 12:56:54 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 22 Oct 2002 13:30:19 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

A pointer to APPEL
http://www.w3.org/TR/P3P-preferences/

I agree, the novel (and interesting question) is <dcp> scope.

I agree, that j19n is generally a registry-private policy problem, best
solved by a registry profile. Our problem is a mechanism that allows a
specific policy, as the EPP implementors, and eventually the EPP operators,
see as prudent.

I disagree that a scopeless bivalued semantic is policy neutral, since we
can reasonably forsee that this isn't.

I'm not inclined to "solve" the IETF's problem with ICANN and whois:43.
The right way to do that is to correct the policy-making body that misuses
whois, not poision the protocol with binary toggles.

Eric


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 g9MGvAcE019387 for <[e-mail]>; Tue, 22 Oct 2002 18:57:10 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9MGvA6j019386 for ietf-provreg-outgoing; Tue, 22 Oct 2002 18:57:10 +0200 (MEST)
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 g9MGv6cE019381 for <[e-mail]>; Tue, 22 Oct 2002 18:57:07 +0200 (MEST)
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 MAA12019; Tue, 22 Oct 2002 12:57:04 -0400 (EDT)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <TF9XZBM0>; Tue, 22 Oct 2002 12:57:04 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Stephane Bortzmeyer'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: "private" Element Attribute
Date: Tue, 22 Oct 2002 12:56:54 -0400
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 suggest instead to rely on a function of EPP: the fact that you can
> include XML elements which are not in the official schema. For
> instance, P3P <URL:http://www.w3.org/TR/P3P/> elements could be added
> in the EPP flow from the registry to the registrar and APPEL elements
> from the registrar to the registry.
> 
> That way, we would build on an existing and documented and recognized
> and quite comprehensive framework (managing its privacy preferences is
> complicated enough that we do not introduce a new framework).

As Eric has already replied, we already have data collection policy elements
in the core protocol.  I'm not familiar with APPEL; could you provide a
pointer?

My biggest concern in reopening this debate is that we don't get bogged down
again in debates about how one jurisdiction's privacy policy has to be
ingrained in the protocol.  I firmly believe that our obligation is to
ensure that the protocol provides functionality that provides flexibility
for the expression of multiple privacy policies and privacy preferences.  I
thought we had that going into the IESG review with the current extension
mechanism (though it might not be explained well (or not at all) in the
current text), but one IESG member initially suggested a need to provide
element-level granularity.  We still have a responsibility to keep the
mechanism as policy-neutral as possible, which is where the proposal I
floated yesterday came from.

-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 g9MFILcE017982 for <[e-mail]>; Tue, 22 Oct 2002 17:18:21 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9MFILJM017981 for ietf-provreg-outgoing; Tue, 22 Oct 2002 17:18:21 +0200 (MEST)
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 g9MFIJcE017976 for <[e-mail]>; Tue, 22 Oct 2002 17:18:20 +0200 (MEST)
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 g9MFIvtE010634; Tue, 22 Oct 2002 11:18:57 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Andrew Sullivan <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: "private" Element Attribute 
In-Reply-To: Your message of "Tue, 22 Oct 2002 10:23:33 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 22 Oct 2002 11:18:57 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Andrew,

The <access> element asserts that the collector allows the originator
read-access to some datum.

Now P3P doesn't actually specify how this is provided, and hence how
the originator could detect a policy other than the assertion made in
the <access> element, that is, if <all/> were stated, and the originator
found that the actual read-access was <none/>, we've no way of knowing,
let alone attempting to "enforce" the <all/> assertion.

We are graced with <info>, so we actually can use <access> and <info> to
enforce data consistency within the EPP provisioning chain.

When a registrant changes her contact data, she can <push> that delta on
the registry (and possibly registrar) records, so she and not the registry
is the authoritative holder of the data, and the upstreams (registrars and
registries) simply consistent caches of her contact data.

So, unlike P3P for web sites (and cookies and Xforms and ...), we can move
beyond announcement to announcment plus evaluation of the truth value of
the announcement (for some things), which is necessary to enable any form
of protocol-based  enforcement (as opposed to dumping lawyers on the target
registry from some reasonable altitude).

Earlier Dan asked if anyone was implementing <dcp>. I haven't looked at your
client code in ages, are you?

Eric


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 g9MEtDcE017558 for <[e-mail]>; Tue, 22 Oct 2002 16:55:13 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9MEtDRW017557 for ietf-provreg-outgoing; Tue, 22 Oct 2002 16:55:13 +0200 (MEST)
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 g9MEtBcE017552 for <[e-mail]>; Tue, 22 Oct 2002 16:55:11 +0200 (MEST)
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 g9MEtmtE010531; Tue, 22 Oct 2002 10:55:48 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Stephane Bortzmeyer <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: "private" Element Attribute 
In-Reply-To: Your message of "Tue, 22 Oct 2002 15:55:16 +0200." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 22 Oct 2002 10:55:48 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Stephane,

I spent 2000 working for a "grey hat" in the privacy area, Engage, a CMGI
company. Engage shares trade at about US$ 0.07 last time I looked, down
slightly from US$ 160. Bulk and transactionally acquired PII (deterministic)
or demographic (probablistic) data was my interest, cookies and other bits
of web cruft, and onward-transport of customer-profiles from web sites that
performed data collection -- oddly, quite similar to our own provisioning
chain.

In October 2000 the P3P Spec WG decided to split the APPEL draft out from
the P3P Spec. I was one of those who voted for this split, and never took
a look at APPEL subsequent. I really like Marc Langheinrich (editor), but
it was delaying getting P3P to W3C RC status.

This is simply to say I was writing rather carelessly about APPEL.

>From the high-level blurb, written by someone(s) in the P3P Policy and
Outreach (non-techies):

	... P3P is a standardized set of multiple-choice questions ...
	... a standard, machine-readable format ...
	... enabled browsers can [evaluate a policy statement] ...
	... compare it to the [user]'s own set of privacy preferences.

Its a data collection practice announcement format specification, intended
for data collection implementors and policy evaluation implementors. It is
not a user preference announcement language, nor is it a mechanism to
negociate data collection practices.

>From the high-level blurb, written either by Marc (editor) or Lorrie (chair):

	... the language for exchanging privacy preferences ...

	This document complements the P3P1.0 specification [P3P10] by
	specifying a language for describing collections of preferences
	regarding P3P policies between P3P agents.

In all the discussion I've had with data collectors and policy evaluation
engine implementors in 2000, 2001, and 2002 I can't recall anyone making
the case that a use-case for APPEL was communicating between the data
source and the data sink. It was always between data sources (users) and
between template providors (privacy advocates) and users.

I spent 2001 working for a gTLD operator that never really "got" privacy
and I expect engages in bulk transactions and otherwise repurposes user
data. Like others, but not all others.

Please let me know what makes sense for the .fr operator, and others too.

Eric


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 g9MENacE017094 for <[e-mail]>; Tue, 22 Oct 2002 16:23:36 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9MENai4017093 for ietf-provreg-outgoing; Tue, 22 Oct 2002 16:23:36 +0200 (MEST)
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 g9MENYcE017088 for <[e-mail]>; Tue, 22 Oct 2002 16:23:35 +0200 (MEST)
Received: from andrew by mail.libertyrms.com with local (Exim 3.22 #3 (Debian)) id 183zwT-0001Gs-00 for <[e-mail]>; Tue, 22 Oct 2002 10:23:33 -0400
Date: Tue, 22 Oct 2002 10:23:33 -0400
From: Andrew Sullivan <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Re: "private" Element Attribute
Message-ID: <[e-mail]>
Mail-Followup-To: Andrew Sullivan <[e-mail]>, "'[e-mail]'" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Oct 21, 2002 at 01:56:53PM -0400
Sender: [e-mail]
Precedence: bulk

On Mon, Oct 21, 2002 at 01:56:53PM -0400, Eric Brunner-Williams in Portland Maine wrote:

> Before we take our first step down this bunny trail we need to know
> if what we are creating a mechanism for is a policy assertion by a
> registrant, or a registry, or some intermediary, AND, if the policy
> can be observed in its instantiation.

It seems to me that the historic goal of the WG has been to be
agnostic about policy; and that whether registrants or registries get
to enforce the policy is itself a policy question.  But maybe the
answer (at the expense of yet more complexity) is to do something
analogous to the server*Prohibited/client*Prohibited status values? 
I don't really know, and I can't think of any firm proposals right
now; but would that help, in any case, to address the concern?

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 g9MDtJcE016681 for <[e-mail]>; Tue, 22 Oct 2002 15:55:19 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9MDtJDM016680 for ietf-provreg-outgoing; Tue, 22 Oct 2002 15:55:19 +0200 (MEST)
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 g9MDtIcE016675 for <[e-mail]>; Tue, 22 Oct 2002 15:55:18 +0200 (MEST)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id g9MDtH7I1458252; Tue, 22 Oct 2002 15:55:18 +0200 (CEST)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id 7E0D810F2C; Tue, 22 Oct 2002 15:55:16 +0200 (CEST)
Date: Tue, 22 Oct 2002 15:55:16 +0200
From: Stephane Bortzmeyer <[e-mail]>
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
Cc: Stephane Bortzmeyer <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: "private" Element Attribute
Message-ID: <[e-mail]>
References: <[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, Oct 22, 2002 at 09:50:57AM -0400,
 Eric Brunner-Williams in Portland Maine <[e-mail]> wrote 
 a message of 68 lines which said:

> Unless the APPEL draft has changed significantly (and I'll check, I've
> got some P3P Spec WG due diligence to do anyway), APPEL remains a
> mechanism for user agents like IE6 or Mozilla to attempt to acquire a
> P3P policy from some P3P policy author. 

Not at all and it never was. It is a mechanism to export privacy
preferences from the user to the database maintainer, exactly the
thing we want with the <private> element.






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 g9MDoKcE016581 for <[e-mail]>; Tue, 22 Oct 2002 15:50:20 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9MDoKrd016580 for ietf-provreg-outgoing; Tue, 22 Oct 2002 15:50:20 +0200 (MEST)
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 g9MDoJcE016575 for <[e-mail]>; Tue, 22 Oct 2002 15:50:19 +0200 (MEST)
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 g9MDovtE010237; Tue, 22 Oct 2002 09:50:57 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Stephane Bortzmeyer <[e-mail]>
cc: "Hollenbeck, Scott" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: "private" Element Attribute 
In-Reply-To: Your message of "Tue, 22 Oct 2002 14:09:22 +0200." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 22 Oct 2002 09:50:57 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Stepane,

No "ultra-simple" proposals. I agree.

Example, personally identifying information (PII) disclosure

	a) via whois:43 (or other forms of whois-like services)
	   to j-random query engines
vs
	b) via bulk transfer
	   to corporate members of the "other" IAB
	   (Internet Advertizing Bureau)

The user acceptance is based upon probability (assumed low so an
"acceptable risk") vs certainty. In the whois:43 list there was
evidence that the probability of PII harvesting from whois:43 is
high.

> I suggest instead to rely on a function of EPP: the fact that you can
> include XML elements which are not in the official schema.

Please see the discussion of the data collection policy <dcp> element,
in the -07 draft. This stuff got formalized for us around the London
meeting.

Unless the APPEL draft has changed significantly (and I'll check, I've
got some P3P Spec WG due diligence to do anyway), APPEL remains a
mechanism for user agents like IE6 or Mozilla to attempt to acquire a
P3P policy from some P3P policy author. It isn't a mechanism to assert
some access/retention/distribution/... policy upon a data flow from a
UA.

> That way, we would build on an existing and documented and recognized
> and quite comprehensive framework (managing its privacy preferences is
> complicated enough that we do not introduce a new framework).

Hmm. I don't want to make the same (IMO) error of judgement that has lead
to people thinking someone has the only comprehensive framework for FOO,
e.g., the Unicoders and character sets. That said, covering the three basic
forms of policy (EU Directives, OEDC Guidelines, and US FTC) took the P3P
activity some time. We have an additional issue, jurisdictionalization,
which shows up in the ICANN gTLD vs IANA ccTLD policy claims at the protocol
level, and possibly elsewhere, e.g., in delegations below the top level.

We have some of P3P's vocabulary. What are we missing, and speaking to the
point made by Randy, what do we need to do to get element-wise properties?

I have to write something sensible for the p3p workshop this week, so if
anyone has any ideas they'd like me to noodle about, drop me a line. Here
what the Chair sent yesterday:

	I hope all of you have seen the information about the
	upcoming workshop on the future of P3P. If not, please
	take a look at http://www.w3.org/2002/p3p-ws/
	
	I hope that a number of you will participate. Officially
	the deadline has passed, but we do have room for
	more participants, so please let me know ASAP if you
	want to participate. This workshop will help W3C
	decide what sort of P3P-related efforts to continue
	in the future, so it is important that we get input from
	a diverse set of people. We expect the workshop to
	be more discussion than presentation, so participation
	from people in this working group who are familiar with
	what is in the current spec will be very helpful.

Kitakitamatsinopowaw, (see you all again)
Eric


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 g9MC9ScE015656 for <[e-mail]>; Tue, 22 Oct 2002 14:09:28 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9MC9SWm015655 for ietf-provreg-outgoing; Tue, 22 Oct 2002 14:09:28 +0200 (MEST)
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 g9MC9RcE015650 for <[e-mail]>; Tue, 22 Oct 2002 14:09:27 +0200 (MEST)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id g9MC9N7I1450167; Tue, 22 Oct 2002 14:09:23 +0200 (CEST)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id C565510F2C; Tue, 22 Oct 2002 14:09:22 +0200 (CEST)
Date: Tue, 22 Oct 2002 14:09:22 +0200
From: Stephane Bortzmeyer <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re: "private" Element Attribute
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 Mon, Oct 21, 2002 at 10:08:29AM -0400,
 Hollenbeck, Scott <[e-mail]> wrote 
 a message of 42 lines which said:

> In the ongoing IESG discussion of our EPP documents, we (Patrik and I) have
> come to the conclusion that we might need to add a new attribute to every
> object element in the domain, contact, and host mappings.  This boolean
> attribute, "private", will be used to note that the value of an element
> should not be disclosed to third parties. 

OK, privacy is a touchy subject and a complicated one. I would
disagree with such "ultra-simple" proposals that give the impression
we do something for privacy-conscious people while we do not really
address the full range of the subject. 

For instance, many people would agree that their coordinates are
displayed in reply to a whois query but not that they are included in
a bulk transfer of the database to a spammer (ooops, I mean marketer).

I suggest instead to rely on a function of EPP: the fact that you can
include XML elements which are not in the official schema. For
instance, P3P <URL:http://www.w3.org/TR/P3P/> elements could be added
in the EPP flow from the registry to the registrar and APPEL elements
from the registrar to the registry.

That way, we would build on an existing and documented and recognized
and quite comprehensive framework (managing its privacy preferences is
complicated enough that we do not introduce a new framework).





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 g9MBfocE015439 for <[e-mail]>; Tue, 22 Oct 2002 13:41:50 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9MBfoN3015438 for ietf-provreg-outgoing; Tue, 22 Oct 2002 13:41:50 +0200 (MEST)
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 g9MBfmcE015433 for <[e-mail]>; Tue, 22 Oct 2002 13:41:49 +0200 (MEST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11893; Tue, 22 Oct 2002 07:39:31 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: [e-mail], [e-mail], [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-jseng-idn-admin-01.txt
Date: Tue, 22 Oct 2002 07:39:30 -0400
Sender: [e-mail]
Precedence: bulk

--NextPart

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


	Title		: Internationalized Domain Names Registration and 
                          Administration Guideline for Chinese, Japanese and 
                          Korean
	Author(s)	: J. Seng, J. Klensin et al.
	Filename	: draft-jseng-idn-admin-01.txt
	Pages		: 20
	Date		: 2002-10-21
	
Achieving internationalized access to domain names raises many complex 
issues.  These include not only associated with basic protocol design 
(i.e., how the names are represented on the network, compared, and 
converted to appropriate forms) but also issues and options for 
deployment, transition, registration and administration.

The IETF IDN working group focused on the development of a standards 
track specification for access to domain names in a broader range of 
scripts than the original ASCII.  It became clear during its efforts 
that there was great potential for confusion, and difficulties in 
deployment and transition, due to characters with similar appearances 
or interpretations and that those issues could best be addressed 
administratively, rather than through restrictions embedded in the 
protocols. 

This document provides guidelines for zone administrators (including 
but not limited to registry operators and registrars), and information 
for all domain names holders, on the administration of those domain 
names which contain characters drawn from Chinese, Japanese and Korean 
scripts (CJK).  Other language groups are encouraged to develop their 
own guidelines as needed, based on these guideline if that is helpful.

Comments on this document can be sent to the authors at 
[e-mail].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jseng-idn-admin-01.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-jseng-idn-admin-01.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-jseng-idn-admin-01.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-jseng-idn-admin-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-jseng-idn-admin-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




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 g9LK6qcE008161 for <[e-mail]>; Mon, 21 Oct 2002 22:06:52 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9LK6qPE008160 for ietf-provreg-outgoing; Mon, 21 Oct 2002 22:06:52 +0200 (MEST)
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 g9LK6ocE008155 for <[e-mail]>; Mon, 21 Oct 2002 22:06:51 +0200 (MEST)
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 g9LK7btE006198; Mon, 21 Oct 2002 16:07:37 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: Follow-up on IESG Comment #6 
In-Reply-To: Your message of "Mon, 21 Oct 2002 14:54:23 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 21 Oct 2002 16:07:37 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> The suggested change to section 2.1 of epp-07 was to change this line:
> 
> - The transport mapping MUST manage congestion.
> 
> to:
> 
> - The transport mapping MUST only be to an IETF standards
> track congestion control protocol such as TCP or SCTP, or to
> a protocol which uses one of these.

Well, that's sort of an improvement, since now I won't have attempt to make
the case that EPP/SMTP/TCP (or EPP/HTTP/TCP) doesn't need an explicit form
of congestion control, as that exists in the lower layer ...


BUT

I can't think of a reason why EPP/SMTP/UUCP isn't just as useful (if not
more useful) than EPP/SMTP/TCP. But then UUCP isn't an IETF standards
track congestion control protocol. UUCP isn't an IETF standard at all.

What are we trying to do here? Prevent an EPP/FOO draft from publication
(in any of experimental, informational, best practices, standard niches),
or require that interoperable EPP implementations are capable of using
congestion control in the presence (or possibility) of congestive collapse?

If the former, I'm not interested. It isn't a technical issue.

If the latter, I'm interested. It is both a technical (how to) issue, and
a operational best-practices (when to) issue.

I'm not too keen on the prescriptive presumption. This may be an aesthetic
issue, or my personal skepticism about practice and theory.

So, my two beads worth of wampum is:

The transport mapping MUST provide a mechanism to detect congestion,
and to apply standards track congestion control, e.g., TCP or SCTP,
when congestion is detected.

It is the ABSURDLY STRONG RECOMMENDATION that the EPP implementations
attempt to detect congestion, and when congestion is present, that the
TCP transport mapping, or the SCTP transport mapping, if available, is
used.

Well, a diaper calls.
Eric


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 g9LIsRcE007561 for <[e-mail]>; Mon, 21 Oct 2002 20:54:27 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9LIsRTr007560 for ietf-provreg-outgoing; Mon, 21 Oct 2002 20:54:27 +0200 (MEST)
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 g9LIsQcE007555 for <[e-mail]>; Mon, 21 Oct 2002 20:54:26 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA23333 for <[e-mail]>; Mon, 21 Oct 2002 14:54:25 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <4RC7DLZL>; Mon, 21 Oct 2002 14:54:12 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Follow-up on IESG Comment #6
Date: Mon, 21 Oct 2002 14:54:23 -0400
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

Here's another update on the conversations that Ed, Jaap, and I have been
having with members of the IESG regarding their EPP comments.  This update
specifically addresses comment #6 described earlier [1].

The suggested change to section 2.1 of epp-07 was to change this line:

- The transport mapping MUST manage congestion.

to:

- The transport mapping MUST only be to an IETF standards
track congestion control protocol such as TCP or SCTP, or to
a protocol which uses one of these.

Suggested improvements or issues?  Please reply to the list.

-Scott-

[1]
http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00023.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 g9LHu6cE006914 for <[e-mail]>; Mon, 21 Oct 2002 19:56:06 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9LHu6q7006913 for ietf-provreg-outgoing; Mon, 21 Oct 2002 19:56:06 +0200 (MEST)
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 g9LHu4cE006908 for <[e-mail]>; Mon, 21 Oct 2002 19:56:05 +0200 (MEST)
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 g9LHurtE005691; Mon, 21 Oct 2002 13:56:53 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: "private" Element Attribute 
In-Reply-To: Your message of "Mon, 21 Oct 2002 12:40:31 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 21 Oct 2002 13:56:53 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> I knew I was going to regret reopening this issue, but the IESG hasn't
> bought the "we've been through this and what you see is what we came up
> with" argument.

It could be worse. when I attempted to assist a current and former member
of that august body on a memo on the mechanism for http state management,
their responses were something along the lines of "we don't need help, we
are the IESG", or something significantly less cheritable.

Before we take our first step down this bunny trail we need to know if what
we are creating a mechanism for is a policy assertion by a registrant, or a
registry, or some intermediary, AND, if the policy can be observed in its
instantiation. The exection value of a "Do/Will not give FOO to Martians"
policy claim, wheather by the source of FOO or the sink of FOO is slightly
harder to evaluate than "Do not s/FOO/BAR/", at least in the case where the
source has access to the sink sufficient to detect non-tampering with FOO.

Now I think that adding these to <recipient> are sensible:

	<dns/>	(after all, that was the point, neh?)
	<whois>	(possibly several permutations, ARIN just published theirs
		 today, e.g., :43, uwho, arin, ripe, ++, ...)

I'm open to revisiting the <dcp>, so that it is no longer an announcement
mechanism for data collectors, but something that has manditory error
semantics (if present), e.g.,

	<contact:email private="true">[e-mail]</contact:email>

causes a server error condition if the server-registry announced (regardless
of the scope of the announcement, a seperate topic) <dcp> is inconsistent
with the user-registrant asserted (new term) "data surrender policy" <dsp>.

Which default for no <dcp> (it is optional after all) is a choice. It could
mean "do whatever the user asserts", or "ignore asserts". The better choice
may be to make the <dcp> manditory, then deal with <dsp> != <dcp> cases.

I think this is a way to meet this:

	... what is missing is a mechanism for a user/registrant/etc. to
	flag individual elements that need to be protected in accordance
	with some stated policy.

Now we just need to decide if this is the protocol's job with the server
performing detection and enforcment (see error, above), or if the protocol's
job is to transport data which has access control, independent of the server.

	Blanket acceptance of whatever the stated policy might be doesn't
	appear to address their concern.

Error semantics give them what they need.

I'm at a loss to figure out why granularity smaller than the social/technial
split on the contact object is something Randy/Patrik/... are keen on.


Just to keep a straight face on the value of privacy, this isn't a function
that anyone appears willing to invest in. I've made $0.00 in the area since
the bubble burst, it seems to be everyone's violin d'ingres.

Oh well, at least the Silverbacks aren't calling it "Security", so some bit
of forward progress has been made since Pittsburg.

Cheers,
Eric

P.S. In P3P-esse, they are asking for a binding form of APPEL. Hence policy
negociation, or at least error semantics.


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 g9LGeZcE006290 for <[e-mail]>; Mon, 21 Oct 2002 18:40:35 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9LGeZ6O006289 for ietf-provreg-outgoing; Mon, 21 Oct 2002 18:40:35 +0200 (MEST)
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 g9LGeYcE006284 for <[e-mail]>; Mon, 21 Oct 2002 18:40:34 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA14792; Mon, 21 Oct 2002 12:40:33 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <4RC7D2Y5>; Mon, 21 Oct 2002 12:40:19 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Eric Brunner-Williams in Portland Maine'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: "private" Element Attribute 
Date: Mon, 21 Oct 2002 12:40:31 -0400
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

Eric,

I knew I was going to regret reopening this issue, but the IESG hasn't
bought the "we've been through this and what you see is what we came up
with" argument.

Regarding the domain example I gave, your guess was correct: it could mean
that the registration event itself must remain undisclosed.

> Now Randy's point was different, the scope of some semantic. 
> At present, we
> have a <dcp> in a <greeting>, providing EPP-session scope to 
> whatever sort
> of data collection practices semantic we have. Could we make 
> the granularity
> scope sensibly smaller than EPP-session?

I don't think that would do the trick.  The DCP stuff is in there and has
been for a while, yet Randy still asked the question.  I don't think it
addresses Randy's concern, even if we added additional elements to describe
more narrowly scoped server policies, based on the conversations I've had
with Randy and Patrik over the last few days.  Randy (and now Patrik)
believe that what is missing is a mechanism for a user/registrant/etc. to
flag individual elements that need to be protected in accordance with some
stated policy.  Blanket acceptance of whatever the stated policy might be
doesn't appear to address their concern.

-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 g9LGQYcE006157 for <[e-mail]>; Mon, 21 Oct 2002 18:26:35 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9LGQY6l006156 for ietf-provreg-outgoing; Mon, 21 Oct 2002 18:26:34 +0200 (MEST)
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 g9LGQWcE006151 for <[e-mail]>; Mon, 21 Oct 2002 18:26:33 +0200 (MEST)
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 g9LGRMtE005413; Mon, 21 Oct 2002 12:27:22 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: "private" Element Attribute 
In-Reply-To: Your message of "Mon, 21 Oct 2002 10:08:29 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 21 Oct 2002 12:27:22 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Scott,

This is "policy".

I proposed moving 954 to historic, so there would be no "IETF Impremature" for
repurposing social data. Bob Braden seems to be of the view that changing the
status of 954 would make the protocol go away. I don't know how, but he had a
"third-rail" response when he saw the draft in the announce list. He wasn't
alone in thinking I'd come down with the IETF-equivalent to head lice.

What is out there, the ICANN zoo, data wholesalers, data miners, the EU
Directives, its beyond us.

I understand that Patrik wants to stick a bi-valued switch on each object in
the tree. Sic transit gloria whois.

This no more extensible than Hong's dohicky for registry-private (nexus and
purpose) policy cruft. It doesn't get extensible until schematized.


Unrestricted third-party access (with no guarantee of accuracy) comes from
the <recipient> element, with a value of <public/>.

We could add the pestilential form specific to the domain name industry,
mandated by 954 (which the RIRs sanely ignore, but ICANN is fixated upon),
and add a <whois> element as a child of the <recipient>, and even allow it
child elements.

The effect would be that registries that publish via 954 (private) data
could announce their (US DoD EXPIRED, ICANN CONTEMPORARY MANDATED) policy.

If the WG consensus is to adopt Patrik's proposal, I suggest that the better
default value is "true", not "false".

I don't think Patrik's proposal sensible. Here's the example from -07, with
interlinear comments, with an "or" passage:

  S:    <dcp>
  S:      <access><all/></access>
		(the originator can see his/her data, detecting error, OK)
  S:      <statement>
  S:        <purpose><admin/><prov/></purpose>
		("admin" and provisioning only, OK)
  S:        <recipient><ours/></recipient>
		(the data is provisioned only and apparently not published)
or

  S:        <recipient><ours/><public/></recipient>
		(the data is provisioned and published via :43)
  S:        <retention><stated/></retention>
  S:      </statement>
  S:    </dcp>

It appears that we ment publication via the zone file is implicit in <ours/>.

Now we could change the sense of <ours/> to no-publication, just internal
use, and add a <dns/> and a <whois/> for publication forms and allow dcp's
like these:

  S:        <recipient><ours/><dns/><whois/></recipient>
		(classical 954)
or
  S:        <recipient><ours/><dns/><whois/><public/></recipient>
		(classical 954 plus some non-43 publication, ala IM et al)
or
  S:        <recipient><ours/><dns/><whois/><unrelated/></recipient>
		(classical 954 plus bulk sale to cash-n-carry marketers)
or
  S:        <recipient><ours/><dns/></recipient>
		(a dns-only registry, yeah!)



There is an interesting nuance on one of your examples:

	<domain:name private="false">example.com</domain:name>

Why would this ever be "private"? Since we don't have a dns-or-whois flag
(yet), isn't every domain published (via dns)? Ans: This could allow the
private registration of names, moving strings out of the registry's string
space, without disclosing the fact that the string has been taken for non-
administrative purposes.


The problem is that there is an equivalency-class of registries (and also
of registrars) who MUST do whatever silly thing is in their business paper,
In particular, they must ignore jurisdictional claims which conflict with
the policies contained in their business paper, and must provide whois:43
in its US DoD form (actually in its MILNET TAC (strongest) form).

As wide-spread as this abuse is, it is not generic, it is not automatically
applicable to the ccTLD registries, who would have to be crazy to sign the
ICANN contract, and irrelevent to the RIR registries, a class of non-TLD
registries that may use EPP.

As with Hong's dohickey, existance or absence of whois:43 is registry-private
policy cruft.

Incidently, noWhois as a policy could be fulfilled and the email data sold
to 3rd-party marketers, or used to promote additional registry (or registrar,
or reseller) products and services.

More than one cork is required to keep a boat afloat that has two or more
holes. Shooting whois:43 in the head is always a good idea. Leaving the
registries free to not implement an optional <dcp> that would disclose the
bulk sale of customer profiles is not an equally good idea.

Since the additional attribute would not be "optional" (it has two defined
values), this (limited) form of "privay enablement" would be manditory to
implement, unlike the <dcp>, which we've left optional.

The proposal (bivalue attribute added to all elements) doesn't add function
not already present in the <dcp>, with the implicit nuance that <dcp>s have
EPP-session scope, which leads to an operational set-up/tear-down overhead
to delta the <dcp> on per-object basis.


I'm opposed. I'm opposed to a scopeless bivalued semantic addition. I would
not like the idea any better if the proposal was to color every element, so
long as the color was either black or white. 


Now Randy's point was different, the scope of some semantic. At present, we
have a <dcp> in a <greeting>, providing EPP-session scope to whatever sort
of data collection practices semantic we have. Could we make the granularity
scope sensibly smaller than EPP-session?


Sure.



A point of my query yesterday was that some data is participant-private, so
the access model for blobs-o-gunk during onward-transport from the originator
(registrant) to the (authoritative) repositor{y,ies} might not be uniform.
Suppose for a moment we'd wicked-good element-wise XML crypto, and the email
address ([e-mail]) was delivered to the registry encrypted. The registry
could transparently publish "[e-mail]", making Patrick happy.

Comments by Janusz (enum), and Mike (<info> affected) noted while writing.
Enum is not the answer, per Scott. <info> scoping and contact-private-creep
seems reasonable and probable, assuming an outcome I'd prefer not.

Eric

> Randy:
> 
> 8.
> why do domain/contact/.. not have granular information about privacy?


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 g9LGMicE006102 for <[e-mail]>; Mon, 21 Oct 2002 18:22:44 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9LGMiWp006101 for ietf-provreg-outgoing; Mon, 21 Oct 2002 18:22:44 +0200 (MEST)
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 g9LGMgcE006096 for <[e-mail]>; Mon, 21 Oct 2002 18:22:42 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA13844; Mon, 21 Oct 2002 12:22:41 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <4RC7D2L7>; Mon, 21 Oct 2002 12:22:28 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Mike Lampson'" <[e-mail]>, "'ietf-provregcafaxse'" <[e-mail]>
Subject: RE: "private" Element Attribute
Date: Mon, 21 Oct 2002 12:22:40 -0400
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

> Would "private" object elements appear to non-sponsoring entities
> (Registrars) when they issue the "info" command?

If the client has the authInfo I think this is fine.  The restriction would
be better phrased as "do not disclose to unauthorized third parties".

-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 g9LFgVcE005745 for <[e-mail]>; Mon, 21 Oct 2002 17:42:31 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9LFgVJI005744 for ietf-provreg-outgoing; Mon, 21 Oct 2002 17:42:31 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp03.infoave.net (smtp03.infoave.net [165.166.0.28]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g9LFgTcE005739 for <[e-mail]>; Mon, 21 Oct 2002 17:42:30 +0200 (MEST)
Received: from ML ([165.166.145.85]) by SMTP00.InfoAve.Net (PMDF V6.1-1X1 #38777) with SMTP id <[e-mail]> for [e-mail]; Mon, 21 Oct 2002 11:41:48 -0400 (EDT)
Date: Mon, 21 Oct 2002 11:41:46 -0400
From: Mike Lampson <[e-mail]>
Subject: Re: "private" Element Attribute
To: "'ietf-provregcafaxse'" <[e-mail]>
Cc: Hollenbeck Scott <[e-mail]>
Message-id: <013901c27918$5d701e00$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References:  <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Scott,

Would "private" object elements appear to non-sponsoring entities
(Registrars) when they issue the "info" command?

My preference would be that "info" would only show non-private object
elements to non-sponsoring entities *unless* the non-sponsoring entity has a
valid AuthInfo code.  This allows the elements to remain private, but also
allows for the values to be disclosed to another Registrar if they have been
provided the correct AuthInfo code.  While this isn't necessary at a
protocol level to initiate a transfer, it is necessary at an administrative
level so that the potential gaining Registrar knows whose domain they are
actually transferring.  (It's better to verify that the Transfer is being
initiated by a current contact for the domain rather than a former employee
or other individual who may have somehow acquired the AuthInfo code.)

I expect that once a "private" attribute is implemented at a Registry that
you are not going to see just phone numbers and email addresses marked as
private, but entire contacts will be marked as private.  Hence my
recommendation for the "info" comand to show everything when a valid
AuthInfo code is included.

Just my 2cents,

Mike Lampson
The Registry at Info Avenue, LLC
(Really a Registrar, not a Registry)


----- Original Message -----
From: "Hollenbeck Scott" <[e-mail]>
To: "'ietf-provregcafaxse'" <[e-mail]>
Sent: Monday, October 21, 2002 10:08 AM
Subject: "private" Element Attribute


A heads-up to the WG related to IESG comment #8, described here [1]:

In the ongoing IESG discussion of our EPP documents, we (Patrik and I) have
come to the conclusion that we might need to add a new attribute to every
object element in the domain, contact, and host mappings.  This boolean
attribute, "private", will be used to note that the value of an element
should not be disclosed to third parties.  It will have a default value of
"false" meaning it is ok to disclose info.  Additional constraints can be
defined using the protocol extension mechanism.

Here are some examples:

<contact:email private="true">[e-mail]</contact:email>

<domain:name private="false">example.com</domain:name>

<host:addr ip="v4" private="true">192.1.2.3</host:addr>

<extension>
  <noWhois><contact:email></noWhois>
</extension>

(This extension example isn't syntactically valid, but I wanted it to be
short, clear, and to the point without the clutter needed to make it valid.
In this case it means that the email address should not be published via
whois.)

Patrik's point is that we start getting into the policy issues that bogged
us down earlier if we try to pick and choose the elements to which the
attribute should be added.  That's a good point that can get us past where
we failed a year or so ago, but it means that server operators might have to
deal with some operational inconsistencies.  We'll have to add some notes to
explain that server policy might not recognize the value of an attribute if
it's turned on (like in the address example above) when turning on the
attribute is counter to some policy.

If anyone has any issues with this approach, please mention them now.

-Scott-

[1]
http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00023.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 g9LF0ncE005194 for <[e-mail]>; Mon, 21 Oct 2002 17:00:49 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9LF0n9R005193 for ietf-provreg-outgoing; Mon, 21 Oct 2002 17:00:49 +0200 (MEST)
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 g9LF0lcE005188 for <[e-mail]>; Mon, 21 Oct 2002 17:00:48 +0200 (MEST)
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 LAA08550; Mon, 21 Oct 2002 11:00:46 -0400 (EDT)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <TF9XX9QY>; Mon, 21 Oct 2002 11:00:46 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'janusz sienkiewicz'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: "private" Element Attribute
Date: Mon, 21 Oct 2002 11:00:44 -0400
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: janusz sienkiewicz [mailto:[e-mail]]
> Sent: Monday, October 21, 2002 10:59 AM
> To: Hollenbeck, Scott
> Cc: '[e-mail]'
> Subject: Re: "private" Element Attribute
> 
> 
> Wouldn't it be more convenient to redefine private attribute 
> as enumeration
> versus boolean? For example:
> 
> <contact:email private="true">[e-mail]</contact:email>
> 
> could be replaced by:
> 
> <contact:email access=enumValue>[e-mail]</contact:email>
> 
> Where enumValue could be: private, public, noWhois, etc.
> 
> Among other petential benefits this approach could eliminate 
> the inconvenience
> of using <extension>.

There's no real benefit to an enumeration because to add new elements to the
enumeration we'd have to rev the protocol -- we can't extend enumerations.
using the extension mechanism means we can add new elements, policies, etc.
without having to produce a new version of the protocol.

Plus, we'd have to agree on all of the possible enumeration elements and
then we'd still be left with no room for extension without revising the
protocol.  We tried talking through identification of policy elements some
time ago when we talked about privacy requirements, and we got nowhere.  The
results of that discussion is in the archives somewhere.

-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 g9LErtcE005114 for <[e-mail]>; Mon, 21 Oct 2002 16:53:55 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9LErtPi005113 for ietf-provreg-outgoing; Mon, 21 Oct 2002 16:53:55 +0200 (MEST)
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 g9LErscE005108 for <[e-mail]>; Mon, 21 Oct 2002 16:53:54 +0200 (MEST)
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 183dwD-0005iG-00; Mon, 21 Oct 2002 10:53:49 -0400
Message-ID: <[e-mail]>
Date: Mon, 21 Oct 2002 10:58:50 -0400
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: "private" Element Attribute
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Wouldn't it be more convenient to redefine private attribute as enumeration
versus boolean? For example:

<contact:email private="true">[e-mail]</contact:email>

could be replaced by:

<contact:email access=enumValue>[e-mail]</contact:email>

Where enumValue could be: private, public, noWhois, etc.

Among other petential benefits this approach could eliminate the inconvenience
of using <extension>.

Regards,

Janusz Sienkiewicz

"Hollenbeck, Scott" wrote:

> A heads-up to the WG related to IESG comment #8, described here [1]:
>
> In the ongoing IESG discussion of our EPP documents, we (Patrik and I) have
> come to the conclusion that we might need to add a new attribute to every
> object element in the domain, contact, and host mappings.  This boolean
> attribute, "private", will be used to note that the value of an element
> should not be disclosed to third parties.  It will have a default value of
> "false" meaning it is ok to disclose info.  Additional constraints can be
> defined using the protocol extension mechanism.
>
> Here are some examples:
>
> <contact:email private="true">[e-mail]</contact:email>
>
> <domain:name private="false">example.com</domain:name>
>
> <host:addr ip="v4" private="true">192.1.2.3</host:addr>
>
> <extension>
>   <noWhois><contact:email></noWhois>
> </extension>
>
> (This extension example isn't syntactically valid, but I wanted it to be
> short, clear, and to the point without the clutter needed to make it valid.
> In this case it means that the email address should not be published via
> whois.)
>
> Patrik's point is that we start getting into the policy issues that bogged
> us down earlier if we try to pick and choose the elements to which the
> attribute should be added.  That's a good point that can get us past where
> we failed a year or so ago, but it means that server operators might have to
> deal with some operational inconsistencies.  We'll have to add some notes to
> explain that server policy might not recognize the value of an attribute if
> it's turned on (like in the address example above) when turning on the
> attribute is counter to some policy.
>
> If anyone has any issues with this approach, please mention them now.
>
> -Scott-
>
> [1]
> http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00023.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 g9LE8ZcE004612 for <[e-mail]>; Mon, 21 Oct 2002 16:08:35 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9LE8Z69004611 for ietf-provreg-outgoing; Mon, 21 Oct 2002 16:08:35 +0200 (MEST)
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 g9LE8XcE004606 for <[e-mail]>; Mon, 21 Oct 2002 16:08:34 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA04891 for <[e-mail]>; Mon, 21 Oct 2002 10:08:32 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <4RC7DFDX>; Mon, 21 Oct 2002 10:08:19 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: "private" Element Attribute
Date: Mon, 21 Oct 2002 10:08:29 -0400
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

A heads-up to the WG related to IESG comment #8, described here [1]:

In the ongoing IESG discussion of our EPP documents, we (Patrik and I) have
come to the conclusion that we might need to add a new attribute to every
object element in the domain, contact, and host mappings.  This boolean
attribute, "private", will be used to note that the value of an element
should not be disclosed to third parties.  It will have a default value of
"false" meaning it is ok to disclose info.  Additional constraints can be
defined using the protocol extension mechanism.

Here are some examples:

<contact:email private="true">[e-mail]</contact:email>

<domain:name private="false">example.com</domain:name>

<host:addr ip="v4" private="true">192.1.2.3</host:addr>

<extension>
  <noWhois><contact:email></noWhois>
</extension>

(This extension example isn't syntactically valid, but I wanted it to be
short, clear, and to the point without the clutter needed to make it valid.
In this case it means that the email address should not be published via
whois.)

Patrik's point is that we start getting into the policy issues that bogged
us down earlier if we try to pick and choose the elements to which the
attribute should be added.  That's a good point that can get us past where
we failed a year or so ago, but it means that server operators might have to
deal with some operational inconsistencies.  We'll have to add some notes to
explain that server policy might not recognize the value of an attribute if
it's turned on (like in the address example above) when turning on the
attribute is counter to some policy.

If anyone has any issues with this approach, please mention them now.

-Scott-

[1]
http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00023.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 g9KI7JcE027589 for <[e-mail]>; Sun, 20 Oct 2002 20:07:19 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9KI7JEH027588 for ietf-provreg-outgoing; Sun, 20 Oct 2002 20:07:19 +0200 (MEST)
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 g9KI7HcE027581 for <[e-mail]>; Sun, 20 Oct 2002 20:07:18 +0200 (MEST)
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 g9KI67pt017924; Sun, 20 Oct 2002 14:06:07 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: <authInfo> in Transfer Query for Domain and Contact 
In-Reply-To: Your message of "Fri, 11 Oct 2002 20:14:22 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Sun, 20 Oct 2002 14:06:07 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

The (non)problem and unrelated work, got me to wondering if there any of
the following are "real":

	o an intermediary should not access an element,

	  is there any data that neither the (optional) agent, and/or the
	  registrar need NOT know? 

	o not all the data has the same access permissions,

	o transformations are applied selectively, possibly w/o access,
	  to some data,

Let me know if this kind of stuff would be useful out there in "competitive
registrar land" (where I've no experience).

Eric


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 g9KHeKcE027389 for <[e-mail]>; Sun, 20 Oct 2002 19:40:20 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9KHeKXS027388 for ietf-provreg-outgoing; Sun, 20 Oct 2002 19:40:20 +0200 (MEST)
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 g9KHeIcE027383 for <[e-mail]>; Sun, 20 Oct 2002 19:40:19 +0200 (MEST)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g9KHeHFP007267; Sun, 20 Oct 2002 10:40:17 -0700 (PDT)
Date: Sun, 20 Oct 2002 10:40:17 -0700 (PDT)
From: Rick Wesson <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: <authInfo> in Transfer Query for Domain and Contact
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>
> Actually, no, I don't think it's a problem.  While the losing client can't
> track the status via the <transfer> query after the authInfo gets changed,
> they are informed of the completion of the transfer via queued and polled
> messages -- so we have the requirement met.
>
> -Scott-


Also a registrar may still get info and status information which will
identify the registrar of record.

-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 g9KHVZcE027329 for <[e-mail]>; Sun, 20 Oct 2002 19:31:35 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9KHVZSw027328 for ietf-provreg-outgoing; Sun, 20 Oct 2002 19:31:35 +0200 (MEST)
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 g9KHVYcE027323 for <[e-mail]>; Sun, 20 Oct 2002 19:31:34 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g9KHVWbX048312 for <[e-mail]>; Sun, 20 Oct 2002 19:31:32 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id g9KHVWI7048311 for [e-mail]; Sun, 20 Oct 2002 19:31:32 +0200 (CEST)
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 g9C0GmcE003981 for <[e-mail]>; Sat, 12 Oct 2002 02:16:49 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id UAA18413; Fri, 11 Oct 2002 20:14:42 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <4RC679DZ>; Fri, 11 Oct 2002 20:14:41 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: <authInfo> in Transfer Query for Domain and Contact
Date: Fri, 11 Oct 2002 20:14:22 -0400
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 question about <authInfo> being mandatory for the <transfer>
> command. I understand that it was added into EPP-06 [1] based on the
> "spying" issue raised by Dan Manley [2]. I also feel that 
> this parameter
> should be mandatory for the other four operations related to 
> <transfer>,
> i.e., request, cancel, reject and approve.
> 
> However, there is a special case where it is helpful NOT to 
> make <authInfo>
> manadatory. The scenario is the following: domain abc.tld is 
> transferred
> from Registrar A to Registrar B. During the transfer pending 
> period, both A
> and B share the knowledge of the same <authInfo> of abc.tld. 
> However, after
> the transfer is completed successfully, Registrar B may change the
> <authInfo> (for security reasons or at the request of the registrar of
> abc.tld). Once that happens, Registrar B will not be able to see the
> transfer result of abc.tld anymore...However, GRRP 
> Requirements (RFC 3375)
> requires that (page 10):
> 
> [8] The protocol MUST provide services that allow both the original
> sponsoring registrar and the potential new registrar to 
> monitor the status
> of both pending and completed transfer requests. 
> 
> The same problem exists for <authInfo> being mandatory for 
> contact transfer.
> 
> Do you think this is a problem in the EPP domain and contact 
> specs that
> needs to be fixed? Thanks!

Actually, no, I don't think it's a problem.  While the losing client can't
track the status via the <transfer> query after the authInfo gets changed,
they are informed of the completion of the transfer via queued and polled
messages -- so we have the requirement met.

-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 g9KHTVcE027305 for <[e-mail]>; Sun, 20 Oct 2002 19:29:31 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9KHTVri027304 for ietf-provreg-outgoing; Sun, 20 Oct 2002 19:29:31 +0200 (MEST)
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 g9KHTUcE027299 for <[e-mail]>; Sun, 20 Oct 2002 19:29:30 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g9KHTTbX048280; Sun, 20 Oct 2002 19:29:30 +0200 (CEST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Liu, Hong" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Subject: Re: <authInfo> in Transfer Query for Domain and Contact 
In-reply-to: Your message of Fri, 11 Oct 2002 19:10:19 -0400. <[e-mail]> 
Date: Sun, 20 Oct 2002 19:29:29 +0200
From: Jaap Akkerhuis <[e-mail]>
Sender: [e-mail]
Precedence: bulk

    For some reason, I did not see this email appear in the archive. So here is
    the resend.
    
Hong,

The reason was:

Subject: BOUNCE [e-mail]:     Admin request of type /\bcancel\b/i at line 7  

Which translates to:

In the first n-lines (I'm not sure about the value of n) the majordomo
server noticed ``cancel'' and thought it was a  cancel request. Me,
being away, hadn't the opportunity to approve the message.

Sorry about all this. It does raises another question: Anybody else
out there willing to share the administrational burden maintaining
the provreg list?

	jaap

To quote the part that triggered the bounce:

	I have a question about <authInfo> being mandatory for the <transfer>
	command. I understand that it was added into EPP-06 [1] based on the
	"spying" issue raised by Dan Manley [2]. I also feel that this parameter
	should be mandatory for the other four operations related to <transfer>,
	i.e., request, cancel, reject and approve.


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 g9KGp0cE027120 for <[e-mail]>; Sun, 20 Oct 2002 18:51:00 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9KGp02M027119 for ietf-provreg-outgoing; Sun, 20 Oct 2002 18:51:00 +0200 (MEST)
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 g9KGoxcE027114 for <[e-mail]>; Sun, 20 Oct 2002 18:50:59 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g9KGosbX047984 for <[e-mail]>; Sun, 20 Oct 2002 18:50:54 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id g9KGorJC047983 for [e-mail]; Sun, 20 Oct 2002 18:50:53 +0200 (CEST)
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 g9BJWacE001674 for <[e-mail]>; Fri, 11 Oct 2002 21:32:37 +0200 (MEST)
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 g9BJWZ131658 for <[e-mail]>; Fri, 11 Oct 2002 19:32:36 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <SZM95QW4>; Fri, 11 Oct 2002 15:32:42 -0400
Message-ID: <[e-mail]>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: <authInfo> in Transfer Query for Domain and Contact
Date: Fri, 11 Oct 2002 15:32:39 -0400
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

Scott,

I have a question about <authInfo> being mandatory for the <transfer>
command. I understand that it was added into EPP-06 [1] based on the
"spying" issue raised by Dan Manley [2]. I also feel that this parameter
should be mandatory for the other four operations related to <transfer>,
i.e., request, cancel, reject and approve.

However, there is a special case where it is helpful NOT to make <authInfo>
manadatory. The scenario is the following: domain abc.tld is transferred
from Registrar A to Registrar B. During the transfer pending period, both A
and B share the knowledge of the same <authInfo> of abc.tld. However, after
the transfer is completed successfully, Registrar B may change the
<authInfo> (for security reasons or at the request of the registrar of
abc.tld). Once that happens, Registrar B will not be able to see the
transfer result of abc.tld anymore...However, GRRP Requirements (RFC 3375)
requires that (page 10):

[8] The protocol MUST provide services that allow both the original
sponsoring registrar and the potential new registrar to monitor the status
of both pending and completed transfer requests. 

The same problem exists for <authInfo> being mandatory for contact transfer.

Do you think this is a problem in the EPP domain and contact specs that
needs to be fixed? Thanks!

--Hong

[1] http://www.cafax.se/ietf-provreg/maillist/2002-01/msg00080.html
[2] http://www.cafax.se/ietf-provreg/maillist/2001-11/msg00043.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 g9IGjlcE012413 for <[e-mail]>; Fri, 18 Oct 2002 18:45:47 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9IGjlvk012412 for ietf-provreg-outgoing; Fri, 18 Oct 2002 18:45:47 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail1-0.chcgil.ameritech.net (mail1-0.chcgil.ameritech.net [206.141.192.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g9IGjkcE012405 for <[e-mail]>; Fri, 18 Oct 2002 18:45:46 +0200 (MEST)
Received: from repligate ([67.37.230.233]) by mail1-0.chcgil.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20021018164544.SIMM23046.mail1-0.chcgil.ameritech.net@repligate>; Fri, 18 Oct 2002 11:45:44 -0500
Message-ID: <003d01c276c5$cd862270$0100a8c0@repligate>
From: "Jim Fleming" <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>, "'Ram Mohan'" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: 0:201     COM....Re: Conformance with ICANN Redemption Grace Periods
Date: Fri, 18 Oct 2002 11:45:42 -0500
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: "Hollenbeck, Scott" <[e-mail]>
To: "'Ram Mohan'" <[e-mail]>; <[e-mail]>
Sent: Friday, October 18, 2002 11:08 AM
Subject: RE: Conformance with ICANN Redemption Grace Periods


> > My understanding was that if we have to add a new status 
> > value for a domain
> > object it cannot be done
> > within the EPP extension framework -- don't the EPP spec and 
> > xml schema
> > definition have to be
> > modified ?
> 
> No, that's what extensions are all about: adding new elements, constructs,
> and procedures for specialized processing without having to modify the core
> schemas.
> 
> I'll gladly provide a strawman extension schema for you and Rick if you'd
> like to consider it for any proposal you might develop.
> 

Have these four companies been provided the information ?

http://www.cashbackalliance.com/domain/domainsfor619.aspx
$6.19
http://www.wildwestdomains.com/pricelist.asp
$6.75
http://www.srsplus.com/en-def-5d142899df19/en/srsplus/partners_pricing.shtml
$8.00
http://resellers.tucows.com/opensrs/
$10.00
====================================================

Jim Fleming
128-bit DNS is closer than you think...
0:201     COM
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




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 g9IGRFcE012238 for <[e-mail]>; Fri, 18 Oct 2002 18:27:15 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9IGREAK012237 for ietf-provreg-outgoing; Fri, 18 Oct 2002 18:27:14 +0200 (MEST)
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 g9IGRDcE012232 for <[e-mail]>; Fri, 18 Oct 2002 18:27:13 +0200 (MEST)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g9IGRBFP010297; Fri, 18 Oct 2002 09:27:11 -0700 (PDT)
Date: Fri, 18 Oct 2002 09:27:07 -0700 (PDT)
From: Rick Wesson <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Ram Mohan'" <[e-mail]>, <[e-mail]>
Subject: RE: Conformance with ICANN Redemption Grace Periods
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Scott,

I would be happy to see your proposal. thanks for offering!

-rick

On Fri, 18 Oct 2002, Hollenbeck, Scott wrote:

> > My understanding was that if we have to add a new status
> > value for a domain
> > object it cannot be done
> > within the EPP extension framework -- don't the EPP spec and
> > xml schema
> > definition have to be
> > modified ?
>
> No, that's what extensions are all about: adding new elements, constructs,
> and procedures for specialized processing without having to modify the core
> schemas.
>
> I'll gladly provide a strawman extension schema for you and Rick if you'd
> like to consider it for any proposal you might develop.
>
> -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 g9IG97cE011994 for <[e-mail]>; Fri, 18 Oct 2002 18:09:07 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9IG97vu011993 for ietf-provreg-outgoing; Fri, 18 Oct 2002 18:09:07 +0200 (MEST)
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 g9IG95cE011980 for <[e-mail]>; Fri, 18 Oct 2002 18:09:05 +0200 (MEST)
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 MAA10578; Fri, 18 Oct 2002 12:09:03 -0400 (EDT)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <TF9XWH7Q>; Fri, 18 Oct 2002 12:09:03 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Ram Mohan'" <[e-mail]>, [e-mail]
Subject: RE: Conformance with ICANN Redemption Grace Periods
Date: Fri, 18 Oct 2002 12:08:53 -0400
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

> My understanding was that if we have to add a new status 
> value for a domain
> object it cannot be done
> within the EPP extension framework -- don't the EPP spec and 
> xml schema
> definition have to be
> modified ?

No, that's what extensions are all about: adding new elements, constructs,
and procedures for specialized processing without having to modify the core
schemas.

I'll gladly provide a strawman extension schema for you and Rick if you'd
like to consider it for any proposal you might develop.

-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 g9IFnxcE011714 for <[e-mail]>; Fri, 18 Oct 2002 17:49:59 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9IFnxFu011713 for ietf-provreg-outgoing; Fri, 18 Oct 2002 17:49:59 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ns01.afilias.info (ns01.afilias.info [66.45.25.225]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g9IFnvcE011708 for <[e-mail]>; Fri, 18 Oct 2002 17:49:57 +0200 (MEST)
Received: from RAMLAPTOP (pcp01379381pcs.levtwn01.pa.comcast.net [68.81.94.117]) (authenticated) by ns01.afilias.info (8.11.2/8.11.2) with ESMTP id g9IFnkQ27609; Fri, 18 Oct 2002 11:49:46 -0400
Message-ID: <02cd01c276bd$fc6ddc70$[e-mail]>
From: "Ram Mohan" <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Conformance with ICANN Redemption Grace Periods
Date: Fri, 18 Oct 2002 11:48:57 -0400
Organization: Afilias
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.2800.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk

Scott,
Thanks for the clarfication.

My understanding was that if we have to add a new status value for a domain
object it cannot be done
within the EPP extension framework -- don't the EPP spec and xml schema
definition have to be
modified ?

(see extract from the redemption grace period proposal below)
> > Accordingly, under the proposal, a registry Whois check on a
> > name that is within the Delete Pending Period would return at least the
following
> > information:
> >
> >   Domain Name: example.com
> >   Sponsoring Registrar: exampleregistrar.com
> >   Domain Status: DELETE PENDING PERIOD
> >   Delete Requested: 31-may-2002

-Ram
--------------------------------------------------------
ram mohan/cto/afilias.info
p: [phone]; f: [phone]
e: [e-mail]
--------------------------------------------------------
----- Original Message -----
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Ram Mohan'" <[e-mail]>; <[e-mail]>
Sent: Thursday, October 17, 2002 6:20 PM
Subject: RE: Conformance with ICANN Redemption Grace Periods


> Protocol extension if needed for ICANN registries.  It's certainly not a
> general-purpose feature that should be added to the core protocol.
>
> -Scott-
>
> > -----Original Message-----
> > From: Ram Mohan [mailto:[e-mail]]
> > Sent: Thursday, October 17, 2002 5:20 PM
> > To: [e-mail]
> > Subject: Conformance with ICANN Redemption Grace Periods
> >
> >
> > Scott,
> > As you may have noticed, in the Bucharest ICANN meeting, the
> > Board resolved
> > to have registries adopt the proposed Redemption Grace Period
> > (http://www.icann.org/bucharest/redemption-topic.htm) policy.
> >
> > Embedded in the document are the following, which may have an
> > impact on EPP.
> > I forward to provreg to determine if any of these need to be
> > factored into
> > our thinking.  (New capability, may or may not need a
> > command; new domain
> > status if agreed to, will require some remapping)
> >
> > -ram
> > >>Creation of New "RESTORE" Capability
> >
> > The Technical Steering Group proposes the creation of a new "RESTORE"
> > capability that can be provided by a registry to registrars
> > via one or more
> > of the following methods: a modification of the
> > registry/registrar protocol,
> > an administration website, a fax service, or a telephone service. The
> > RESTORE capability will only affect names that are within the
> > Delete Pending
> > Period. In other words, all RESTORE requests for names not in
> > the Delete
> > Pending Period will be ignored.
> >
> > >> Registry Transparency Requirements for Deleted Names
> >
> > In order to ensure fairness to all registrants and
> > registrars, the Technical
> > Steering Group proposes that deleted and restored names
> > should be handled as
> > openly and transparently as feasible. Original registrants
> > and those wishing
> > to be "next in line" to register a name that is being deleted
> > should be able
> > to tell when a name was deleted and when it will be "returned
> > to the pool"
> > of names available for registration.
> >
> > Accordingly, under the proposal, a registry Whois check on a
> > name that is
> > within the Delete Pending Period would return at least the following
> > information:
> >
> >   Domain Name: example.com
> >   Sponsoring Registrar: exampleregistrar.com
> >   Domain Status: DELETE PENDING PERIOD
> >   Delete Requested: 31-may-2002



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 g9IEZqcE010950 for <[e-mail]>; Fri, 18 Oct 2002 16:35:52 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9IEZqkv010949 for ietf-provreg-outgoing; Fri, 18 Oct 2002 16:35:52 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ns01.afilias.info (ns01.afilias.info [66.45.25.225]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g9IEZocE010944 for <[e-mail]>; Fri, 18 Oct 2002 16:35:51 +0200 (MEST)
Received: from RAMLAPTOP (pcp01379381pcs.levtwn01.pa.comcast.net [68.81.94.117]) (authenticated) by ns01.afilias.info (8.11.2/8.11.2) with ESMTP id g9IEZWQ26288; Fri, 18 Oct 2002 10:35:33 -0400
Message-ID: <015001c276b3$9f49e980$[e-mail]>
From: "Ram Mohan" <[e-mail]>
To: "Rick Wesson" <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Conformance with ICANN Redemption Grace Periods
Date: Fri, 18 Oct 2002 10:35:27 -0400
Organization: Afilias
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.2800.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk

rick,
i'll take you up on this -- and communicate off-list

-ram
----- Original Message -----
From: "Rick Wesson" <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
Cc: "'Ram Mohan'" <[e-mail]>; <[e-mail]>
Sent: Thursday, October 17, 2002 6:28 PM
Subject: RE: Conformance with ICANN Redemption Grace Periods


>
>
> On Thu, 17 Oct 2002, Hollenbeck, Scott wrote:
>
> > Protocol extension if needed for ICANN registries.  It's certainly not a
> > general-purpose feature that should be added to the core protocol.
>
> yes, maybe an extention in the renew command would be appropiate.
>
> ram, we could develop a proposal...
>
>
> -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 g9HN3BcE003768 for <[e-mail]>; Fri, 18 Oct 2002 01:03:11 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9HN3BPA003767 for ietf-provreg-outgoing; Fri, 18 Oct 2002 01:03:11 +0200 (MEST)
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 g9HN39cE003762 for <[e-mail]>; Fri, 18 Oct 2002 01:03:09 +0200 (MEST)
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 g9HN2Zpt041611; Thu, 17 Oct 2002 19:02:35 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Ram Mohan'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Conformance with ICANN Redemption Grace Periods 
In-Reply-To: Message from "Hollenbeck, Scott" <[e-mail]>  of "Thu, 17 Oct 2002 18:20:02 EDT." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 17 Oct 2002 19:02:35 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Yup. Not general, a registry-equivalency-class private concern.



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 g9HMSVcE003417 for <[e-mail]>; Fri, 18 Oct 2002 00:28:31 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9HMSV7K003416 for ietf-provreg-outgoing; Fri, 18 Oct 2002 00:28:31 +0200 (MEST)
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 g9HMSUcE003411 for <[e-mail]>; Fri, 18 Oct 2002 00:28:30 +0200 (MEST)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g9HMSRFP026892; Thu, 17 Oct 2002 15:28:27 -0700 (PDT)
Date: Thu, 17 Oct 2002 15:28:24 -0700 (PDT)
From: Rick Wesson <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Ram Mohan'" <[e-mail]>, <[e-mail]>
Subject: RE: Conformance with ICANN Redemption Grace Periods
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Thu, 17 Oct 2002, Hollenbeck, Scott wrote:

> Protocol extension if needed for ICANN registries.  It's certainly not a
> general-purpose feature that should be added to the core protocol.

yes, maybe an extention in the renew command would be appropiate.

ram, we could develop a proposal...


-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 g9HMK8cE003355 for <[e-mail]>; Fri, 18 Oct 2002 00:20:08 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9HMK8v4003354 for ietf-provreg-outgoing; Fri, 18 Oct 2002 00:20:08 +0200 (MEST)
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 g9HMK7cE003349 for <[e-mail]>; Fri, 18 Oct 2002 00:20:07 +0200 (MEST)
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 SAA11882; Thu, 17 Oct 2002 18:20:06 -0400 (EDT)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <TF9XVVDR>; Thu, 17 Oct 2002 18:20:06 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Ram Mohan'" <[e-mail]>, [e-mail]
Subject: RE: Conformance with ICANN Redemption Grace Periods
Date: Thu, 17 Oct 2002 18:20:02 -0400
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 g9HMK8cE003350
Sender: [e-mail]
Precedence: bulk

Protocol extension if needed for ICANN registries.  It's certainly not a
general-purpose feature that should be added to the core protocol.

-Scott-

> -----Original Message-----
> From: Ram Mohan [mailto:[e-mail]]
> Sent: Thursday, October 17, 2002 5:20 PM
> To: [e-mail]
> Subject: Conformance with ICANN Redemption Grace Periods
> 
> 
> Scott,
> As you may have noticed, in the Bucharest ICANN meeting, the 
> Board resolved
> to have registries adopt the proposed Redemption Grace Period
> (http://www.icann.org/bucharest/redemption-topic.htm) policy.
> 
> Embedded in the document are the following, which may have an 
> impact on EPP.
> I forward to provreg to determine if any of these need to be 
> factored into
> our thinking.  (New capability, may or may not need a 
> command; new domain
> status if agreed to, will require some remapping)
> 
> -ram
> >>Creation of New "RESTORE" Capability
> 
> The Technical Steering Group proposes the creation of a new "RESTORE"
> capability that can be provided by a registry to registrars 
> via one or more
> of the following methods: a modification of the 
> registry/registrar protocol,
> an administration website, a fax service, or a telephone service. The
> RESTORE capability will only affect names that are within the 
> Delete Pending
> Period. In other words, all RESTORE requests for names not in 
> the Delete
> Pending Period will be ignored.
> 
> >> Registry Transparency Requirements for Deleted Names
> 
> In order to ensure fairness to all registrants and 
> registrars, the Technical
> Steering Group proposes that deleted and restored names 
> should be handled as
> openly and transparently as feasible. Original registrants 
> and those wishing
> to be "next in line" to register a name that is being deleted 
> should be able
> to tell when a name was deleted and when it will be "returned 
> to the pool"
> of names available for registration.
> 
> Accordingly, under the proposal, a registry Whois check on a 
> name that is
> within the Delete Pending Period would return at least the following
> information:
> 
>   Domain Name: example.com
>   Sponsoring Registrar: exampleregistrar.com
>   Domain Status: DELETE PENDING PERIOD
>   Delete Requested: 31-may-2002
> 
> ----- Original Message -----
> From: "Hollenbeck, Scott" <[e-mail]>
> To: <[e-mail]>
> Sent: Thursday, October 17, 2002 2:51 PM
> Subject: FW: IESG Review Comments
> 
> 
> > Forwarded with Patrik's permission for the benefit of the 
> WG, these are
> the
> > comments received back from the IESG's review of the EPP 
> documents.  I'll
> be
> > editing the documents shortly to incorporate the IESG's 
> suggested text
> > changes and others received from the WG over the last few weeks.
> >
> > I've added annotations to number the comments in this 
> message.  We're
> still
> > trying to obtain clarifications for comments 6 and 8.
> >
> > -Scott-
> >
> > -----Original Message-----
> > From: Patrik Fältström [mailto:[e-mail]]
> > Sent: Tuesday, October 15, 2002 5:17 AM
> > To: Scott Hollenbeck
> > Cc: Jaap Akkerhuis; Edward Lewis
> > Subject: Discuss on epp documents
> >
> >
> > [Ooopss....I forgot to click on "send", this window has been sitting
> > for a week in my laptop behind the window with the mailboxes....I AM
> > SORRY]
> >
> >  From IESG:
> >
> > Steve:
> >
> > 1.
> >   > <draft-ietf-provreg-epp-07.txt>  Do we put mailing list 
> names and
> > URLs in RFCs?
> >
> > 2.
> >   I'd like a stronger Security Considerations section, 
> though I think
> >   it can be added by an RFC Editor note. In particular, I want it to
> >   say that EPP "MUST NOT be used over a transport mechanism 
> that does
> >   not provide confidentiality", or "All transport mappings for EPP
> >   MUST provide confidentiality and integrity". (I think 
> that that's what
> >   they intend, but it's not clear enough.)
> >
> > 3.
> >   > <draft-ietf-provreg-epp-domain-05.txt>
> >   What is an "authorization token"? It's not defined, but 
> it's mandated
> >   by the security considerations. (I suspect it's what is 
> discussed in
> >   2.6, but it doesn't use the same words.)
> >
> > 4.
> >   > <draft-ietf-provreg-epp-contact-05.txt>
> >   What is an "authorization token"? It's not defined, but 
> it's mandated
> >   by the security considerations. (I suspect it's what is 
> discussed in
> >   2.8, but it doesn't use the same words.)
> >
> > 5.
> >   > <draft-ietf-provreg-epp-tcp-05.txt>
> >   The Security Considerations section seems to require TLS client
> >   authentication, which in turn requires client 
> certificates. Is this
> >   intended? If so, great! But in that case, what is the 
> fate, if any,
> >   of the EPP login/password command? Is it still needed? Is it still
> >   legal? What does it mean? Must the identities agree? (The 
> requirement
> >   for server authentication is excellent, but some more 
> text mentioning
> >   the need to validate the certificate chain is probably a 
> good idea.)
> >
> > Scott:
> > note:
> >
> > 6.
> > draft-ietf-provreg-epp-07.txt sec 2.1
> >        I think it would be good to be a bit more strict about
> >        the use of congestion control protocols specifically require
> >        the use of an IETF standards track congestion control
> >        protocol such as TCP or SCTP
> >
> >        i.e. change the following line:
> >        - The transport mapping MUST manage congestion.
> >
> >        to:
> >        - The transport mapping MUST only be to an IETF standards
> >        track congestion control protocol such as TCP or SCTP.
> >
> > Bert: document: draft-ietf-provreg-epp-07.txt
> >
> > 7.
> > page 12, example greeting has:
> >
> >      S: <svID>Example EPP server epp.example.tld</svID>
> >
> > in an example greeting. Did we not decide at some point
> > that examples should be of the form: epp.example.org ??
> >
> > Patrik answers:
> >
> >  > We should follow RFC 2606 which states that:
> >  >
> >  > 3. Reserved Example Second Level Domain Names
> >  >
> >  > The Internet Assigned Numbers Authority (IANA) also
> >  > currently has the
> >  > following second level domain names reserved which can be used as
> >  > examples.
> >  >
> >  > example.com
> >  > example.net
> >  > example.org
> >  >
> >  >
> >  > I.e. using "tld" as an example top level domain is wrong.
> >  >
> >  > Can you please have a discuss on this?
> >  >
> > Sure... it seemed more like a small nit to me, in any event, such a
> > discuss I think can be cleared with a RFC-Editor note.
> >
> > Randy:
> >
> > 8.
> > why do domain/contact/.. not have granular information 
> about privacy?
> >
> 



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 g9HLffcE002989 for <[e-mail]>; Thu, 17 Oct 2002 23:41:41 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9HLffdh002988 for ietf-provreg-outgoing; Thu, 17 Oct 2002 23:41:41 +0200 (MEST)
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 g9HLfdcE002983 for <[e-mail]>; Thu, 17 Oct 2002 23:41:40 +0200 (MEST)
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 g9HLf8pt041344; Thu, 17 Oct 2002 17:41:08 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: FW: IESG Review Comments -- 1-6, 8
In-Reply-To: Your message of "Thu, 17 Oct 2002 14:51:01 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 17 Oct 2002 17:41:08 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

1. Mailing list names and URLs

   During the development of a specification, draft versions of the
   document are made available for informal review and comment by
   placing them in the IETF's "Internet-Drafts" directory, which is
   replicated on a number of Internet hosts.  This makes an evolving 
   working document readily available to a wide audience, facilitating 
   the process of review and revision.

Having mailing list, the url for the IETF's "Internet-Drafts" directory [1],
for the working group, its archive, seems to meet the clear sense of sec2.2
of 2026. After the development is complete, they do seem likly to "age".

In any case, this is an RFC editor issue, and rather cosmetic..

2. Manditory to implement transport confidentiality or confidentiality and
   integrity.

Hmm. This was not a requirement when the prevailing model of access was
described in rfc518. How about rfc597? Nope. How about at the dawn of the
classical period with rfc625? Nope. Let's try rfc756 (keep this in mind,
I do), and Nope again. ... Skipping ahead to the dawn of the modern age
there is rfc1261 -- and another Nope. Not until we get to rfc2832 does
the possibility even begin to exist.

There is, or are, one or more use-case assumptions buried in this that
must be beaten out of the mush of "Security". I don't know what they are,
yet.

3.,4. Sigh. the authInfoType isn't of type token. Fix language (not
schema).

5. Now there is a catch worth paying for. Thanks Steve!

6. Scott's note (Bradner I assume) interests me.

What would interoperating implementations of EPP look like, if they either
attempted congestion control themselves (now there's an extension), or if
they could cause congestive collapse of some transited link. For it to be
of any but local interest, and not expose some fatally stupid bandwidth
under provisioning at the registry (I can think of one) and constitute a
(self-inflicted) DOS attack, the failed transit link would have to be a
core link.

Even counting-to-infinity type events didn't cause congestive collapse
when I was younger and an operator.

Feel free to think out loud folks, why does congestion control really
matter? This seems rather far from the VGRS "storm" events.

I've commented on 7 seperately.

I'll think about 8. This is on-par with element-level XML encryption.
(Ironically, the XMLP activity is "on the other line" about just this.)

Eric


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 g9HLKIcE002737 for <[e-mail]>; Thu, 17 Oct 2002 23:20:18 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9HLKI8N002736 for ietf-provreg-outgoing; Thu, 17 Oct 2002 23:20:18 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ns01.afilias.info (ns01.afilias.info [66.45.25.225]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g9HLKHcE002731 for <[e-mail]>; Thu, 17 Oct 2002 23:20:17 +0200 (MEST)
Received: from RAMLAPTOP (ismtp.afilias.com [216.217.55.254]) (authenticated) by ns01.afilias.info (8.11.2/8.11.2) with ESMTP id g9HLKFJ18395 for <[e-mail]>; Thu, 17 Oct 2002 17:20:15 -0400
Message-ID: <044101c27622$f86ec5d0$[e-mail]>
From: "Ram Mohan" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Conformance with ICANN Redemption Grace Periods
Date: Thu, 17 Oct 2002 17:19:43 -0400
Organization: Afilias
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.2800.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk

Scott,
As you may have noticed, in the Bucharest ICANN meeting, the Board resolved
to have registries adopt the proposed Redemption Grace Period
(http://www.icann.org/bucharest/redemption-topic.htm) policy.

Embedded in the document are the following, which may have an impact on EPP.
I forward to provreg to determine if any of these need to be factored into
our thinking.  (New capability, may or may not need a command; new domain
status if agreed to, will require some remapping)

-ram
>>Creation of New "RESTORE" Capability

The Technical Steering Group proposes the creation of a new "RESTORE"
capability that can be provided by a registry to registrars via one or more
of the following methods: a modification of the registry/registrar protocol,
an administration website, a fax service, or a telephone service. The
RESTORE capability will only affect names that are within the Delete Pending
Period. In other words, all RESTORE requests for names not in the Delete
Pending Period will be ignored.

>> Registry Transparency Requirements for Deleted Names

In order to ensure fairness to all registrants and registrars, the Technical
Steering Group proposes that deleted and restored names should be handled as
openly and transparently as feasible. Original registrants and those wishing
to be "next in line" to register a name that is being deleted should be able
to tell when a name was deleted and when it will be "returned to the pool"
of names available for registration.

Accordingly, under the proposal, a registry Whois check on a name that is
within the Delete Pending Period would return at least the following
information:

  Domain Name: example.com
  Sponsoring Registrar: exampleregistrar.com
  Domain Status: DELETE PENDING PERIOD
  Delete Requested: 31-may-2002

----- Original Message -----
From: "Hollenbeck, Scott" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, October 17, 2002 2:51 PM
Subject: FW: IESG Review Comments


> Forwarded with Patrik's permission for the benefit of the WG, these are
the
> comments received back from the IESG's review of the EPP documents.  I'll
be
> editing the documents shortly to incorporate the IESG's suggested text
> changes and others received from the WG over the last few weeks.
>
> I've added annotations to number the comments in this message.  We're
still
> trying to obtain clarifications for comments 6 and 8.
>
> -Scott-
>
> -----Original Message-----
> From: Patrik Fältström [mailto:[e-mail]]
> Sent: Tuesday, October 15, 2002 5:17 AM
> To: Scott Hollenbeck
> Cc: Jaap Akkerhuis; Edward Lewis
> Subject: Discuss on epp documents
>
>
> [Ooopss....I forgot to click on "send", this window has been sitting
> for a week in my laptop behind the window with the mailboxes....I AM
> SORRY]
>
>  From IESG:
>
> Steve:
>
> 1.
>   > <draft-ietf-provreg-epp-07.txt>  Do we put mailing list names and
> URLs in RFCs?
>
> 2.
>   I'd like a stronger Security Considerations section, though I think
>   it can be added by an RFC Editor note. In particular, I want it to
>   say that EPP "MUST NOT be used over a transport mechanism that does
>   not provide confidentiality", or "All transport mappings for EPP
>   MUST provide confidentiality and integrity". (I think that that's what
>   they intend, but it's not clear enough.)
>
> 3.
>   > <draft-ietf-provreg-epp-domain-05.txt>
>   What is an "authorization token"? It's not defined, but it's mandated
>   by the security considerations. (I suspect it's what is discussed in
>   2.6, but it doesn't use the same words.)
>
> 4.
>   > <draft-ietf-provreg-epp-contact-05.txt>
>   What is an "authorization token"? It's not defined, but it's mandated
>   by the security considerations. (I suspect it's what is discussed in
>   2.8, but it doesn't use the same words.)
>
> 5.
>   > <draft-ietf-provreg-epp-tcp-05.txt>
>   The Security Considerations section seems to require TLS client
>   authentication, which in turn requires client certificates. Is this
>   intended? If so, great! But in that case, what is the fate, if any,
>   of the EPP login/password command? Is it still needed? Is it still
>   legal? What does it mean? Must the identities agree? (The requirement
>   for server authentication is excellent, but some more text mentioning
>   the need to validate the certificate chain is probably a good idea.)
>
> Scott:
> note:
>
> 6.
> draft-ietf-provreg-epp-07.txt sec 2.1
>        I think it would be good to be a bit more strict about
>        the use of congestion control protocols specifically require
>        the use of an IETF standards track congestion control
>        protocol such as TCP or SCTP
>
>        i.e. change the following line:
>        - The transport mapping MUST manage congestion.
>
>        to:
>        - The transport mapping MUST only be to an IETF standards
>        track congestion control protocol such as TCP or SCTP.
>
> Bert: document: draft-ietf-provreg-epp-07.txt
>
> 7.
> page 12, example greeting has:
>
>      S: <svID>Example EPP server epp.example.tld</svID>
>
> in an example greeting. Did we not decide at some point
> that examples should be of the form: epp.example.org ??
>
> Patrik answers:
>
>  > We should follow RFC 2606 which states that:
>  >
>  > 3. Reserved Example Second Level Domain Names
>  >
>  > The Internet Assigned Numbers Authority (IANA) also
>  > currently has the
>  > following second level domain names reserved which can be used as
>  > examples.
>  >
>  > example.com
>  > example.net
>  > example.org
>  >
>  >
>  > I.e. using "tld" as an example top level domain is wrong.
>  >
>  > Can you please have a discuss on this?
>  >
> Sure... it seemed more like a small nit to me, in any event, such a
> discuss I think can be cleared with a RFC-Editor note.
>
> Randy:
>
> 8.
> why do domain/contact/.. not have granular information about privacy?
>



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 g9HKIjcE002101 for <[e-mail]>; Thu, 17 Oct 2002 22:18:45 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9HKIjC3002100 for ietf-provreg-outgoing; Thu, 17 Oct 2002 22:18:45 +0200 (MEST)
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 g9HKIicE002095 for <[e-mail]>; Thu, 17 Oct 2002 22:18:44 +0200 (MEST)
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 g9HKIht00650 for <[e-mail]>; Thu, 17 Oct 2002 20:18:43 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <SZM96XNM>; Thu, 17 Oct 2002 16:18:58 -0400
Message-ID: <[e-mail]>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: IESG Review Comments
Date: Thu, 17 Oct 2002 16:18:51 -0400
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 g9HKIicE002096
Sender: [e-mail]
Precedence: bulk

Scott,

I also have concerns about comment #6 being too restricted. But I will wait
for the clarifications. Thansk!

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[e-mail]]
Sent: Thursday, October 17, 2002 2:51 PM
To: '[e-mail]'
Subject: FW: IESG Review Comments


Forwarded with Patrik's permission for the benefit of the WG, these are the
comments received back from the IESG's review of the EPP documents.  I'll be
editing the documents shortly to incorporate the IESG's suggested text
changes and others received from the WG over the last few weeks.

I've added annotations to number the comments in this message.  We're still
trying to obtain clarifications for comments 6 and 8.

-Scott-

-----Original Message-----
From: Patrik Fältström [mailto:[e-mail]]
Sent: Tuesday, October 15, 2002 5:17 AM
To: Scott Hollenbeck
Cc: Jaap Akkerhuis; Edward Lewis
Subject: Discuss on epp documents


[Ooopss....I forgot to click on "send", this window has been sitting 
for a week in my laptop behind the window with the mailboxes....I AM 
SORRY]

 From IESG:

Steve:

1.
  > <draft-ietf-provreg-epp-07.txt>  Do we put mailing list names and 
URLs in RFCs?

2.
  I'd like a stronger Security Considerations section, though I think
  it can be added by an RFC Editor note. In particular, I want it to
  say that EPP "MUST NOT be used over a transport mechanism that does
  not provide confidentiality", or "All transport mappings for EPP
  MUST provide confidentiality and integrity". (I think that that's what
  they intend, but it's not clear enough.)

3.
  > <draft-ietf-provreg-epp-domain-05.txt>
  What is an "authorization token"? It's not defined, but it's mandated
  by the security considerations. (I suspect it's what is discussed in
  2.6, but it doesn't use the same words.)

4.
  > <draft-ietf-provreg-epp-contact-05.txt>
  What is an "authorization token"? It's not defined, but it's mandated
  by the security considerations. (I suspect it's what is discussed in
  2.8, but it doesn't use the same words.)

5.
  > <draft-ietf-provreg-epp-tcp-05.txt>
  The Security Considerations section seems to require TLS client
  authentication, which in turn requires client certificates. Is this
  intended? If so, great! But in that case, what is the fate, if any,
  of the EPP login/password command? Is it still needed? Is it still
  legal? What does it mean? Must the identities agree? (The requirement
  for server authentication is excellent, but some more text mentioning
  the need to validate the certificate chain is probably a good idea.)

Scott:
note:

6.
	draft-ietf-provreg-epp-07.txt sec 2.1
       I think it would be good to be a bit more strict about
       the use of congestion control protocols specifically require
       the use of an IETF standards track congestion control
       protocol such as TCP or SCTP

       i.e. change the following line:
       - The transport mapping MUST manage congestion.

       to:
       - The transport mapping MUST only be to an IETF standards
       track congestion control protocol such as TCP or SCTP.

Bert: document: draft-ietf-provreg-epp-07.txt

7.
page 12, example greeting has:

     S: <svID>Example EPP server epp.example.tld</svID>

in an example greeting. Did we not decide at some point
that examples should be of the form: epp.example.org ??

Patrik answers:

 > We should follow RFC 2606 which states that:
 >
 > 3. Reserved Example Second Level Domain Names
 >
 > The Internet Assigned Numbers Authority (IANA) also
 > currently has the
 > following second level domain names reserved which can be used as
 > examples.
 >
 > example.com
 > example.net
 > example.org
 >
 >
 > I.e. using "tld" as an example top level domain is wrong.
 >
 > Can you please have a discuss on this?
 >
Sure... it seemed more like a small nit to me, in any event, such a
discuss I think can be cleared with a RFC-Editor note.

Randy:

8.
why do domain/contact/.. not have granular information about privacy?



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 g9HKDVcE002034 for <[e-mail]>; Thu, 17 Oct 2002 22:13:31 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9HKDV3L002033 for ietf-provreg-outgoing; Thu, 17 Oct 2002 22:13:31 +0200 (MEST)
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 g9HKDTcE002028 for <[e-mail]>; Thu, 17 Oct 2002 22:13:30 +0200 (MEST)
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 g9HKCwpt041023; Thu, 17 Oct 2002 16:12:58 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: FW: IESG Review Comments -- item 7
In-Reply-To: Your message of "Thu, 17 Oct 2002 14:51:01 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 17 Oct 2002 16:12:58 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Scott,

The choice of labelN.labelN-1..label1.label0, for values of N < big, seems
to be entirely editorial in nature. Second, while Donald may have had the
best of intentions in bagging some SLDs (example.{com,net,org}, the strings
MUST, MANDITORY, MUSTY and MANDIBLE occure nowhere in 2606, therefore to
conclude that some labelN.labelN-1..label1.label0 sequence is "wrong" seems
without foundation.

Personally I don't care what you do, and I do wish IESG review would focus
on the protocol, not the namespace ephemera. If someone from .be could get
"cenestpasunepipe.be" (The Treachery of Images) that would be splendid, and 
get the ICANN marketing cruft out of the way.

utterly-bogus.nld and pseudo-random.nld work for me.

The point is a clear spec, nothing else.

Eric


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 g9HIp7cE000911 for <[e-mail]>; Thu, 17 Oct 2002 20:51:07 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9HIp7is000910 for ietf-provreg-outgoing; Thu, 17 Oct 2002 20:51:07 +0200 (MEST)
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 g9HIp6cE000905 for <[e-mail]>; Thu, 17 Oct 2002 20:51:06 +0200 (MEST)
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 OAA29424 for <[e-mail]>; Thu, 17 Oct 2002 14:51:05 -0400 (EDT)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <TF9XV341>; Thu, 17 Oct 2002 14:51:05 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: FW: IESG Review Comments
Date: Thu, 17 Oct 2002 14:51:01 -0400
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 g9HIp7cE000906
Sender: [e-mail]
Precedence: bulk

Forwarded with Patrik's permission for the benefit of the WG, these are the
comments received back from the IESG's review of the EPP documents.  I'll be
editing the documents shortly to incorporate the IESG's suggested text
changes and others received from the WG over the last few weeks.

I've added annotations to number the comments in this message.  We're still
trying to obtain clarifications for comments 6 and 8.

-Scott-

-----Original Message-----
From: Patrik Fältström [mailto:[e-mail]]
Sent: Tuesday, October 15, 2002 5:17 AM
To: Scott Hollenbeck
Cc: Jaap Akkerhuis; Edward Lewis
Subject: Discuss on epp documents


[Ooopss....I forgot to click on "send", this window has been sitting 
for a week in my laptop behind the window with the mailboxes....I AM 
SORRY]

 From IESG:

Steve:

1.
  > <draft-ietf-provreg-epp-07.txt>  Do we put mailing list names and 
URLs in RFCs?

2.
  I'd like a stronger Security Considerations section, though I think
  it can be added by an RFC Editor note. In particular, I want it to
  say that EPP "MUST NOT be used over a transport mechanism that does
  not provide confidentiality", or "All transport mappings for EPP
  MUST provide confidentiality and integrity". (I think that that's what
  they intend, but it's not clear enough.)

3.
  > <draft-ietf-provreg-epp-domain-05.txt>
  What is an "authorization token"? It's not defined, but it's mandated
  by the security considerations. (I suspect it's what is discussed in
  2.6, but it doesn't use the same words.)

4.
  > <draft-ietf-provreg-epp-contact-05.txt>
  What is an "authorization token"? It's not defined, but it's mandated
  by the security considerations. (I suspect it's what is discussed in
  2.8, but it doesn't use the same words.)

5.
  > <draft-ietf-provreg-epp-tcp-05.txt>
  The Security Considerations section seems to require TLS client
  authentication, which in turn requires client certificates. Is this
  intended? If so, great! But in that case, what is the fate, if any,
  of the EPP login/password command? Is it still needed? Is it still
  legal? What does it mean? Must the identities agree? (The requirement
  for server authentication is excellent, but some more text mentioning
  the need to validate the certificate chain is probably a good idea.)

Scott:
note:

6.
	draft-ietf-provreg-epp-07.txt sec 2.1
       I think it would be good to be a bit more strict about
       the use of congestion control protocols specifically require
       the use of an IETF standards track congestion control
       protocol such as TCP or SCTP

       i.e. change the following line:
       - The transport mapping MUST manage congestion.

       to:
       - The transport mapping MUST only be to an IETF standards
       track congestion control protocol such as TCP or SCTP.

Bert: document: draft-ietf-provreg-epp-07.txt

7.
page 12, example greeting has:

     S: <svID>Example EPP server epp.example.tld</svID>

in an example greeting. Did we not decide at some point
that examples should be of the form: epp.example.org ??

Patrik answers:

 > We should follow RFC 2606 which states that:
 >
 > 3. Reserved Example Second Level Domain Names
 >
 > The Internet Assigned Numbers Authority (IANA) also
 > currently has the
 > following second level domain names reserved which can be used as
 > examples.
 >
 > example.com
 > example.net
 > example.org
 >
 >
 > I.e. using "tld" as an example top level domain is wrong.
 >
 > Can you please have a discuss on this?
 >
Sure... it seemed more like a small nit to me, in any event, such a
discuss I think can be cleared with a RFC-Editor note.

Randy:

8.
why do domain/contact/.. not have granular information about privacy?



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 g9HFZEcE028947 for <[e-mail]>; Thu, 17 Oct 2002 17:35:14 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9HFZEiP028946 for ietf-provreg-outgoing; Thu, 17 Oct 2002 17:35:14 +0200 (MEST)
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 g9HFZBcE028941 for <[e-mail]>; Thu, 17 Oct 2002 17:35:11 +0200 (MEST)
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 g9HFYdpt040036; Thu, 17 Oct 2002 11:34:39 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
cc: Edward Lewis <[e-mail]>, [e-mail], Jaap Akkerhuis <[e-mail]>, [e-mail]
Subject: Re: our two past-due deadlines 
In-Reply-To: Your message of "Wed, 16 Oct 2002 11:09:39 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 17 Oct 2002 11:34:39 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> The second - Eric has a document not in the I-D repository and "NOT 
> offered in accordance with Section 10 of RFC2026" on the EPP/SMTP 
> topic.

OK. I found the noDerivativeWorksNow bit (undocumented) in Marshall's
xml2rfc.tcl and the IPR boiler-plate now reads:

: Status of this Memo
: 
:    This document is an Internet-Draft and is in full conformance with
:    all provisions of Section 10 of RFC2026 except that the right to
:    produce derivative works is not granted.  (If this document becomes
:    part of an IETF working group activity, then it will be brought into
:    full compliance with Section 10 of RFC2026.)

I added an i18n considerations section (why one can use things the
author of BCP47 managed to miss, rather than just use them without
comment) and I suppose there are other bits I could add too.

The -55 -00 cut-off date is 10/28. I'll submit to the I-D Admin on 10/21.

This allows a week to resubmit as a WG doc, prior to -55, or anytime after
04/11, or never.

Eric


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 g9HDKdcE027666 for <[e-mail]>; Thu, 17 Oct 2002 15:20:39 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9HDKd60027665 for ietf-provreg-outgoing; Thu, 17 Oct 2002 15:20:39 +0200 (MEST)
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 g9HDKbcE027660 for <[e-mail]>; Thu, 17 Oct 2002 15:20:38 +0200 (MEST)
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 g9HDKRRF004913; Thu, 17 Oct 2002 09:20:27 -0400 (EDT)
Received: from [192.149.252.227] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA28386; Thu, 17 Oct 2002 09:20:25 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b03b9d4685e3bcd@[192.149.252.227]>
In-Reply-To: <008b01c27526$e57d8210$[e-mail]>
References: <a05111b02b9d31eb56226@[192.149.252.227]> <008b01c27526$e57d8210$[e-mail]>
Date: Thu, 17 Oct 2002 09:20:14 -0400
To: "Ram Mohan" <[e-mail]>, <[e-mail]>, "Edward Lewis" <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: our two past-due deadlines
Cc: <[e-mail]>, "Jaap Akkerhuis" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 11:15 -0400 10/16/02, Ram Mohan wrote:
>ed,
>i'm interested in the EPP Extensions Guidelines doc, and look forward to
>reviewing it prior to stating my opinion re: adoption.

Just in case I need to mention this, the draft exists as a non-WG 
item in the I-D repository:

   http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-ext-00.txt

With the -00 draft deadline coming up for the Atlanta meetings (at 
which we have no time slot) coming soon, if there are no opinions 
stated by early Monday (-0400) the draft will be renamed and enter 
the group.

Recall - just because the draft goes in doesn't mean it will pass. 
If there are serious problems with the draft, it will be kicked back 
out.  A few drafts have been kicked out over the course of the 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 g9HCAscE027105 for <[e-mail]>; Thu, 17 Oct 2002 14:10:54 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9HCAs2w027104 for ietf-provreg-outgoing; Thu, 17 Oct 2002 14:10:54 +0200 (MEST)
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 g9HCAqcE027099 for <[e-mail]>; Thu, 17 Oct 2002 14:10:52 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA06782; Thu, 17 Oct 2002 08:10:45 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <4RC7B2YB>; Thu, 17 Oct 2002 08:10:43 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: <authInfo> in Transfer Query for Domain and Contact
Date: Thu, 17 Oct 2002 08:10:41 -0400
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

> Maybe I should suggest some text regarding what I would like 
> to see changes.
> In the schema, the <authInfo> element should be OPTIONAL. However, the
> following text may be included to clarify its use:
>  
> "The use of <authInfo> is mandatory for all transfer related 
> operations
> except for query. The server MUST reject any transfer related 
> operation with
> invalid <authInfo>. The server MAY accept a transfer query 
> from the last
> losing registrar if <authInfo> is not present."
> 
> What do you think?

I think it should be consistent with other query operations that use
authInfo.  If a server operator wants to let a non-sponsoring client see the
results of a transfer using the transfer query, they should be able to
create the policy and implementation to do so -- just as they can with the
<info> command.

I'm working on changes now to address some comments received from the IESG,
so I'll work this in.

-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 g9GJLFcE020501 for <[e-mail]>; Wed, 16 Oct 2002 21:21:15 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9GJLF4C020500 for ietf-provreg-outgoing; Wed, 16 Oct 2002 21:21:15 +0200 (MEST)
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 g9GJLEcE020493 for <[e-mail]>; Wed, 16 Oct 2002 21:21:14 +0200 (MEST)
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 g9GJLDt26087 for <[e-mail]>; Wed, 16 Oct 2002 19:21:13 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <SZM963HS>; Wed, 16 Oct 2002 15:21:26 -0400
Message-ID: <[e-mail]>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: <authInfo> in Transfer Query for Domain and Contact
Date: Wed, 16 Oct 2002 15:21:20 -0400
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

Scott,

Sorry for getting back to you late. Yes, the <poll> mechanism is one way to
get the losing registrar notified of the result. But should that be the only
way? I guess this is really up to the registry to decide. As pointed out by
Ross Radar in another related issue [1], the protocol should provide the
mechanism for policy enforcement, but not the enforcement itself. Here, the
protocol excludes the possibility for losing registrars to inspect completed
transfer results. If a registry wants to provide such service, it has to
allow transfer query with invalid <authInfo> but from the last losing
registry to go through. To me, this is a more serious violation to the
protocol semantics than just allowing <authInfo> to be optional.

Maybe I should suggest some text regarding what I would like to see changes.
In the schema, the <authInfo> element should be OPTIONAL. However, the
following text may be included to clarify its use:
 
"The use of <authInfo> is mandatory for all transfer related operations
except for query. The server MUST reject any transfer related operation with
invalid <authInfo>. The server MAY accept a transfer query from the last
losing registrar if <authInfo> is not present."

What do you think?

--Hong

[1] http://www.cafax.se/ietf-provreg/maillist/2002-01/msg00058.html

-----Original Message-----
From: Hollenbeck, Scott [mailto:[e-mail]]
Sent: Friday, October 11, 2002 8:14 PM
To: 'Liu, Hong'; '[e-mail]'
Subject: RE: <authInfo> in Transfer Query for Domain and Contact


> I have a question about <authInfo> being mandatory for the <transfer>
> command. I understand that it was added into EPP-06 [1] based on the
> "spying" issue raised by Dan Manley [2]. I also feel that 
> this parameter
> should be mandatory for the other four operations related to 
> <transfer>,
> i.e., request, cancel, reject and approve.
> 
> However, there is a special case where it is helpful NOT to 
> make <authInfo>
> manadatory. The scenario is the following: domain abc.tld is 
> transferred
> from Registrar A to Registrar B. During the transfer pending 
> period, both A
> and B share the knowledge of the same <authInfo> of abc.tld. 
> However, after
> the transfer is completed successfully, Registrar B may change the
> <authInfo> (for security reasons or at the request of the registrar of
> abc.tld). Once that happens, Registrar B will not be able to see the
> transfer result of abc.tld anymore...However, GRRP 
> Requirements (RFC 3375)
> requires that (page 10):
> 
> [8] The protocol MUST provide services that allow both the original
> sponsoring registrar and the potential new registrar to 
> monitor the status
> of both pending and completed transfer requests. 
> 
> The same problem exists for <authInfo> being mandatory for 
> contact transfer.
> 
> Do you think this is a problem in the EPP domain and contact 
> specs that
> needs to be fixed? Thanks!

Actually, no, I don't think it's a problem.  While the losing client can't
track the status via the <transfer> query after the authInfo gets changed,
they are informed of the completion of the transfer via queued and polled
messages -- so we have the requirement met.

-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 g9GFFscE017990 for <[e-mail]>; Wed, 16 Oct 2002 17:15:54 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9GFFsMj017989 for ietf-provreg-outgoing; Wed, 16 Oct 2002 17:15:54 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ns01.afilias.info (ns01.afilias.info [66.45.25.225]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g9GFFqcE017984 for <[e-mail]>; Wed, 16 Oct 2002 17:15:53 +0200 (MEST)
Received: from RAMLAPTOP (ismtp.afilias.com [216.217.55.254]) (authenticated) by ns01.afilias.info (8.11.2/8.11.2) with ESMTP id g9GFFol32580; Wed, 16 Oct 2002 11:15:50 -0400
Message-ID: <008b01c27526$e57d8210$[e-mail]>
From: "Ram Mohan" <[e-mail]>
To: <[e-mail]>, "Edward Lewis" <[e-mail]>
Cc: <[e-mail]>, "Jaap Akkerhuis" <[e-mail]>
References: <a05111b02b9d31eb56226@[192.149.252.227]>
Subject: Re: our two past-due deadlines
Date: Wed, 16 Oct 2002 11:15:37 -0400
Organization: Afilias
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.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk

ed,
i'm interested in the EPP Extensions Guidelines doc, and look forward to
reviewing it prior to stating my opinion re: adoption.

-ram
----- Original Message -----
From: "Edward Lewis" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; "Jaap Akkerhuis" <[e-mail]>
Sent: Wednesday, October 16, 2002 10:08 AM
Subject: our two past-due deadlines


> According to the automated powers that be we are overdue on two items:
>
> # PROVREG:Sep 2002:First draft of EPP Extensions Guidelines draft
> # PROVREG:Sep 2002:First draft of EPP over SMTP
>
> The first - Scott has a personal submission in the hopper and the
> chairs already asked if the group wanted to adopt or not.  No one
> replied.  Based on an earlier call for the doc - at our last in
> person meeting, The chairs are going to ask Scott and the I-D people
> to add the doc to the WG (name change and put it on the charter page).
>
> The second - Eric has a document not in the I-D repository and "NOT
> offered in accordance with Section 10 of RFC2026" on the EPP/SMTP
> topic.  As such, the document isn't eligible to be "just transferred"
> into the group even though it is publicly available and a reference
> to it exists in the mailing list archives.  The (one) eligibility
> hurdle is the prohibition of the IETF to make changes to the document.
>
> So the question remains open, but with at least more input on the
> topic available, whether an SMTP draft will be produced.
>
> To the previous volunteers: unless you either express interest again
> or produce a document or documents as personal products, the chairs
> will consider you as "unvolunteering."
>
> The chairs are reluctant to just choose an editor(s) for the draft
> *in the absence of a demand for us to do so*.  This is because it is
> up to the WG members to determine if this draft is desired and to
> support its development.  The chairs shouldn't be determining the
> course of the group, but making sure the group adheres to the charter
> and makes headway into solving our problems.  (So much for the
> soapbox.)
>
> So - if the volunteers are still interested, say so or better yet
> submit works that the WG can edit.  If the group wants to an editor
> to be named, let the chairs know...
>
> But please let the chairs get our milestones moved!  You don't know
> the horrors of the IETF Secretariat torture chamber.
> Drip-spam-drip-spam-... ;)
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 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 g9GFA7cE017915 for <[e-mail]>; Wed, 16 Oct 2002 17:10:07 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9GFA6KA017914 for ietf-provreg-outgoing; Wed, 16 Oct 2002 17:10:06 +0200 (MEST)
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 g9GFA1cE017909 for <[e-mail]>; Wed, 16 Oct 2002 17:10:01 +0200 (MEST)
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 g9GF9dpt033491; Wed, 16 Oct 2002 11:09:40 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: [e-mail], Jaap Akkerhuis <[e-mail]>, [e-mail]
Subject: Re: our two past-due deadlines 
In-Reply-To: Your message of "Wed, 16 Oct 2002 10:08:54 EDT." <a05111b02b9d31eb56226@[192.149.252.227]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 16 Oct 2002 11:09:39 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> The first - Scott has a personal submission in the hopper and the 
> chairs already asked if the group wanted to adopt or not.  No one 
> replied.

Yes.

> The second - Eric has a document not in the I-D repository and "NOT 
> offered in accordance with Section 10 of RFC2026" on the EPP/SMTP 
> topic.

I'm waiting for substantive comments from the 822/edi/this lists. I'm
going to give it another few days and then submit a "full conformance"
draft prior to the pending -00 cut-off -- I've thought of a few things
since.

So far, I've heard from two contributors to this list. Thanks guys!

Eric


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 g9GE8rcE017178 for <[e-mail]>; Wed, 16 Oct 2002 16:08:53 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9GE8rgI017177 for ietf-provreg-outgoing; Wed, 16 Oct 2002 16:08:53 +0200 (MEST)
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 g9GE8pcE017172 for <[e-mail]>; Wed, 16 Oct 2002 16:08:52 +0200 (MEST)
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 g9GE8oRF075777; Wed, 16 Oct 2002 10:08:51 -0400 (EDT)
Received: from [192.149.252.227] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA15201; Wed, 16 Oct 2002 10:08:48 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b02b9d31eb56226@[192.149.252.227]>
Date: Wed, 16 Oct 2002 10:08:54 -0400
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: our two past-due deadlines
Cc: [e-mail], Jaap Akkerhuis <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

According to the automated powers that be we are overdue on two items:

# PROVREG:Sep 2002:First draft of EPP Extensions Guidelines draft
# PROVREG:Sep 2002:First draft of EPP over SMTP

The first - Scott has a personal submission in the hopper and the 
chairs already asked if the group wanted to adopt or not.  No one 
replied.  Based on an earlier call for the doc - at our last in 
person meeting, The chairs are going to ask Scott and the I-D people 
to add the doc to the WG (name change and put it on the charter page).

The second - Eric has a document not in the I-D repository and "NOT 
offered in accordance with Section 10 of RFC2026" on the EPP/SMTP 
topic.  As such, the document isn't eligible to be "just transferred" 
into the group even though it is publicly available and a reference 
to it exists in the mailing list archives.  The (one) eligibility 
hurdle is the prohibition of the IETF to make changes to the document.

So the question remains open, but with at least more input on the 
topic available, whether an SMTP draft will be produced.

To the previous volunteers: unless you either express interest again 
or produce a document or documents as personal products, the chairs 
will consider you as "unvolunteering."

The chairs are reluctant to just choose an editor(s) for the draft 
*in the absence of a demand for us to do so*.  This is because it is 
up to the WG members to determine if this draft is desired and to 
support its development.  The chairs shouldn't be determining the 
course of the group, but making sure the group adheres to the charter 
and makes headway into solving our problems.  (So much for the 
soapbox.)

So - if the volunteers are still interested, say so or better yet 
submit works that the WG can edit.  If the group wants to an editor 
to be named, let the chairs know...

But please let the chairs get our milestones moved!  You don't know 
the horrors of the IETF Secretariat torture chamber. 
Drip-spam-drip-spam-... ;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 g9BNAIcE003564 for <[e-mail]>; Sat, 12 Oct 2002 01:10:18 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9BNAIY7003563 for ietf-provreg-outgoing; Sat, 12 Oct 2002 01:10:18 +0200 (MEST)
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 g9BNAGcE003558 for <[e-mail]>; Sat, 12 Oct 2002 01:10:17 +0200 (MEST)
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 g9BNAF105457 for <[e-mail]>; Fri, 11 Oct 2002 23:10:15 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <SZM95S1R>; Fri, 11 Oct 2002 19:10:21 -0400
Message-ID: <[e-mail]>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: <authInfo> in Transfer Query for Domain and Contact
Date: Fri, 11 Oct 2002 19:10:19 -0400
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

For some reason, I did not see this email appear in the archive. So here is
the resend.

-----Original Message-----
From: Liu, Hong 
Sent: Friday, October 11, 2002 3:33 PM
To: '[e-mail]'
Subject: <authInfo> in Transfer Query for Domain and Contact


Scott,

I have a question about <authInfo> being mandatory for the <transfer>
command. I understand that it was added into EPP-06 [1] based on the
"spying" issue raised by Dan Manley [2]. I also feel that this parameter
should be mandatory for the other four operations related to <transfer>,
i.e., request, cancel, reject and approve.

However, there is a special case where it is helpful NOT to make <authInfo>
manadatory. The scenario is the following: domain abc.tld is transferred
from Registrar A to Registrar B. During the transfer pending period, both A
and B share the knowledge of the same <authInfo> of abc.tld. However, after
the transfer is completed successfully, Registrar B may change the
<authInfo> (for security reasons or at the request of the registrar of
abc.tld). Once that happens, Registrar B will not be able to see the
transfer result of abc.tld anymore...However, GRRP Requirements (RFC 3375)
requires that (page 10):

[8] The protocol MUST provide services that allow both the original
sponsoring registrar and the potential new registrar to monitor the status
of both pending and completed transfer requests. 

The same problem exists for <authInfo> being mandatory for contact transfer.

Do you think this is a problem in the EPP domain and contact specs that
needs to be fixed? Thanks!

--Hong

[1] http://www.cafax.se/ietf-provreg/maillist/2002-01/msg00080.html
[2] http://www.cafax.se/ietf-provreg/maillist/2001-11/msg00043.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 g9BL4dcE002503 for <[e-mail]>; Fri, 11 Oct 2002 23:04:39 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9BL4dJf002502 for ietf-provreg-outgoing; Fri, 11 Oct 2002 23:04:39 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g9BL4bcE002497 for <[e-mail]>; Fri, 11 Oct 2002 23:04:38 +0200 (MEST)
Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id OAA14166; Fri, 11 Oct 2002 14:04:33 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta)
Date: Fri, 11 Oct 2002 14:04:19 -0700
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Dave Crocker <[e-mail]>
Subject: Re: how to exchange EPP content using SMTP transport 
Cc: Dave Crocker <[e-mail]>, Eric Brunner-Williams in Portland Maine <[e-mail]>, [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <Your message of "Fri, 11 Oct 2002 12:14:48 PDT." <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

At 04:35 PM 10/11/2002 -0400, Eric Brunner-Williams in Portland Maine wrote:

>Once I caught MIME, everything looked like a frenchman wearing thick makeup.

never seen one.  don't know what they look like.


>I decided that it was more useful to write a Foo-over-OneTP memo than a
>MetaFoo-over-ManyTP memo.

well, my primary point is that for most of the material, this is not "over 
SMTP".  Rather, it is "over MIME".  MIME is the bottom layer to worry about.

That said, there really ARE some SMTP issues that at least need to be 
cited, now that I think of it.

Addressing and reliability (as in, actual transmissions issues) come to 
mind.  Given that SMTP is not reliable on an end-to-end basis, what do we 
want to do if/when a message gets dropped?


> > The table is interesting, but I am not clear what purpose it servces in the
> > current specification.  Please clarify.
>
>Personel taste. A weakness for taxonomy.

But I still don't know what purpose it serves for this document.  The other 
two protocols are not under consideration and are not mentioned elsewhere 
in the doc, are they?


> > probably should also cite rfc2822, resnick, "Internet Message Format" and
> > rfc2821, klensin, "Simple Mail Transfer Protocol".
>
>Thank. I like the oldies. I've a nit with the moderns I haven't got my head
>around.

pro forma requirement.  part of helping the adoption curve.

d/


----------
Dave Crocker <mailto:[e-mail]>
TribalWise, Inc. <http://www.tribalwise.com>
tel [phone]; fax [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 g9BKYjcE002158 for <[e-mail]>; Fri, 11 Oct 2002 22:34:45 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9BKYja0002157 for ietf-provreg-outgoing; Fri, 11 Oct 2002 22:34:45 +0200 (MEST)
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 g9BKYhcE002152 for <[e-mail]>; Fri, 11 Oct 2002 22:34:44 +0200 (MEST)
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 g9BKZWpu003512; Fri, 11 Oct 2002 16:35:33 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Dave Crocker <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, [e-mail], [e-mail]
Subject: Re: how to exchange EPP content using SMTP transport 
In-Reply-To: Your message of "Fri, 11 Oct 2002 12:14:48 PDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 11 Oct 2002 16:35:32 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Dave,

(ediint and 822 bcc'd to target discussion on the host list, provreg.)

This started as "Applicability Statement for EPP over Transport other than
TCP", with the comment:

   The original motivation for this memo is a casual figure contained in
   a presentation made by James Seng to the PROVREG WG face-to-face
   meeting at IETF-51.  This figure purported to show a loop-free store-
   and-forward transport topology, which unfortunately contained loops.

I then slogged grimly through the rainy grey ruins of connection and HOL
blocking, session semantics, authentication mechanism scaling, state, and
the semantics of EPP session/read/write commands and responses to find no
real case for transport-over-TCP, no there there, at least outside of the
ICANN sandbox, and even there, the real use case seems to be minimum-delay
exact match write races -- a QoS guarantee not actually specified in the
TCP mapping.

I next gamboled blithly over the sunny meadows of {SMTP,NEWS}/{TCP,UUCP},
and HTTP/TCP and concluded that:

>           ... the requirements for epp/smtp are the same as for any MIME
> object needing the same security services.

Once I caught MIME, everything looked like a frenchman wearing thick makeup.

I decided that it was more useful to write a Foo-over-OneTP memo than a
MetaFoo-over-ManyTP memo.

> Having all those examples is really excellent.

Thanks. Laborious. Error-certain.

> The table is interesting, but I am not clear what purpose it servces in the
> current specification.  Please clarify.

Personel taste. A weakness for taxonomy.

> what does "receiver message structures" mean?  are these the replies?

Yup.

> "Standard for the Format of ARPA Internet Text Messages"
> 
> probably should also cite rfc2822, resnick, "Internet Message Format" and
> rfc2821, klensin, "Simple Mail Transfer Protocol".

Thank. I like the oldies. I've a nit with the moderns I haven't got my head
around.

Eric






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 g9BJjEcE001747 for <[e-mail]>; Fri, 11 Oct 2002 21:45:14 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9BJjEju001746 for ietf-provreg-outgoing; Fri, 11 Oct 2002 21:45:14 +0200 (MEST)
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 g9BJjDcE001741 for <[e-mail]>; Fri, 11 Oct 2002 21:45:13 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g9BJj5bX009196 for <[e-mail]>; Fri, 11 Oct 2002 21:45:05 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id g9BJj4vp009195 for [e-mail]; Fri, 11 Oct 2002 21:45:04 +0200 (CEST)
Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g9BJF4cE001540 for <[e-mail]>; Fri, 11 Oct 2002 21:15:04 +0200 (MEST)
Received: from bbprime.brandenburg.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id MAA10150; Fri, 11 Oct 2002 12:14:58 -0700
Date: Fri, 11 Oct 2002 12:14:48 -0700
From: Dave Crocker <[e-mail]>
X-Mailer: The Bat! (v1.61) UNREG / CD5BF9353B3B7091
Reply-To: Dave Crocker <[e-mail]>
Organization: TribalWise
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail], Eric Brunner-Williams in Portland Maine <[e-mail]>
CC: [e-mail]
Subject: Re: how to exchange EPP content using SMTP transport
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Eric,

(ediint and 822 bcc'd to target discussion on the host list, provreg.)

MANY thanks for doing this.

Comments inline.

Friday, October 11, 2002, 10:13:47 AM, you wrote:
EBWiPM>    This memo defines mechanisms to secure (sign or encrypt or sign and
EBWiPM>    encrypt) one or more EPP messages in any SMTP message.  This memo
EBWiPM>    does not define mechanism to secure (sign or encrypt or sign and
EBWiPM>    encrypt) individual XML elements within an EPP message.

Are there any requirements for epp/smtp security that are distinctive?  My
guess is that the requirements for epp/smtp are the same as for any MIME
object needing the same security services.

That is, if we say that these objects may need privacy, authentication and
signed receipt, then it should the security-related work of this specification
should be done... as long as we can cite an external reference that defines
the common way(s) to achieve those services.

>From work in IMPP I've come to believe that we need a MIMEsec specification
that is common to all MIME objects, for these common services.  (Well, ok,
signed receipt is not yet common.)

Such a document should, essentially, take existing text from various special
efforts, like ediint and impp, as you have noted.  Would this be reasonable?

If yes, then the current specification should be able to cite a MIMEsec
document, for security basic security issues.  Given that it is a transaction
service, perhaps it needs to mention something about man-in-the-middle and DOS
attacks?

Otherwise, the normative (specification) portion could then focus on
definition of the MIME type and, perhaps, profile the bulk carriage details.

Having all those examples is really excellent.


EBWiPM> 2. Background Summary
EBWiPM> 
EBWiPM>    Some language about these three registry protocols, and the
EBWiPM>    applicability of SMTP as a transport protocol.  TBD.
EBWiPM> 
EBWiPM>    This table compares the salient characteristics of EPP, RRP and SRS.

The table is interesting, but I am not clear what purpose it servces in the
current specification.  Please clarify.



EBWiPM> 
EBWiPM> 13. Receiver Message Structures
EBWiPM> 
EBWiPM>    This section is intentionally blank, pending implementation.

what does "receiver message structures" mean?  are these the replies?



EBWiPM>    [3]   Crocker, D., "Simple Mail Transfer Protocol", RFC 822, STD 11,
EBWiPM>          August 1982.

"Standard for the Format of ARPA Internet Text Messages"

probably should also cite rfc2822, resnick, "Internet Message Format" and
rfc2821, klensin, "Simple Mail Transfer Protocol".

d/



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 g9BHCwcE000477 for <[e-mail]>; Fri, 11 Oct 2002 19:12:58 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9BHCw0G000476 for ietf-provreg-outgoing; Fri, 11 Oct 2002 19:12:58 +0200 (MEST)
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 g9BHCvcE000471 for <[e-mail]>; Fri, 11 Oct 2002 19:12:57 +0200 (MEST)
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 g9BHDlpt002645; Fri, 11 Oct 2002 13:13:47 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
cc: [e-mail]
Subject: how to exchange EPP content using SMTP transport
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 11 Oct 2002 13:13:47 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Appologies for the cross-posting.

As Jon Crowcroft wrote to the ed2end list Monday, this is somewhat 1/2
baked, but comments are welcome.

Available via ftp from [216.220.241.233]
	user=anonymous
	pswd=guest (or whatever)
	file=pub/draft-brunner-epp-smtp-00.txt,html

Comments to me please, I like writing acknowledgements.

Eric


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 g9ABLcJC014054 for <[e-mail]>; Thu, 10 Oct 2002 13:21:38 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9ABLbPJ014053 for ietf-provreg-outgoing; Thu, 10 Oct 2002 13:21:37 +0200 (MEST)
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 g9ABLaJC014048 for <[e-mail]>; Thu, 10 Oct 2002 13:21:36 +0200 (MEST)
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 HAA16724; Thu, 10 Oct 2002 07:21:29 -0400 (EDT)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <TF9XM568>; Thu, 10 Oct 2002 07:21:29 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Definition of "External" Host
Date: Thu, 10 Oct 2002 07:21:12 -0400
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 will leave it to you as how to incorporate the above 
> paragraph in section 1.1. 
> 
> What do you think?

I'm OK with your clarifications.  Thanks for providing the text.

-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 g9A5rQJC011946 for <[e-mail]>; Thu, 10 Oct 2002 07:53:26 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9A5rQeC011945 for ietf-provreg-outgoing; Thu, 10 Oct 2002 07:53:26 +0200 (MEST)
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 g9A5rOJC011940 for <[e-mail]>; Thu, 10 Oct 2002 07:53:25 +0200 (MEST)
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 g9A5rN108843 for <[e-mail]>; Thu, 10 Oct 2002 05:53:24 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <SZM951NZ>; Thu, 10 Oct 2002 01:53:28 -0400
Message-ID: <[e-mail]>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Definition of "External" Host
Date: Thu, 10 Oct 2002 01:53:27 -0400
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

Scott,

The text I would like to propose to change is in
draft-ietf-provreg-epp-domain-05.txt, section 1.1, second paragraph, last
sentence: 
change 
"Such hosts are described as "external" hosts in this specification since
the management authority for these hosts is external to the repository in
which the host is being used for delegation purposes."
to
"Such hosts are described as "external" hosts in this specification since
the name of such host does not belong to the name space of the repository in
which the host is being used for delegation purposes."

I would also like to add some text in section 1.1 for the case where a host
object is used as a nameserver for a domain, but it is neither an external
host nor a subordiate host of the domain. That is, a host object that is
internal to the repository but external to the domain where it is being used
for delegation purpose. For example, ns1.abc.tld is a subordinate host of
domain abc.tld, and it is being used as a nameserver for domain def.tld. EPP
seems to allow this scenario, but it is not explicitly covered in section
1.1. The suggested text can be the following:

"Whether a host is external or internal is with respect to the repository in
which the host is being used for delegation purposes. Whether an internal
host is subordinate or non-subordinate is with respect to a domain within
the respository. For example, host ns1.abc.tld is a subordinate host of
domain abc.tld, but is a non-subordinate host of domain def.tld. ns1.abc.tld
can be used as a nameserver for def.tld. In this case, ns1.abc.tld MUST be
treated as an internal host, subject to the rules governing the operations
on subordinate hosts within the same repository."

I will leave it to you as how to incorporate the above paragraph in section
1.1. 

What do you think?

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[e-mail]]
Sent: Wednesday, October 09, 2002 9:55 PM
To: 'Liu, Hong'; '[e-mail]'
Subject: RE: Definition of "External" Host

[snip...]

So, I think we're talking about the same thing.  Could you get to the point
of whatever it is you have an issue with?  If you don't like the way these
special-case hosts are described in the current document, please suggest
alternative text to describe the concept.

By the way, none of this was introduced in EPP-07.  It's been this way for
several revisions, including the one that passed WG last call.

-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 g9A1tBJC010731 for <[e-mail]>; Thu, 10 Oct 2002 03:55:11 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9A1tBh1010730 for ietf-provreg-outgoing; Thu, 10 Oct 2002 03:55:11 +0200 (MEST)
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 g9A1t9JC010725 for <[e-mail]>; Thu, 10 Oct 2002 03:55:10 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id VAA06365; Wed, 9 Oct 2002 21:54:59 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <4RC656QD>; Wed, 9 Oct 2002 21:54:59 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Definition of "External" Host
Date: Wed, 9 Oct 2002 21:54:42 -0400 
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 still do not understand what you do not understand.  In the specialized
case of a host being a name server, the host is either registered in a
repository that is authoritative for the IP address association with that
host or it isn't.  If it isn't, we came up with the "external host" term to
note the distinction that requires special DNS processing for name server
hosts.

host.2ld.tld is internal to the 2ld.tld repository.  It is external to any
other repository, including those that might exist under 2ld.tld, such as
3ld.2ld.tld, for reasons including some of those you described.  I'm not
sure where my earlier responses suggest otherwise, but they way you
described collapsing DBs and zones suggests that you've interpreted
something I said in a manner that I didn't intend.

This has nothing to do with registration policies, business practices, or
whatever.  It is ultimately related to the DNS and the zone file in which a
glue record for the name server should properly be published.

So, I think we're talking about the same thing.  Could you get to the point
of whatever it is you have an issue with?  If you don't like the way these
special-case hosts are described in the current document, please suggest
alternative text to describe the concept.

By the way, none of this was introduced in EPP-07.  It's been this way for
several revisions, including the one that passed WG last call.

-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 g9A0mDJC009377 for <[e-mail]>; Thu, 10 Oct 2002 02:48:13 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g9A0mC57009376 for ietf-provreg-outgoing; Thu, 10 Oct 2002 02:48:12 +0200 (MEST)
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 g9A0mAJC009371 for <[e-mail]>; Thu, 10 Oct 2002 02:48:11 +0200 (MEST)
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 g9A0mjEQ006390; Wed, 9 Oct 2002 20:48:45 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: Definition of "External" Host 
In-Reply-To: Your message of "Wed, 09 Oct 2002 07:29:11 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 09 Oct 2002 20:48:45 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Scott,

It appears to me that there is some confusion concerning the following:

	1. the existance distinct policies scoped to the presence
	   (or absence) of infix dots, viz:
	  	*.a.z	policy "az",
	   	*.b.z	policy "bz",
	   	*.z	policy " z",

	2. the delegation of authoritative publication requirements,
	    viz:
	    	existence of glue records for nameservers (aka "hosts"),

	3. distinct instances of EPP servers.

In the context of the channel capacity of a single BEEP session I discussed
the possibility of a single TCP connection servicing the command/response
exchanges of two EPP endpoints conducting transactions against distinct
registries. This was in an exchange with Sheer El-Showk, back in August of
'01. That is what caught my limited attention in this exchange -- operators
with multiple policies and possibly using some mechanism other than distinct
endpoints to distinguish between policy scopes.

Comments:

New.Net marketed infix dots without delegation, and some other operators
may similarly market infix w/o delegation. Utility arguements for infix
dots w/o delegation are outside of our scope. This is fortunate for me,
as I can't think of any off-hand.

The text in -5 (host) at 2.5 isn't quite consistent with the text at 3.2,
the first has "SHOULD be required only as needed", the second a "REQUIRED
only as needed". However, we missed the point of using stub zones to
obviate the need for glue NS records in a parent zone.

I'd appreciate it if the discussion were less hypothetical, and some of
the discussion conducted in master file format.

Eric


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 g99MSdJC008670 for <[e-mail]>; Thu, 10 Oct 2002 00:28:39 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g99MSdGP008669 for ietf-provreg-outgoing; Thu, 10 Oct 2002 00:28:39 +0200 (MEST)
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 g99MSbJC008664 for <[e-mail]>; Thu, 10 Oct 2002 00:28:38 +0200 (MEST)
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 g99MSa100870 for <[e-mail]>; Wed, 9 Oct 2002 22:28:36 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <SZM95DBM>; Wed, 9 Oct 2002 18:28:39 -0400
Message-ID: <[e-mail]>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Definition of "External" Host
Date: Wed, 9 Oct 2002 18:28:33 -0400 
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

Scott,

Please see my comments below enclosed by <HL/>.

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[e-mail]]
Sent: Wednesday, October 09, 2002 7:29 AM
To: 'Liu, Hong'; '[e-mail]'
Subject: RE: Definition of "External" Host

> 
> Maybe an example will help explain my point. Suppose we have 
> a TLD .tld with
> two 3rd level delegations del1.tld and del2.tld. So there are 
> three disjoint
> name spaces under .tld: del1.tld, del2.tld and anything else 
> under .tld.
> These three name spaces have different registration policies. 
> They may also
> share some common registration policies.
> 
> If I understand correctly, .tld, .del1.tld, and .del2.tld are 
> considered as
> three separate "repositories". If not, please ignore the rest of the
> message.

My contention is that they are all under the same ultimate management
authority and part of the same repository because they are all part of the
same TLD branch.

<HL>
This is where you and I have different views. Yes, they are all part of the
same TLD, but they are different name spaces with different registration
policies. While it is true that the complete name space is governed by the
same management authority for most gTLDs, it is not true for many ccTLDs. So
in general, we cannot regard a TLD as one repository because there are
delegations under the same TLD, mostly at the second level, but also can be
extended to higher levels.

Back to the example, the name spaces are defined as follows:

.del1.tld: anything under the subtree rooted at .del1.tld. Registration
occurs at the 3rd level in the form of abc.del1.tld.
.del2.tld: anything under the subtree rooted at .del2.tld. Registration
occurs at the 3rd level in the form of def.del2.tld.
.tld: anything under .tld that are NOT under .del1.tld or del2.tld.
Registration occurs at the 2nd level in the form of ghi.tld.

Logially, these are three separate repositories, each of which has its own
registry DB and zone file. If an entity happens to manage both .tld and
.del1.tld, as an implementation optimization option, it may choose to
combine both registry DBs and generate one zone file. But that is registry
implementation option. It should not be codified into the protocol as the
generic case. I personally don't think that is good engineering since
optimization by collapsing logical structures often limits future
extensibility and may come back to haunt software development.

Of course, in order for DNS to work, del1.tld and del2.tld must be
registered under .tld as part of the pre-provisioning process by the .tld
registry operator. So if ns.del1.tld is a nameserver for del1.tld, then a
glue record must be created in the .tld zone file for that host.
</HL>

Think of it this way: should I or should I not be publishing glue records
for hosts registered under these domains?  If the answer is "yes", they are
not external hosts.  If the answer is "no", they are external hosts.

<HL>
I don't disagree with that, but I think the cause and result should be
reversed. Whether a glue record should be generated for a host w.r.t a
repository is determined by whether the host name belongs to the name space
in question. If the host is external to the name space, then no glue record
should be generated for that host. 

That is why it is so important to be explicit about the name space when
creating a host object. In EPP-07, the rules for creating an external host
are different than those for creating an internal host.
</HL>

-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 g99D7ZJC003988 for <[e-mail]>; Wed, 9 Oct 2002 15:07:35 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g99D7Zn3003987 for ietf-provreg-outgoing; Wed, 9 Oct 2002 15:07:35 +0200 (MEST)
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 g99D70JC003973 for <[e-mail]>; Wed, 9 Oct 2002 15:07:00 +0200 (MEST)
Received: from repligate ([67.36.181.100]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20021009130659.CTO14448.mailhost.chi1.ameritech.net@repligate>; Wed, 9 Oct 2002 08:06:59 -0500
Message-ID: <01ad01c26f94$cbcf0420$0100a8c0@repligate>
From: "Jim Fleming" <[e-mail]>
To: <[e-mail]>, "'Liu, Hong'" <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, "Ron Sherwood" <[e-mail]>, "Richard J. Sexton" <[e-mail]>, "Richard Henderson" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, "Judith Oppenheimer" <[e-mail]>, "Joop Teernstra" <[e-mail]>, "Joe Baptista" <[e-mail]>, "Joanna Lane" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, "Ben Edelman" <[e-mail]>, "@quasar Internet Solutions, Inc." <[e-mail]>
References: <[e-mail]>
Subject: Re: Definition of "External" Host
Date: Wed, 9 Oct 2002 08:07:15 -0500
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: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>; <[e-mail]>
Sent: Wednesday, October 09, 2002 6:29 AM
Subject: RE: Definition of "External" Host


> > The sentence you quoted seems OK if the terms "management 
> > authority" and
> > "repository" are precisely defined. It is not a problem if 
> > the repository is
> > the whole TLD and the management authority is the TLD 
> > registry operator.
> > However, it is getting complicated when delegation of name 
> > spaces occurs
> > under the same TLD in 3rd level and up.
> > 
> > Maybe an example will help explain my point. Suppose we have 
> > a TLD .tld with
> > two 3rd level delegations del1.tld and del2.tld. So there are 
> > three disjoint
> > name spaces under .tld: del1.tld, del2.tld and anything else 
> > under .tld.
> > These three name spaces have different registration policies. 
> > They may also
> > share some common registration policies.
> > 
> > If I understand correctly, .tld, .del1.tld, and .del2.tld are 
> > considered as
> > three separate "repositories". If not, please ignore the rest of the
> > message.
> 
> My contention is that they are all under the same ultimate management
> authority and part of the same repository because they are all part of the
> same TLD branch.
> 
> Think of it this way: should I or should I not be publishing glue records
> for hosts registered under these domains?  If the answer is "yes", they are
> not external hosts.  If the answer is "no", they are external hosts.
> 

Glue is the clue, but, it may not be that simple. You have to consider whether it is the
32-bit DNS or the 128-bit DNS. There are not many glue record services for the 32-bit DNS.
Also, if there are Mirrored Registries for the TLD in the 32-bit DNS, to prevent having
a single-point-of-corporate-failure, AND to allow transitions from a censored regime to
an open regime, then you might have a situation where one of the TLD Registries only has
a few SLD names, and the new TLD Registry could have all of those SLD names, plus all
of the new ones being added. Couple that with the 128-bit front-end Registry, with all of the
128-bit DNS AAAA Record Glue Control Services, and it is not so simple.

Glue is the clue...

128-bit DNS AAAA Record Flag Day Formats
2002:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
[YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
1-bit to set the Reserved/Spare ("SNOOPY") bit in Fragment Offset [S]
1-bit to set the Don't Fragment (DF) bit [D]
2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL]
1-bit for Options Control [O]
7-bits to set the Identification Field(dst) [FFFFFFF]
4-bits to set the TOS(dst) Field [TTTT]
Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000
FFF.FFFF.TTTT = GGG.SSSS.SSSS
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
IPv8
0QQQQGGGSSSSSSSS[32-bits][Port]
IPv16
0QQQQGGGSSSSSSSS[32-bits][Port]
1WWWWWWWSSSSSSSS[32-bits][Port]

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer...
http://www.ietf.com
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
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




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 g99BTYJC003025 for <[e-mail]>; Wed, 9 Oct 2002 13:29:34 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g99BTYPE003024 for ietf-provreg-outgoing; Wed, 9 Oct 2002 13:29:34 +0200 (MEST)
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 g99BTWJC003019 for <[e-mail]>; Wed, 9 Oct 2002 13:29:33 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA22231; Wed, 9 Oct 2002 07:29:26 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <4RC65DLX>; Wed, 9 Oct 2002 07:29:26 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Definition of "External" Host
Date: Wed, 9 Oct 2002 07:29:11 -0400 
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 sentence you quoted seems OK if the terms "management 
> authority" and
> "repository" are precisely defined. It is not a problem if 
> the repository is
> the whole TLD and the management authority is the TLD 
> registry operator.
> However, it is getting complicated when delegation of name 
> spaces occurs
> under the same TLD in 3rd level and up.
> 
> Maybe an example will help explain my point. Suppose we have 
> a TLD .tld with
> two 3rd level delegations del1.tld and del2.tld. So there are 
> three disjoint
> name spaces under .tld: del1.tld, del2.tld and anything else 
> under .tld.
> These three name spaces have different registration policies. 
> They may also
> share some common registration policies.
> 
> If I understand correctly, .tld, .del1.tld, and .del2.tld are 
> considered as
> three separate "repositories". If not, please ignore the rest of the
> message.

My contention is that they are all under the same ultimate management
authority and part of the same repository because they are all part of the
same TLD branch.

Think of it this way: should I or should I not be publishing glue records
for hosts registered under these domains?  If the answer is "yes", they are
not external hosts.  If the answer is "no", they are external hosts.

-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 g992TkJC029202 for <[e-mail]>; Wed, 9 Oct 2002 04:29:46 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g992TklT029201 for ietf-provreg-outgoing; Wed, 9 Oct 2002 04:29:46 +0200 (MEST)
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 g992TiJC029196 for <[e-mail]>; Wed, 9 Oct 2002 04:29:45 +0200 (MEST)
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 g992Th100778 for <[e-mail]>; Wed, 9 Oct 2002 02:29:43 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <SZM9Z6NV>; Tue, 8 Oct 2002 22:29:44 -0400
Message-ID: <[e-mail]>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Definition of "External" Host
Date: Tue, 8 Oct 2002 22:29:40 -0400 
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

Scott,

The sentence you quoted seems OK if the terms "management authority" and
"repository" are precisely defined. It is not a problem if the repository is
the whole TLD and the management authority is the TLD registry operator.
However, it is getting complicated when delegation of name spaces occurs
under the same TLD in 3rd level and up.

Maybe an example will help explain my point. Suppose we have a TLD .tld with
two 3rd level delegations del1.tld and del2.tld. So there are three disjoint
name spaces under .tld: del1.tld, del2.tld and anything else under .tld.
These three name spaces have different registration policies. They may also
share some common registration policies.

If I understand correctly, .tld, .del1.tld, and .del2.tld are considered as
three separate "repositories". If not, please ignore the rest of the
message.

Now suppose registry operator A is responsible for .tld and .del1.tld, and
registry operator B is responsible for .del2.tld. So A is the management
authority for .tld and del1.tld, while B is the management authority for
del2.tld. 

Let's say three domains have been created in the three repositories,
respectively: abc.tld, def.del1.tld, ghi.del2.tld. Suppose def.del1.tld
wants to use hosts ns.abc.tld and ns.ghi.del2.tld as its nameservers. The
questions are:

(1) Is ns.abc.tld an external host of def.del1.tld? 
The answer seems to be "yes" since .tld and .del1.tld are two different
repositories. However, the management authority of ns.abc.tld is identical
to that of del1.tld, i.e., registry operator A. In other words, A is not
external to def.del1.tld.

(2) Is ns.ghi.del2.tld an external host of def.del1.tld?
The answer is "yes", and the definition is fine.

So it seems what needs to be clarified is the case where two separate
repositories under the same TLD are administered by the same management
authority. The key lies in the delineation of repository, not the management
authority. In the above example, if we stick to the name space definition,
then the answers would be "yes" to both questions.

The real sticky issue is whether a host is external or not may not be clear
at the time it is created. In the above example, when ns.abc.tld is created,
it is not clear whether it will be used as a nameserver for abc.tld or
def.del1.tld since registry operator A operates both .tld and del1.tld. It
will only be clear when it is associated with either abc.tld (delegated) or
def.del1.tld (external). Additional questions are:

(3) Can ns.abc.tld be created without abc.tld being created first?
The answer seems to be "no" in the case. That is, the "subordinate host
rule" should take precedence over the "external host rule" for host object
creation.

(4) Can ns.abc.tld have multiple copies, one per registrar?
For the "subordinate host rule", the answer should be "no". But for the
"external host rule", the answer should be "yes". The dilemma is that
ns.abc.tld cannot become an external host unless it is associated with
def.del1.tld. However, it cannot be an external host for def.del1.tld unless
it is created as an external host object for the sponsoring registrar of
def.del1.tld. On the other hand, a subordinate host object ns.abc.tld
already exists for domain abc.tld. So creating another copy would fail!

With connection-oriented transport bindings such as TCP, (3) and (4) can be
resolved by assigning different connections between the registry and the
registrar for .tld and del1.tld. The server will be able to tell from the
connection whether the host object created is intended for .tld or del1.tld.
While this is not very efficient, it can be made to work. With
connection-less transport, such as HTTP or SMTP, we are not as lucky. Maybe
we should include a <respository> parameter in the <login> message for the
client to indicate to the server which name space(s) the session is set up
for.

I apologize for the long message. Basically I am talking myself through
these issues. I hope that I am not making this issue more confusing than
necessary, -:)

Regards,

--Hong


-----Original Message-----
From: Hollenbeck, Scott [mailto:[e-mail]]
Sent: Tuesday, October 08, 2002 7:59 PM
To: 'Liu, Hong'; '[e-mail]'
Subject: RE: Definition of "External" Host


> I have a question for clarification regarding the definition 
> of "external"
> host in the 2nd paragraph of Section 1.1 in
> draft-ietf-provreg-epp-host-05.txt. Does it mean that a host object is
> external to the current TLD only if the host name belongs to 
> another TLD?
> There are other cases that a host can also be external under 
> the same TLD
> but belongs to different 3rd level delegations. Thanks!

I think the definition in section 1.1 is pretty clear: if there is no
superordinate domain name (a domain name higher up in the hierarchy)
registered in the repository, the host is considered an external host.  What
matters is where the management authority for the host's registered domain
lies:

"Such hosts are
described as "external" hosts in this specification since the
management authority for these hosts is external to the repository in
which the host is being used for delegation purposes."

-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 g98NxAJC027212 for <[e-mail]>; Wed, 9 Oct 2002 01:59:10 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g98NxAPO027211 for ietf-provreg-outgoing; Wed, 9 Oct 2002 01:59:10 +0200 (MEST)
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 g98Nx8JC027200 for <[e-mail]>; Wed, 9 Oct 2002 01:59:09 +0200 (MEST)
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 TAA09186; Tue, 8 Oct 2002 19:59:02 -0400 (EDT)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <TF9XKY8L>; Tue, 8 Oct 2002 19:59:01 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Definition of "External" Host
Date: Tue, 8 Oct 2002 19:58:47 -0400 
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 question for clarification regarding the definition 
> of "external"
> host in the 2nd paragraph of Section 1.1 in
> draft-ietf-provreg-epp-host-05.txt. Does it mean that a host object is
> external to the current TLD only if the host name belongs to 
> another TLD?
> There are other cases that a host can also be external under 
> the same TLD
> but belongs to different 3rd level delegations. Thanks!

I think the definition in section 1.1 is pretty clear: if there is no
superordinate domain name (a domain name higher up in the hierarchy)
registered in the repository, the host is considered an external host.  What
matters is where the management authority for the host's registered domain
lies:

"Such hosts are
described as "external" hosts in this specification since the
management authority for these hosts is external to the repository in
which the host is being used for delegation purposes."

-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 g98KugJC026085 for <[e-mail]>; Tue, 8 Oct 2002 22:56:42 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g98KugYp026084 for ietf-provreg-outgoing; Tue, 8 Oct 2002 22:56:42 +0200 (MEST)
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 g98KueJC026079 for <[e-mail]>; Tue, 8 Oct 2002 22:56:41 +0200 (MEST)
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 g98Kud125307 for <[e-mail]>; Tue, 8 Oct 2002 20:56:40 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <SZM9ZZ3Q>; Tue, 8 Oct 2002 16:56:41 -0400
Message-ID: <[e-mail]>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Definition of "External" Host
Date: Tue, 8 Oct 2002 16:56:29 -0400 
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

Scott,

I have a question for clarification regarding the definition of "external"
host in the 2nd paragraph of Section 1.1 in
draft-ietf-provreg-epp-host-05.txt. Does it mean that a host object is
external to the current TLD only if the host name belongs to another TLD?
There are other cases that a host can also be external under the same TLD
but belongs to different 3rd level delegations. Thanks!

--Hong


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 g91EEFJC012111 for <[e-mail]>; Tue, 1 Oct 2002 16:14:15 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g91EEF0i012110 for ietf-provreg-outgoing; Tue, 1 Oct 2002 16:14:15 +0200 (MEST)
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 g91EEDJC012105 for <[e-mail]>; Tue, 1 Oct 2002 16:14:14 +0200 (MEST)
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 g91EED125390 for <[e-mail]>; Tue, 1 Oct 2002 14:14:13 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <SZM9YHGT>; Tue, 1 Oct 2002 10:14:24 -0400
Message-ID: <[e-mail]>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: 
Date: Tue, 1 Oct 2002 10:14:23 -0400 
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, all,

Just want to let you know that the EPP over SOAP draft is now in the IETF
I-D archive:

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

Cheers,

--Hong