Subject: RE: Updated (and hopefully the last) EPP Privacy Proposal

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 31 Dec 2002 17:04:22 -0500

> Assuming stateful nature of EPP protocol and planned  changes 
> to the protocol
> spec [ds] that are going to make <dcp> element mandatory the 
> first option
> brings almost as much clarity as the second one. At the same 
> time the first
> option allows simpler XML syntax for default disclosure policy.
> 
> [ds]
> http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00089.html

Janusz,

I never said that making the <dcp> element mandatory was something that was
going to be done -- it was only suggested as part of another proposed
solution.  Plus, the whole "separate structure" option has been discussed
with the IESG and they're not happy with it.

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'janusz sienkiewicz'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Updated (and hopefully the last) EPP Privacy Proposal
Date: Tue, 31 Dec 2002 17:04:22 -0500
Sender: [email-masked]

> Assuming stateful nature of EPP protocol and planned  changes 
> to the protocol
> spec [ds] that are going to make <dcp> element mandatory the 
> first option
> brings almost as much clarity as the second one. At the same 
> time the first
> option allows simpler XML syntax for default disclosure policy.
> 
> [ds]
> http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00089.html

Janusz,

I never said that making the <dcp> element mandatory was something that was
going to be done -- it was only suggested as part of another proposed
solution.  Plus, the whole "separate structure" option has been discussed
with the IESG and they're not happy with it.

-Scott-

Date: Tue, 31 Dec 2002 10:53:15 -0500
From: janusz sienkiewicz <[email-masked]>
Organization: LibertyRMS Co.
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: Updated (and hopefully the last) EPP Privacy Proposal
Sender: [email-masked]

"Hollenbeck, Scott" wrote:

> I think I need to add some clarifications to the proposal I sent to the list
> yesterday after reading Joe's and Janusz's comments:
>
> - the IESG has already seen the <doNotDisclose> proposal that I described
> earlier, and they weren't happy with it.  They'd rather see each element
> tagged in some way rather than duplicating elements and/or content in a
> separate structure.
>
> - I should probably have said that "do not disclose" means "do not disclose
> to unauthorized third parties outside the protocol channel".  We already
> have authorization mechanisms in place to deal with query responses; the
> attribute can be just an additional decision point in the server's query
> response policy.
>
> - I'm not suggesting that we get into whois disclosure semantics or any
> other semantics.  The <noWhois> example a provided was just that -- an
> example -- provided to show that application-specific semantics can be
> specified using the extension mechanism that we have in place now.  We're on
> the hook to provide a simple notice that others (like maybe the CRISP WG, in
> the case of whois-like functionality) can use to define application-specific
> semantics.
>
> - XML attributes aren't extensible by design.  Adding semantic meaning can
> be done via extensions.
>
> - If we want to specify a default attribute value for a 'dnd' attribute, it
> MUST be done in the schema because XML Schema requires defaults to be
> specified in the schema.  On the other hand, we could leave the XML
> attribute default out and leave default _behavior_ up to the server operator
> OR we could require that the attribute be present all the time to eliminate
> any ambiguity.  The latter approach might be best to make things perfectly
> clear in case someone who receives the data doesn't know the server's
> default disclosure policy -- like if the optional <dcp> element isn't
> presented.
>

Assuming stateful nature of EPP protocol and planned  changes to the protocol
spec [ds] that are going to make <dcp> element mandatory the first option
brings almost as much clarity as the second one. At the same time the first
option allows simpler XML syntax for default disclosure policy.

[ds]
http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00089.html

>
> Does any of this help make the proposal more clear?  The IESG's concern is
> that we need to specify a simple binary flag -- we don't have to get into
> how that flag should be used by different applications.  They are perfectly
> OK with doing anything beyond the flag in extensions.
>
> -Scott-

Janusz

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Joe Abley'" <[email-masked]>, "'janusz sienkiewicz'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Updated (and hopefully the last) EPP Privacy Proposal
Date: Tue, 31 Dec 2002 08:53:29 -0500
Sender: [email-masked]

I think I need to add some clarifications to the proposal I sent to the list
yesterday after reading Joe's and Janusz's comments:

- the IESG has already seen the <doNotDisclose> proposal that I described
earlier, and they weren't happy with it.  They'd rather see each element
tagged in some way rather than duplicating elements and/or content in a
separate structure.

- I should probably have said that "do not disclose" means "do not disclose
to unauthorized third parties outside the protocol channel".  We already
have authorization mechanisms in place to deal with query responses; the
attribute can be just an additional decision point in the server's query
response policy.

- I'm not suggesting that we get into whois disclosure semantics or any
other semantics.  The <noWhois> example a provided was just that -- an
example -- provided to show that application-specific semantics can be
specified using the extension mechanism that we have in place now.  We're on
the hook to provide a simple notice that others (like maybe the CRISP WG, in
the case of whois-like functionality) can use to define application-specific
semantics.

- XML attributes aren't extensible by design.  Adding semantic meaning can
be done via extensions.

- If we want to specify a default attribute value for a 'dnd' attribute, it
MUST be done in the schema because XML Schema requires defaults to be
specified in the schema.  On the other hand, we could leave the XML
attribute default out and leave default _behavior_ up to the server operator
OR we could require that the attribute be present all the time to eliminate
any ambiguity.  The latter approach might be best to make things perfectly
clear in case someone who receives the data doesn't know the server's
default disclosure policy -- like if the optional <dcp> element isn't
presented.

Does any of this help make the proposal more clear?  The IESG's concern is
that we need to specify a simple binary flag -- we don't have to get into
how that flag should be used by different applications.  They are perfectly
OK with doing anything beyond the flag in extensions.

-Scott-

Date: Mon, 30 Dec 2002 16:38:30 -0500
From: janusz sienkiewicz <[email-masked]>
Organization: LibertyRMS Co.
To: "Hollenbeck, Scott" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Updated (and hopefully the last) EPP Privacy Proposal
Sender: [email-masked]

I am in favour of solution [3] the one with <doNotDisclose> element.

For the client side the attribute based approach and <doNotDisclose> approach
introduce the same level of complexity. For the server side the attribute based
approach is more cumbersome. The server has to check all object elements in epp
request to determine if there are any discrepancies from default disclosure
policy. The <doNotDisclose> approach leads to a simpler algorithm. The server
has to check just one element to find all relevant information.

I would suggest a modification to <doNotDisclose> approach. The approach in its
original shape is not symmetric for all registry implementations. For example a
registry that does not disclose any contact information has to use more complex
xml syntax than the one that discloses all contact information.

The following changes should introduce more symmetry and flexibility:

(1) The default disclosure behaviour for various object mappings should be a
part of server policy.  The server could inform the client about its policies
through <dcp> or any new response element.

(2) <doNotDisclose> element should be replaced by <disclose> with boolean flag
attribute (<disclose flag="no">).

Similiar symmetry issue exists in attribute based proposal. The default values
of dnd attributes for domain, host and contact object
mappings should be a part of server policy.

Janusz Sienkiewicz

"Hollenbeck, Scott" wrote:

> In ongoing background discussions with the IESG regarding our EPP documents,
> we (Jaap, Ed, several IESG members, and I) have continued to talk about the
> IESG's privacy-related comments and the responses to those comments that
> have been sent to the WG mailing list.  We've concluded that we need to add
> a "must implement" feature to the protocol to allow data elements to be
> tagged with a binary indicator of data owner preference for disclosure of
> information to third parties that aren't involved in the provisioning
> transaction.  Back in October [1] I described a proposal to use an XML
> attribute for this purpose.  Over the last few weeks ([2], [3]) I suggested
> a few other options.  Considering all of our options, I would again like to
> suggest an XML attribute-based approach to address this last remaining IESG
> review issue.
>
> This does not mean that the binary indicator is the only way that privacy
> preferences or policies can be expressed.  Expression of more specific
> privacy policies can be accomplished using the protocol's extension
> mechanism.
>
> The proposal is to add a new attribute to every object element in the
> domain, contact, and host mappings.  This boolean attribute, "dnd" (for Do
> Not Disclose), 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) in the domain and host mappings, and a
> default value of "true" (meaning it is NOT ok to disclose info) in the
> contact mapping.  The defaults can be over-ridden and explicitly specified
> by clients.  Additional constraints can be defined using the protocol
> extension mechanism.
>
> Here are some examples:
>
> <contact:email dnd="true">[email-masked]</contact:email>
> <contact:email>[email-masked]</contact:email>
> Both of the above mean "do not disclose this email address to third
> parties".
>
> <contact:email dnd="false">[email-masked]</contact:email>
> This means that the data owner gives permission for the email address to be
> disclosed to third parties.
>
> <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.)
>
> I'll also 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 email
> address example above) when turning on the attribute is counter to some
> policy.
>
> A measure of WG support or dissatisfaction with this proposal would be
> helpful.  Would you please send a note to the mailing list to let the chairs
> know if you either support the proposal as a way to move forward or if you
> do not support the proposal?  If you do not support the proposal it would be
> helpful if you explained why and could suggest modifications (if possible)
> to make it acceptable.
>
> If you do not support the proposal, please recognize that we have been stuck
> on this issue for quite a while and we need to do something.  On the one
> hand, we are aware of the differences in privacy policy, laws, et al. facing
> each registry.  On the other hand, we are being asked to define one standard
> protocol that is rigorous enough to not let privacy slide by.  So the
> question is - does this proposal (including extension support) allow for all
> known policies to be expressed within EPP?
>
> -Scott-
>
> [1]
> http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00041.html
>
> [2]
> http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00089.html
>
> [3]
> http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00093.html

Date: Mon, 30 Dec 2002 13:31:45 -0500
Subject: Re: Updated (and hopefully the last) EPP Privacy Proposal
Cc: [email-masked]
To: "Hollenbeck, Scott" <[email-masked]>
From: Joe Abley <[email-masked]>
Sender: [email-masked]

1. "do not disclose" seems non-extensible, when extensibility seems 
important.

There seems to be more than one party to whom disclosure could be 
controlled:

   + the registrant (unlikely!)
   + the sponsoring registrar (unlikely!)
   + non-sponsoring registrars
   + parties who have reliably identified themselves
   + parties who have agreed to abide by some terms and conditions
   + parties who have paid for access
   + parties who have not exceeded a threshold of data retrieval
   + parties within (or not within) a specific jurisdictional domain 
(e.g. a country, or a state)
   + parties specifically specified by the data owner
   + other defined groups
   + everybody else

There is also the potential to control disclosure according to the 
retrieval mechanism (web page, whois server, bulk export, etc).

Given that the addition of new "do not disclose" semantics has the 
potential to touch every field relating to domains, hosts and contacts, 
it seems reasonable to try and get this reasonably correct in the first 
cut. Hardly any of those questions need to be answered by the EPP spec, 
but the EPP spec should not prevent them from being answered.

The "dnd" functionality needs to be extensible in order to be useful, I 
think. I can't think of a way to make that happen using attributes.

2. A complete proposal should specify whether a "dnd"d field should be 
distinguished from a non-existent field when presenting data to clients 
(e.g. via <info> commands). If it should, then the proscribed manner in 
which that should be done should be included for <info>.

3. What should <check> return if the object being checked is marked as 
dnd="true" and the client doing the <check> is one to which disclosure 
is prohibited?

4. I like the <doNotDisclose> functionality you described in your 
earlier message more than the <noWhoIs> in your more recent message: 
<doNotDisclose> is a better name, and I think you want the <noWhois> to 
enclose the <extension>, rather than the other way round? A separate 
element also gives greater scope for extensibility.

The dnd attribute proposal looks implementable now, but I have doubts 
about whether the coarse functionality it provides is actually useful. 
The reasons those doubts bother me is that future revisions to the dnd 
functionality are going to touch a lot of fields within the schema, and 
it would be nice to avoid wholesale schema and data migration problems 
in the future if we can.

The <doNotDisclose> idea looks more extensible, and I think it is a 
more promising approach.

It might be worth mentioning that neither of these proposals touch the 
base EPP spec. I don't see how privacy concerns should stop the base 
EPP spec from proceeding, when it seems clear that their scope is 
limited to the object binding specifications which deal with data.

Joe

On Monday, Dec 30, 2002, at 09:08 Canada/Eastern, Hollenbeck, Scott 
wrote:

> In ongoing background discussions with the IESG regarding our EPP 
> documents,
> we (Jaap, Ed, several IESG members, and I) have continued to talk 
> about the
> IESG's privacy-related comments and the responses to those comments 
> that
> have been sent to the WG mailing list.  We've concluded that we need 
> to add
> a "must implement" feature to the protocol to allow data elements to be
> tagged with a binary indicator of data owner preference for disclosure 
> of
> information to third parties that aren't involved in the provisioning
> transaction.  Back in October [1] I described a proposal to use an XML
> attribute for this purpose.  Over the last few weeks ([2], [3]) I 
> suggested
> a few other options.  Considering all of our options, I would again 
> like to
> suggest an XML attribute-based approach to address this last remaining 
> IESG
> review issue.
>
> This does not mean that the binary indicator is the only way that 
> privacy
> preferences or policies can be expressed.  Expression of more specific
> privacy policies can be accomplished using the protocol's extension
> mechanism.
>
> The proposal is to add a new attribute to every object element in the
> domain, contact, and host mappings.  This boolean attribute, "dnd" 
> (for Do
> Not Disclose), 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) in the domain and host mappings, 
> and a
> default value of "true" (meaning it is NOT ok to disclose info) in the
> contact mapping.  The defaults can be over-ridden and explicitly 
> specified
> by clients.  Additional constraints can be defined using the protocol
> extension mechanism.
>
> Here are some examples:
>
> <contact:email dnd="true">[email-masked]</contact:email>
> <contact:email>[email-masked]</contact:email>
> Both of the above mean "do not disclose this email address to third
> parties".
>
> <contact:email dnd="false">[email-masked]</contact:email>
> This means that the data owner gives permission for the email address 
> to be
> disclosed to third parties.
>
> <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.)
>
> I'll also 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 
> email
> address example above) when turning on the attribute is counter to some
> policy.
>
> A measure of WG support or dissatisfaction with this proposal would be
> helpful.  Would you please send a note to the mailing list to let the 
> chairs
> know if you either support the proposal as a way to move forward or if 
> you
> do not support the proposal?  If you do not support the proposal it 
> would be
> helpful if you explained why and could suggest modifications (if 
> possible)
> to make it acceptable.
>
> If you do not support the proposal, please recognize that we have been 
> stuck
> on this issue for quite a while and we need to do something.  On the 
> one
> hand, we are aware of the differences in privacy policy, laws, et al. 
> facing
> each registry.  On the other hand, we are being asked to define one 
> standard
> protocol that is rigorous enough to not let privacy slide by.  So the
> question is - does this proposal (including extension support) allow 
> for all
> known policies to be expressed within EPP?
>
> -Scott-
>
> [1]
> http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00041.html
>
> [2]
> http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00089.html
>
> [3]
> http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00093.html

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Updated (and hopefully the last) EPP Privacy Proposal
Date: Mon, 30 Dec 2002 09:08:46 -0500
Importance: high
Sender: [email-masked]

In ongoing background discussions with the IESG regarding our EPP documents,
we (Jaap, Ed, several IESG members, and I) have continued to talk about the
IESG's privacy-related comments and the responses to those comments that
have been sent to the WG mailing list.  We've concluded that we need to add
a "must implement" feature to the protocol to allow data elements to be
tagged with a binary indicator of data owner preference for disclosure of
information to third parties that aren't involved in the provisioning
transaction.  Back in October [1] I described a proposal to use an XML
attribute for this purpose.  Over the last few weeks ([2], [3]) I suggested
a few other options.  Considering all of our options, I would again like to
suggest an XML attribute-based approach to address this last remaining IESG
review issue.

This does not mean that the binary indicator is the only way that privacy
preferences or policies can be expressed.  Expression of more specific
privacy policies can be accomplished using the protocol's extension
mechanism.

The proposal is to add a new attribute to every object element in the
domain, contact, and host mappings.  This boolean attribute, "dnd" (for Do
Not Disclose), 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) in the domain and host mappings, and a
default value of "true" (meaning it is NOT ok to disclose info) in the
contact mapping.  The defaults can be over-ridden and explicitly specified
by clients.  Additional constraints can be defined using the protocol
extension mechanism.

Here are some examples:

<contact:email dnd="true">[email-masked]</contact:email>
<contact:email>[email-masked]</contact:email>
Both of the above mean "do not disclose this email address to third
parties".

<contact:email dnd="false">[email-masked]</contact:email>
This means that the data owner gives permission for the email address to be
disclosed to third parties.

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

I'll also 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 email
address example above) when turning on the attribute is counter to some
policy.

A measure of WG support or dissatisfaction with this proposal would be
helpful.  Would you please send a note to the mailing list to let the chairs
know if you either support the proposal as a way to move forward or if you
do not support the proposal?  If you do not support the proposal it would be
helpful if you explained why and could suggest modifications (if possible)
to make it acceptable.

If you do not support the proposal, please recognize that we have been stuck
on this issue for quite a while and we need to do something.  On the one
hand, we are aware of the differences in privacy policy, laws, et al. facing
each registry.  On the other hand, we are being asked to define one standard
protocol that is rigorous enough to not let privacy slide by.  So the
question is - does this proposal (including extension support) allow for all
known policies to be expressed within EPP?

-Scott-

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

[2]
http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00089.html

[3]
http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00093.html

Date: Tue, 24 Dec 2002 14:42:53 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: milestone discussion
Cc: [email-masked], Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

FYI -

Just to keep the WG in the loop of what's happening, this is a 
message I sent to Patrik concerning our milestones.

What's here isn't complete list of issues, e.g., last verified and 
external hosts are two that come to mind, but I don't anticipate them 
being milestone changers.

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

To replace all of our remaining milestones, I propose something like this.

FEB 03 Submit Guidelines for Extending the EPP to IESG (Informational)
SEP 03 Perform Interoperability Tests
OCT 03 Submit Interoperability Report to IESG (Informational)
OCT 03 Submit Extensible Provisioning Protocol to IESG (Draft)
OCT 03 Submit EPP Contact Mapping to IESG (Draft)
OCT 03 Submit EPP Domain Name Mapping to IESG (Draft)
OCT 03 Submit EPP Host Mapping to IESG (Draft)
OCT 03 Submit EPP Transport Over TCP to IESG (Draft)

I'm assuming that we can respond to the IESG soon for the immediate 
comments, and that we hit Proposed Standard by March or so.

Here are some unknowns -

0) Successfully addressing all the IESG concerns.  I think we are 
real close to this.  I'm assuming that by the second week in January 
we can have a 'formal reply' to everything.  Sooner if it weren't for 
the holidays.

1) Issues arising.  We have some recent entrants to the 
implementation game and they have found a significant, recognized 
issue.  (Other issues have been smoothed over with discussion.)  The 
question (for Patrik) is:

o Do we continue to press the current specs through the IESG and 
address the issues at DS level?

o Do we continue to press the current specs through the IESG and 
address the issues are a return to PS?  (Does the 6 month clock 
restart or not?)

o Do we stop pressing the current specs through the IESG and address 
the issues before achieving PS at all?

I don't think the issues are EPP-shattering, but seem to need some 
working.  (The ROID issue is what I have in mind.)

2) "Other transports".  So far there has been little demand for EPP 
via SOAP beyond the conversations in the face to face meeting in 
Atlanta.  I haven't seen a revision.  I'm inclined to omit it at this 
time, but perhaps consider it at Experimental if coerced.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-jseng-idn-admin-02.txt,.pdf
Date: Mon, 23 Dec 2002 07:54:49 -0500
Sender: [email-masked]

--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 et al.
	Filename	: draft-jseng-idn-admin-02.txt,.pdf
	Pages		: 20
	Date		: 2002-12-20
	
Achieving internationalized access to domain names raises
many complex issues.  These include are 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
[email-masked].

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-jseng-idn-admin-02.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
CC: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-jseng-idn-admin-02.txt,.pdf
Date: Mon, 23 Dec 2002 07:54:49 -0500
Sender: [email-masked]

--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 et al.
	Filename	: draft-jseng-idn-admin-02.txt,.pdf
	Pages		: 20
	Date		: 2002-12-20
	
Achieving internationalized access to domain names raises
many complex issues.  These include are 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
[email-masked].

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-jseng-idn-admin-02.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 19 Dec 2002 08:16:01 -0800
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: RE: EPP Compliance (Was Re: lastVerified: optional vs. extension)
Sender: [email-masked]

Answering at my usual rate of a week late...

The IETF does not get into conformance, it gets into 
interoperability.  What this means is that we don't determine if any 
implementation is conformant to a specification.  We are focused on 
whether implementations can work together.

For EPP, the question will be:

Can BrandX client communicate with BrandY server?
Can BrandY client communicate with BrandX server?

For as many values of X and Y (X != Y) as possible.

In reality, the desire is that if RegistrarA uses BrandX client 
software, will they be able to communicate with RegistryB's BrandY 
server and RegistryC's BrandZ server, using the extensions needed for 
each environment.  Each environment means the policy of the registry.

 From the other side, can RegistryB's BrandY server communicate with 
both RegistrarA's BrandX client and RegistrarD's BrandW client 
according to the policies set forth by the registry (modulo any 
tweaks for business needs)?

As has been mentioned, BrandY's server will at best be described as 
implementing RFC's at one level of granularity.  However, I should 
caution folks to realize that RFC's are not standards - they are 
documents in a series.  (This misunderstanding is something that 
concerns me as an IETF'er, but as a WG chair, I can not to anything 
about it.)  What we want to see is BrandY's server also claim 
conformance with the Draft Standard (or Full Standard) version of EPP 
"as defined in documents RFC <etc.>."

How this works in practice is that the implementations should be 
extensible (just like the protocol) so that parts can be plugged in 
as needed.  E.g., if a BrandX client is working fine with a BrandY 
server for the environment in which they exist but I want to start 
working with BrandZ server in another environment, I may need to 
upgrade my BrandX client.  The hope is that the upgrade is possible 
and accomplishes the needed interaction.

As part of IETF activity, we don't want to get into conformance 
claims and we don't want to get into conformance enforcement.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

Date: Wed, 18 Dec 2002 18:48:12 +0100
From: [email-masked]
To: [email-masked], [email-masked]
Subject: mod_epp - first (pre)release
Sender: [email-masked]

All,

we have just released the first tarball of our Apache2 module mod_epp,
a protocol module enabling Apache2 to "speak" EPP over TCP (should be 
fairly conformant to the current epp/tcp transport draft). 

The module is intended to be used as a frontend tier of an EPP server
based on Apache2. TLS, Authentication and logging are leveraged from the
existing Apache implementation of HTTP, well known CGI/Web based
programming techniques can be used to implement backend tier layers.

We are releasing this early version to raise awareness about this alternative
to the "glue together openssl xinetd phread xerces java"-approach of
implementing an EPP server.

more information plus source is available at:

http://sf.net/projects/aepps/

Please note:

- Consider it alpha software at this point in time. We know that there
  are bugs, and you may find some additional ones as well.
- mod_epp does not implement any business backend logic. That's up to
  either our sample CGI scripts (hint!) or to your current business
  logic system.
- Your feedback is valueable, appreciated and a neccessity for future
  development. see sig below.

Otmar Lendl, Alex Mayrhofer
[email-masked], [email-masked]

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Stephane Bortzmeyer'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Another Privacy Proposal
Date: Tue, 17 Dec 2002 07:35:43 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Stephane Bortzmeyer [mailto:[email-masked]]
> Sent: Tuesday, December 17, 2002 4:03 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]'
> Subject: Re: Another Privacy Proposal
> 
> 
> On Mon, Dec 16, 2002 at 02:44:04PM -0500,
>  Hollenbeck, Scott <[email-masked]> wrote 
>  a message of 79 lines which said:
> 
> > discussion we received a critical clarification: what 
> they're looking to
> > have added is a means to identify data elements for which 
> the data owner
> > would like to note that the data should not be disclosed to third
> > parties.
> 
> Like every other proposal I've seen on this list about privacy, this
> suggestion solves only a very small part of the problem. For instance,
> it does not distinguish between individual access and bulk access by
> third parties (while many registries, such as AFNIC for the .fr ccTLD
> or the RIPE-NCC for their IP addresses database, allow unrestricted
> individual access  but completely prohibit bulk access). Also, it does
> not distinguish between the uses of the data (research, marketing, IPR
> harassment, etc). 

It doesn't do those things because that's not what the IESG is saying is
needed.  If you think such things are needed, please prepare a proposal to
address those requirements.

> I do not think it is possible to come with a reasonable
> "one-paragraph" solution to this difficult problem. I suggest to defer
> it to extensions, possibly using the P3P namespace and elements.

The IESG has already balked at the idea of doing this all in extensions.

> If a proposal like the last one is retained, I suggest to add the
> following warning:
> 
> Some registries may use extensions or other registry-specific
> mechanism (possibly out-band, such as local laws) to gather privacy
> requirments. The lack of a <doNotDisclose> element MUST NOT be
> interpreted as the complete absence of privacy requirments.

I would disagree with this wording.  The absence of a privacy specification,
either in a <doNotDisclose> element or an extension, can only be interpreted
as agreement with the stated data collection policy.

-Scott-

Date: Tue, 17 Dec 2002 10:02:34 +0100
From: Stephane Bortzmeyer <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: Another Privacy Proposal
Organization: NIC France
Sender: [email-masked]

On Mon, Dec 16, 2002 at 02:44:04PM -0500,
 Hollenbeck, Scott <[email-masked]> wrote 
 a message of 79 lines which said:

> discussion we received a critical clarification: what they're looking to
> have added is a means to identify data elements for which the data owner
> would like to note that the data should not be disclosed to third
> parties.

Like every other proposal I've seen on this list about privacy, this
suggestion solves only a very small part of the problem. For instance,
it does not distinguish between individual access and bulk access by
third parties (while many registries, such as AFNIC for the .fr ccTLD
or the RIPE-NCC for their IP addresses database, allow unrestricted
individual access  but completely prohibit bulk access). Also, it does
not distinguish between the uses of the data (research, marketing, IPR
harassment, etc). 

I do not think it is possible to come with a reasonable
"one-paragraph" solution to this difficult problem. I suggest to defer
it to extensions, possibly using the P3P namespace and elements.

If a proposal like the last one is retained, I suggest to add the
following warning:

Some registries may use extensions or other registry-specific
mechanism (possibly out-band, such as local laws) to gather privacy
requirments. The lack of a <doNotDisclose> element MUST NOT be
interpreted as the complete absence of privacy requirments.

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Another Privacy Proposal
Date: Mon, 16 Dec 2002 14:44:04 -0500
Sender: [email-masked]

In continued discussions with the IESG around their privacy-related
comments, I've asked them to consider another alternative to address their
comments.  First, though, I should note that during the course of the
discussion we received a critical clarification: what they're looking to
have added is a means to identify data elements for which the data owner
would like to note that the data should not be disclosed to third parties.
"Third parties" means some entity other than the client and server operator.

Here's my idea:

We can add a new element wrapper that allows the client to note the specific
element values that should not be disclosed to third parties, like this:

<contact:doNotDisclose>
  <contact:email>
  <contact:voice>
</contact:doNotDisclose>

The definition of the wrapper would allow all of the data elements (like,
name, address, email, voice, fax, etc.) to be included, if desired.  The
element could be optional so that it wouldn't be present at all if no
restrictions are requested.  Here's what it might look like when
incorporated into a command to create a contact object:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
     epp-1.0.xsd">
  <command>
    <create>
      <contact:create
       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
       xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
       contact-1.0.xsd">
        <contact:id>sh8013</contact:id>
        <contact:postalInfo type="int">
          <contact:name>John Doe</contact:name>
          <contact:org>Example Inc.</contact:org>
          <contact:addr>
            <contact:street>123 Example Dr.</contact:street>
            <contact:street>Suite 100</contact:street>
            <contact:city>Dulles</contact:city>
            <contact:sp>VA</contact:sp>
            <contact:pc>20166-6503</contact:pc>
            <contact:cc>US</contact:cc>
          </contact:addr>
        </contact:postalInfo>
        <contact:voice x="1234">+1.7035555555</contact:voice>
        <contact:fax>+1.7035555556</contact:fax>
        <contact:email>[email-masked]</contact:email>
        <contact:authInfo>
          <contact:pw>2fooBAR</contact:pw>
        </contact:authInfo>
<!-- New elements here. -->
        <contact:doNotDisclose>
          <contact:email>
          <contact:voice>
        </contact:doNotDisclose>
<!-- End of new elements. -->
      </contact:create>
    </create>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

I'll also have to come up with text to describe how this works, and to note
that how discrepancies between client-specified preferences and server
policies are addressed is a matter of server policy.  For example, if a
client says "do not disclose my email address", but the server operator's
policy is to publish that address in some publicly visible way, then the
server response to this kind of conflicting request may vary depending on
operational policies.

I'm still working this proposal through the IESG.  Does it sound like a way
forward to the WG?  Note that the IESG request is to include this sort of
facility in the domain and host mappings, too.

-Scott-

Date: Fri, 13 Dec 2002 11:52:26 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: what I'm doing now
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Here are our current priorities as chairs....

1) Get the minutes submitted in a few hours
2) Address the comments of the IESG we have been given
3) Discuss with the IESG how to proceed given recent discussions in the group
4) Revise our milestones
       Sub-bullet - commit or not on SOAP document is the hang up
5) Catch up on certain list discussions
       Last Verified
       External Hosts
       ROID
6) Check on other discussions

To make this known to all folks, (speaking for myself) I try to stay 
about a week behind the mailing list.  I don't want to be drawn into 
decisions on the protocol design unless we don't seem to be coming to 
consensus.  I also will go as far as possible to avoid being the one 
who makes a design call.  If I do make a mistake in declaring 
consensus, that will be rectified - I will at least make a personal 
appeal (off-list) to find out what the obstacle is.

I want to make a few other comments:

1) Proposed Standard level is designed to allow for implementation 
experience "to begin" in the sense that we don't go to Draft Standard 
without interoperability (the goal here in the IETF).  There is 
pressure on the IETF to stop being too picky and too perfect on 
documents - you might want to contrast this with desires to have a 
perfect solution in the first set of RFCs.

2) There's some concern that ICANN is asking for a standard, and that 
a Proposed Standard RFC fits this.  This isn't a WG problem, I can't 
redefine the meanings of PS, DS, and Full Standard, and the meanings 
of RFC and STD (yes, there's a STD series, along with FYI) to please 
ICANN (or whomever, and no offense is intended - I'm just a WG chair).

3) When anyone thinks of a new feature - really think long and hard 
if it necessarily belongs in the core of the protocol.  Over time one 
of the aspects we should be trying to fight is bloat in the core.  If 
there is any excuse to make something an extension, let's do that. 
If during implementation and interoperability we decide that an 
extension is necessarily a part of the core, we'll roll it in then.

If anyone is getting frustrated by a discussion - you have my email 
(and Jaap's) and my office phone number below (which I'm not always 
at, but it takes messages).

Finally - if you think our plan isn't the right thing to do - let the 
chairs know (in public or private).  That's why this message is being 
sent.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Antony Perkov'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: date-time values in EPP
Date: Fri, 13 Dec 2002 10:40:33 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Antony Perkov [mailto:[email-masked]]
> Sent: Friday, December 13, 2002 9:49 AM
> To: [email-masked]'
> Subject: date-time values in EPP
> 
> 
> I can't seem to find anything in the EPP documents that 
> specifies how many
> digits to use to represent fractions of a second in date-time values.
> 
> The examples all seem to use 1 digit. Is this mandatory, or 
> can more or less
> precise values be used?

More precision can be used.  See below.

> It would be nice to have some guidance on this, especially as 
> RFC3339 states
> that fractions of a second are a rarely used option.

The EPP documents have normative references to RFC 3339 and the XML Schema
specifications.  3339 specifies this syntax for fractions of a second:

time-fraction     = ("," / ".") 1*DIGIT

which means at least 1 digit with no upper limit on the number of digits.

The EPP documents use the XML Schema "dateTime" data type.  The XML Schema
text for the dateTime data types says this:

"Additional digits can be used to increase the precision of fractional
seconds if desired i.e the format ss.ss... with any number of digits after
the decimal point is supported."

So, it's all there in the normative references and the normative data type
definition.

-Scott-

From: Antony Perkov <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: date-time values in EPP
Date: Fri, 13 Dec 2002 14:48:46 -0000
Sender: [email-masked]

I can't seem to find anything in the EPP documents that specifies how many
digits to use to represent fractions of a second in date-time values.

The examples all seem to use 1 digit. Is this mandatory, or can more or less
precise values be used?

It would be nice to have some guidance on this, especially as RFC3339 states
that fractions of a second are a rarely used option.

Antony Perkov
Poptel

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Document Status
Date: Fri, 13 Dec 2002 08:54:11 -0500
Sender: [email-masked]

Here's where I am in terms of editing the WG documents to address IESG and
recent WG comments:

- All of the IESG comments have been addressed except those that relate to
privacy.  More on that below.

- I'm going with Ed's assessment [1] that we do not have consensus to
include Rick's "lastVerified" suggestion as an optional element.

- I've heard no objections to Janusz' suggested replacement text [2] for the
description of external host processing, so I plan to incorporate his text
changes.

Now for the privacy stuff: I've seen no support for the IESG suggestion to
tag individual elements with a "private" attribute, so we need to come up
with a counter proposal to take back to them.  I see two choices:

1) We again describe how we can define privacy policies via the extension
mechanism.  I already tried this once and the idea wasn't well received.
Or,

2) We make the <dcp> element mandatory and add an element (with dcp-like
child elements) to the command structure that allows the client to opt-out
of the data collection policy elements announced by the server.  I haven't
tried to float this by the IESG so I'd like to know how the WG feels about
the idea.

Thoughts, please.

-Scott-

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

[2]
http://www.cafax.se/ietf-provreg/maillist/2002-11/msg00065.html

To: Edward Lewis <[email-masked]>
cc: [email-masked]
Subject: Re: last chance to comment 
Date: Thu, 12 Dec 2002 15:11:11 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    Folks - sorry if this seems last minute - I sent it a few days ago, 
    it got hung up in a mail queue somewhere.  I swear!  (The dog ate my 
    homework!)

Yes, It really did. With all the attachments, the majordomo server
said it was too big and bounced it. With all the spam bouncing
around, at first I didn't notice until this morning. Sorry about that.

	jaap

Date: Thu, 12 Dec 2002 08:56:06 -0500
To: Edward Lewis <[email-masked]>, [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Re: last chance to comment
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Folks - sorry if this seems last minute - I sent it a few days ago, 
it got hung up in a mail queue somewhere.  I swear!  (The dog ate my 
homework!)

At 20:54 -0500 12/10/02, Edward Lewis wrote:
><x-flowed>I plan to send this in by Friday of this week.  I made some edits to
>the notes for clarification.  Let me know if anyone wants to suggest
>other edits.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

Date: Tue, 10 Dec 2002 20:54:47 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: last chance to comment
Cc: [email-masked], [email-masked]
Sender: [email-masked]

--============_-1172544961==_============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

I plan to send this in by Friday of this week.  I made some edits to 
the notes for clarification.  Let me know if anyone wants to suggest 
othter edits.

--------

Action Items:
1. Respond to the IESG comments.

Most of the comments are easily addressed.  A few need further 
discussion (and are listed as separate action items).

2. Come to a final understanding of UDP and EPP.

There have been some words posted to the "outlawing" of UDP, one 
response was to require stream based protocols.

3. Clarify the adoption of P3P concepts.

P3P was written for website environments, not a business to business 
situation.  This is reflected in some of our examples and needs to be 
cleaned up.

Rick Wesson volunteered to summarize a discussion on privacy issues. 
It might be up to us to forge new ground here as we are one of the 
few protocols that gathers personal information (for registration 
information).

4. Whether or not we adopt a work item for the SOAP 'as transport' draft.

A thread has been started on the list, but the results are luke warm for now.

5. An SMTP mapping is all but dead in the water.

Unless someone objects on the mail list, we're dropping all 
milestones relating to SMTP.

6. Continue to progress on Guidelines.

No sense of urgency, at least not until we get #1 above done.

Two other action items...

7. Clean up the milestones.

After the meeting we talked and decided that the milestones on the 
web page aren't sufficiently descriptive.  Before fixing them, #4 and 
#5 need answers.

8. Discuss 'lastVerified' - mandatory, extension or optional

9. Discuss handling of external hosts

Details on meeting discussion:
IETF provreg Working Group
==========================
9.00-11.30 Slot, IETF 55, 19 November 2002

Chairs: Ed Lewis and Jaap Akkerhuis
Author: Kim Davies

IESG Comments on EPP Drafts
---------------------------

Comments by Ed Lewis (EL)/Scott Hollenbeck (SH):

1. Do we place mailing list names and URLs in RFCs?
A: Removing that section.

2. Would like a stronger Security Considerations section, Wants it to say
     that that EPP "MUST NOT be used over a transport mechanism that does not
     provide confidentiality", or "All transport mappings for EPP..."
A: Incorporated. Clear text passwords are used, so privacy is required.

3. What is "authorization token"?
A: Changed to "authorization information" to be consistent with rest
of document.

4. Does EPP need the login/pass command if it is using TLS authentication?
A: Yes, TLS is using machine to machine authentication. user-level
authentication gives greater granularity. Some greater explanation is needed.

Scott Bradner:
1. More strict about congestion control protocols require an IETF
standards track congestion control such as TCP or SCTP.
A: Will address this later in response to another comment.

Bert:
1. example.tld is not an approved example.
A: Was not aware of the convention for example TLDs. They will be
changed appropriately.  What should be used for IPv6 examples?
Patrick Faltstrom: Will ask the IESG for guidance.

Randy:
1. Why is there no granular privacy options for domain/contact mappings.
A: Raised some discussion. Extensions allow policy to be codified on
a case-by-case basis. Needs to be discussed by the WG.

Allison:
1. <replacement text for managing congestion>
A: <will discuss later>

2. Define "marketing" add a more neutral definition.  More
explanatory material will be added (from P3P website or similar)

3. How does IESG and the community check XML (as opposed to ABNF or
MIB checking)
A: Available checkers from W3C etc.
PF: IESG may more thoroughly define this in the future, only just
implemented requirements on ABNF grammars.

4. Suggest that limiting the number of TCP connections is not a good
thing for net services. change MAY establish to SHOULD NOT. A server MAY limit
becomes SHOULD limit.

5. Missing TCP reference needs to be added

Discussion
----------
SH: Any problems with the suggested replacement text (from Allison 
Q4) that clients should not establish multiple tcp connections, and 
the server should limit connections.

Rick Wesson (RW): Ignores practices in common place

Jon Peterson (JP): ...

EL: This is used to address server load, not network load. This also 
has considerations for both.

JP: We might want to recast the sentence to consider that.

RW: It would be nice to have the actual language rather than the substitutions.

The wording as suggested on screen:

      An EPP client streams EPP commands to an EPP server on an
      established TCP connection.  A client MAY but SHOULD NOT establish
      multiple TCP connections to create multiple command exchange
      channels.  A server SHOULD limit a client to a maximum number
      of TCP connections based on server capabilities and operational
      load.

RW: Seems we are touching up language that ignores that operationally 
this happens (multiple connections) normally.

EL: SHOULD NOT helps convey that it is discouraged, and that
implementations shouldn't make this default behaviour.

Patrik Falstrom (PF): The definition for SHOULD NOT does not forbid
it if there is a justification.

RW: It is good to encourage clients not to do it.

JP: It contains a provision for clients and servers. If the server 
limits the number of concurrent connections it will persuade the 
clients not to.

PF: The client should not just open multiple connections without 
justification. The server can still reject the connections. The 
important reason for including the wording is that those claiming to 
the conformant to this RFC will only implement software with 
concurrent connections only when it is really
needed. I.e., Clients should reuse open TCP connections rather than open new
connections wherever possible.

<no more comments>

Transport Comments (congestion and reliability, Allison-1)
--------------------------------------------------
EL: This is the suggested wording from Allison. "The transport 
mapping MUST be onto a transport such as [..] and so forth".  The 
last part is a concern that SMTP runs over TCP, that the SMTP 
store-and-forward may drop transactions. The first part is that the 
Layer 4 connections don't impact the network.

PF: Also note, the second part, talks about SMTP/BEEP doesn't include 
any MUST or SHOULDs. This is a reminder for transport mapping 
authors, that they need to think about these issues and contain some 
wording on these matters.

EL: Any comments on the proposed text?

SH: Not advocating this position, but Eric B-W's comment was that his 
work on UDP transport would be affected by this.

PF: I suggest that because Eric brings up this issue, that the WG 
summarizes the issue that Eric has and pass it back to Allison. You 
could get Eric to do this. I don't think that the WG should declare 
rough consensus and ignore Eric's comments without consulting with 
Allison.

RW: When did Eric make this comment?

EL: In recent weeks, and I think it was alluded to in the SMTP draft.

SH: I think it was right after the IESG comments were sent to the list.

Simon ??: Many UDP protocols handle this like RPC implementations 
that do retries, back-offs etc. It should be in the transport 
mapping. We shouldn't
expect anything more from the transport ADs.

JP: I'm surprised by this. Is there some reason for using UDP?  Seems 
to be this is a real long-shot, and needn't go to Allison unless 
people think it is credible.

PF: My feeling in IESG discussions, is that the experience from the 
Transport ADs, that messages with one round trip (from SIP etc.) but 
as the protocol grows you implement retransmissions and back-off 
algorithms, so over and over again people who use UDP fails.

RW: I don't feel it is appropriate to do this over UDP. I think that 
without a draft on this we should just move on.

anon: Don't make it completely illegal though, some of the stuff I am 
doing is very lightweight, where if a connection fails it can just be 
retried. Other people are doing things with UDP that are illegal.

RW: More specific?

anon: says discussion is not on-topic for WG

EL: BEEP mapping failed because no-one wants to work on it as a 
group. We have new mappings coming in - do we want to work on those 
in this group?   Does the doc go out prohibiting UDP or just not 
mentioning UDP? We could just ignore datagram protocols, say 
something. I don't want to specify how to do this over a datagram.

I'm not sure how to approach this - leave it unmentioned? I'll talk 
with Patrick about that.

PF: Summarize the issue. See if people don't want it prohibited to do 
this kind of mapping, and then start a dialogue with Allison. I don't 
hear a clear consensus that doing UDP is completely stupid.

EL: I think we're done with this item.

SH: Are you going to take the action to coordinate this with Allison.

EL: Yes, it will go on in the minutes.

PF: Try to talk with her here.

(see the very end of the minutes for a comment from Allison as 
relayed by Patrick.)

Privacy comments
----------------
EL: The last of the major talking points in the IESG comments 
involves privacy. Allison had this specific comment regarding 
marketing purposes.  And then Randy's comments on privacy meta-data 
on a more granular level, down to objects
and aspects and so on, rather than the whole session. Where do we 
want to go with this?

SH: Lets begin with a little explanation on how we got here. Since 
the beginning, the topic of privacy came up 1-2 years ago, and a few 
folks proposed
a strawman proposal on granular privacy tagging - but it never came 
forward, so we went around in circles.

Instead, we punted to the extension mechanism in the protocol now - 
so specific privacy policies can be implemented with the extension 
mechanism.  So if email addresses are private, an extension could tag 
the element for this purpose.
There isn't a lot of text describing privacy and using extensions to implement
this, and we could do this if necessary - but the IESG did not ask 
for this, it asked for more specific privacy.

JP: In a P3P sense, it is clear cut how it is used. But in this B2B 
context, what does this mean for contacting for marketing purposes? 
What does it mean?

RW: In the context for the P3P sense, it only appears to be 
applicable for web pages. There doesn't seem to be any way to do 
this, it is an immature way to address the privacy issue. I don't 
know if what we have is extensible. I like that approach.  Different 
registries can develop policies. But putting a tag on each and every 
element seems like a simple way to solve a problem - but as we don't 
have any operational or policy sense on this, we have no way of 
knowing if it will work.

Rich Shockey (RS): I want to concur with Rick on this. The idea that 
privacy is associated with objects is a good idea. We dont have a 
standard to apply to the EPP objects at this stage. Last week in 
Dulles, VA, the W3C had a workshop on P3P on its applicability 
outside web pages. They do not have a work plan, or anything 
associated to present.  We could go down this road, but int he 
absence of any other technology (and I would assume the W3C will take 
years), as much as I'd like to see something implemented, I don't see 
how we could practically do it.

RW: Privacy is good. Some way of enhancing a registrants, or 
expressing that privacy, is good. I just want a mechanism that is 
more flexible and tested.

RS: I am in total agreement. This could delay the work by orders of magnitude.

EL: There are two types of granularity... Per-item and per-purpose.

SH: I was asked if I had any opinions. Personally, I think the 
protocol addresses this requirement. It allows us to move forward 
without putting restrictions on how it is defined in the future. The 
protocol still depends on the extension mechanism to define what 
private means. The document implies that you must  use the extension 
mechanism.

EL: One suggestion was that, and if you see Randy's comment, that the 
contact details are the ones needed privacy and maybe we only define 
it for those objects.

RW: If we have something that worked for all situations, we would appreciate it
if we could just take something and use someone else's work. We may 
not be qualified to do this kind of work.

JP: This is a common refrain, we had the same thoughts in geopriv. We 
have nothing there, and we don't have anywhere to go.

RS: That's funny, because we are looking to geopriv.

RW: It doesn't exist - are we the right people to develop it?  Should 
it be in the context of another group?

EL: Maybe we are the right place because we are one of the only 
places dealing with these matters.

RS: My personal suggestion would be the WG chairs ask the IESG for 
clarifications, with the comments we have no technical basis or 
competency to
tackle the issue.

EL: I want in the minutes that the P3P, where the documents come 
from, is a good document, but we're not sure is applicable.

RS: I am happy to post the results from the Dulles, Virginia, 
workshop, they are  working on this and cognizant of the limitations 
it has. There are companies that  are looking to do clever things 
with this. But is there a body of work to apply to provreg and EPP? 
No. When could we see one? God knows.

JP: IESG's comments suggestion seems to only be some tweaks - and 
that we are on the right track. Maybe we are doing a good job, and we 
shouldn't decide to
change focus and do something else entirely.

EL: ...

RW: We have not just the registrar-registry model, but we have 
reseller chains that must express this information and how it 
applies. It might be
somewhat clear in the simple R-R model. I believe there is a whole 
lot of work to be looked at here.

RS: This is a question on how the policy can be passed to 3rd and 4th 
parties in a chain of trust. To make it perfectly clear, if there was 
a way to do this
in a reasonable or rational way - we need a few proposals on how this could be
done without complicating the process too much. I think the extensions
proposals are the most reasonable way to do this.

EL: I do want to .. I'm not sure if we have to worry about. Right now
we are looking at the EPP protocol for R-R. Do we need to look at the 
EPP protocol from registrar to registrant? Does it need to be 
addressed now?

RW: If you are not talking about privacy, I agree we don't need to address it.

EL: Why is it special for privacy?

RW: It is the entity that is making the registration, so if you have 
reseller chains, in a privacy context, there is a lot of liability - 
countries,
laws etc. and it is not at all clear to me how it will work.

EL: I think we are done with the IESG comments. We have to discuss 
UDP, Privacy, etc. so we can't just rubber stamp it. But we have 
addressed most
comments apart from these few things.

SH: A request for clarification. Is there going to be a WG response 
to take back to the IESG? If we ask the IESG for clarification, then 
we have to rediscuss it here.

EL: I think we can have a mailing list discussion over the next 2-4 weeks.

SH: I would like to see some kind of position.

EL: Some new issues have come up. Passing information up and down. We 
could sit down and consider types of privacy.

RW: I would suggest we enumerate the kinds of things we have looked 
at. We shouldn't go down the road of defining privacy as it is too 
much work.

EL: Another comments is this doesn't apply as this is B2B.

SH: I think the P3P discussion, and privacy, are somewhat separate.

EL: I think based on the fact we have these small comments that we 
only need to make small changes.

SH: There is no indication we have got this completely wrong.  Who is 
going to make that happen? Our chairs?

EL: Our chairs.

RW: I volunteer..

EL: We have two things to think about - UDP and privacy.

2.5 other issues with the base 10m

      Last-Verified and External Hosts
      (Presentation attached.)

RW: Several weeks ago, a number of groups have an issue with WHOIS. 
-quality assurance In the context of registrant data.. one being the 
postal element, on how it can change - not in the db, but in the real 
world. Such as change
of a zip code or reassignment of a street address. PSTN elements 
change over time too - phone numbers get remapped. It is happening in 
India at the
moment, where the length of numbers are getting changed. In the US, 
Area codes changes. If we had a registration 10yrs ago in the LA 
area, and the area code
would be remapped and would change. Then the data in our systems isn't being
remapped or changed.  I advocate a position where we identify the 
time since a contact acknowledged that they have accurate and correct 
information.

The proposal is for a last-verified-date, since the registrant ack'd 
the data is accurate. It would be optional in EPP for the contact.

Comments?

<none>

EL: OK. On the mailing list, the last message on this talked about 
this being optional. Not everyone agreed that all registries. So this 
is the question i am most interested in. Should it be optional?

RW: From the comments i have received it makes the most sense.

JP: It doesn't seem to make any sense to make it mandatory. There are 
all kinds of bad things about it.

SH: I agree, it seems appropriate. The last comment was more strong 
that it should not be in the base, but i agree with RW on this.

RS: Ditto.

EL: We have documents in from of the IESG and I am not sure if we
want to make a change at this stage.

RW: The IESG knows about this.

      External Hosts

EL: The other item is the external host, external objects.

SH: OK, here is another can of worms that was discussed in great 
details 1-2 years ago. TO set the stage. We have an issue with 
repositories being
authoritative for objects in other repositories. i.e. Hosts being used as
nameservers, being renumbered etc. This causes management issues if 
the entity that owns the host doesn't sponsor the object in the 
registry. An alternative
proposal was that each client sponsored its own copy of these objects, allowing
each client to manage their own. Hopefully there was no restrictions 
on this, prevents hi-jacking. It allows for bulk updates, you change 
one objects and
it percolates through all objects that are associated. This is something we
need to resolve before we move forward.

JP: I am not sure about this issue. I can't speak for Hong.

SH: Hong's objections were this per-client copy, but instead these 
sorts of objects are managed by the server. I don't like the owner 
word, I forget
what the arguments against what that were - it seems rational. If we assume no
objects belong in the registry if they are not authoritative, we can 
throw out these objects and make nameservers attributes of the domain 
objects. This has
problems with bulk updates.

EL: The fear is that using the same nameserver for a lot of zones, 
that would mean a lot of changes if I change nameservers.

RW: We have to do it one way or the other, and each has consequences. 
I think we have made a decision and it is a good choice.  We have a 
significant amount of operational experience about this choice. I 
have not heard significant comment about this apart from Hong.

EL: Any other comments on the base specification, outside the IESG 
and our current discussions?

EL: Next on our agenda is a transport mapping on SOAP. Hong is not 
here so Jon Peterson will present on that.

EPP/SOAP
--------

(presentation attached)

JP: My slide is what i believe are the issues with the draft. Why 
would you want to implement this? SOAP is more widely deployed, so it 
may be easier to use a SOAP envelope to talk EPP. You need to define 
a small amount of persistent session data inside the SOAP header. It 
is relatively straight forward. There are some issues that were 
discussed on the list that are unyet resolved. These are error codes, 
do we want to construct actual transport protocols used by soap, and 
how does this draft fit with existing deliverables of the provreg 
charter. Is this charter work? Does the initial charter of provreg 
consider this appropriate. Is SOAP perceived to be valuable?

RW: Is soap an actual transport? It is a layer of indirection. There 
are a number of bindings defined to another protocols but it is not 
an L4 transport.

Andrew Newton (AN): One of the motivations of using SOAP is that 
abstracts you from the transport, and you can use any number - but 
are there any non-TCP transports?

JP: I'd be surprised if there isn't.

AN: No there isn't one.

RW: What is the status of the draft?  Informational or Standards 
Track? If Info.  I think this is great. I am a SOAP implementor and I 
think it sucks. But that is just the state of affairs today.

EL: Hong has written this and he would like it as a WG item.  That 
would mean the WG takes over. If we think this is just a cool idea 
for Hong to work on, that is fine.  The charter does say we should 
look at transport mappings.  It is perfectly OK for the group to say 
yes we love this idea - we could do that - and it could be standards 
track. I'm not saying that we have 4 people who would love to do this.

AN: SOAP is not a transport. Some people see this as a magic answer 
that would solve all their problems. This has happened with other RPC 
protocols.

Leslie Daigle: If you want to discuss using SOAP, you should come up 
with architectural reasons for going there.

EL: Yes that is an important question.. "Why?" Why are we doing this?

JP: Given how minimal the mechanism is, this is something I am here 
to ask what the WG thinks.

EL: We have already thrown out BEEP mapping because no-one else 
wanted to work on it.  There was nothing wrong with the proposal - it 
was not mature - but its proponents didn't pursue it any further. The 
problem is we had not consensus there.

RW: To answer some of Leslie's question. This is exactly why BEEP 
didn't work. We didn't have the tools or constituency. Right now, the 
fastest way to deploy the service (as long as you don't want too many 
people to use it) is to use SOAP.

EL: If we are talking about EPP, we are going to layer requirements 
on the transport.  With SOAP being this general, how can the document 
address all the transport layers.

RW: We should have a set of requirements that the SOAP transport must 
use. Just like the TLS over TCP.

JP: I think Rick is correct with the SOAP approach. We would rely on 
profiling on constraining you to particular transports.

EL: Does this have promise? Might this be an interesting thing? Do we 
want this in the charter?

(yes)

EL: Who would implement this?

PF: Including specific requirements all the way down the stack to IP 
- i.e. not just using HTTP.

RW: There has been no analysis.

EL: If we invite this into the WG we will start working on it. I want 
to make sure before we do this. Before we do this, I want to see 
sufficient well-spread interest in this.  If only 1 person wants to 
do this, they can experiment all they want without WG involvement.

PF: I agree with your concerns concerning new bindings. Regarding 
whether the transport binding is part of the charter. I will require 
a review by the WG or
mailing list if the WG doesn't exist.  The mailing list can not go 
away if the WG dies. I hope the WG winds up within 6 months. You will 
still do the review, it doesn't need to be in the charter. 
Milestones/Deliverables need to change.

RS: The document can independently proceed, and the IESG reviews it?

PF: Exactly. It wont be stopped by the WG if it is not in the 
deliverables. The WG/ML will still need to review it.

EL: The IETF will not get in the way of this. I'm not saying that we 
are going to kill this by not putting it in the WG. What I am after 
is how many people are willing to commit time and resources that 
would indicate it should be a WG item?

RW: If you're looking for low hanging fruit for a second transport 
implementation, this is it. For me to implement this would take all 
of a day. It is just not a big deal.

JP: Just one thing about that - i think it is a reasonable barrier to 
entry to insist on finding a few implementors to make it a WG item. I 
think this is the
wrong forum to ask this question.

EL: This will go to the mailing list.

PF: One thing, BTW, I take the constraint of transport protocols as 
an action item.

JP: I definitely think it should not be characterized as a L4 protocol.

EL: The other item on the agenda, is the SMTP draft. This is an case 
of why my (as chair) skepticism towards new documents has been rising 
over the years.  People have said they are all for an SMTP transport, 
with 3-4 volunteers.  Finally someone wrote a document. Further 
discussion has not happened as the author is unavailable at this 
time. SMTP is something people have liked over time.  Are there 
people who would like to implement SMTP transport?

OK, No hands showing here.  This will go back to the ML, but it could 
be we don't pursue this.  Anyone think this is a great loss?

No. Ok. We may ask to remove a milestone. We only have that and one 
other milestone.

EL: Next item on the agenda is the only other WG document we have, 
that Scott has, the guidelines for extending EPP. I would like to see 
this document mature
very quickly.

(Side note: We also need to discuss the milestones, some have been 
done and subsequently dropped.)

SH: This doc was first published a few months ago, as a result of 
some screwy ways of extending the protocol in some independent 
documents. The only
comments I have received is from Ed, there has been very little 
discussion otherwise. I wanted some WG discussion before implementing 
those comments.

RW: This is the part where we talk about other docs?

EL: I'd like to talk about the guidelines first?

EL: The intent here is to give people a leg-up on extending EPP. The 
idea came up about a year ago. How many people are implementors in 
this room?  OK, so it is the minority here. So in this case it is 
best discussed on this list.

EL: Ok, other documents.

RW: I wanted to find out if there was interest in writing a BCP for 
domain registries over EPP. Is this a good idea? It would be an 
individual submission. It doesn't have to be a WG item. ... Sounds 
like a resounding no.

EL: Yeah I think it is not a WG item, but that doesn't stop you.

EL: Next item is discussion on the future of the WG. It seems to me 
there are some things still to work on. The IESG comments will 
require a little bit of
work, the SOAP is a consideration with more than 1 implementor in the room will
want to take a look at, and we'll ask for input from the ML. That 
could wind up as another item. It sounds like SMTP will be tabled 
indefinitely or killed, not for the lack of interest but no need to 
implement/interoperate. So, the extensions guidelines draft which 
shouldn't be controversial, the IESG comments, and the SOAP draft - 
and I think that is pretty much it.  If there isn't anything else, we 
can close the meeting. I would like to get copies of the slides.

PF: Wait - I was just looking for Allison. I asked her about UDP.
Her experience has shown those using UDP do broken thing, so they 
want to ban UDP. So that is the message back from Allison. So you 
need to make some kind of statement and engage in discussion with the 
transport.

EL: I might make a post to the ML that we will outlaw UDP, and see 
what kind of flames we get.

PF: I think we will also have a discussion within the IESG, if this 
kind of requirement exists there needs to be some kind of statement.

EL: OK, so I think we're done.

Meeting Ends
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

--============_-1172544961==_============
Content-Id: <a05111b00ba1c37df11b6@[192.149.252.235].0.0>
Content-Type: application/pdf; name="last-verified-provreg-ietf55.#0"
 ; x-mac-type="50444620"
 ; x-mac-creator="4341524F"
Content-Disposition: attachment; filename="last-verified-provreg-ietf55.#0"
Content-Transfer-Encoding: base64

--============_-1172544961==_============
Content-Id: <a05111b00ba1c37df11b6@[192.149.252.235].0.1>
Content-Type: application/vnd.ms-powerpoint; name="provreg55th.ppt"
 ; x-mac-type="534C4433"
 ; x-mac-creator="50505433"
Content-Disposition: attachment; filename="provreg55th.ppt"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAIAAA
AAAAAAAAEAAAIwAAAAEAAAD+////AAAAACEAAAD/////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
///9////GgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAABsAAAD+
////GQAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAD+////
/v////7///8cAAAAHQAAAB4AAAAfAAAA/v//////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
--============_-1172544961==_============--

To: Michael Graff <[email-masked]>
Cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: EPP statuses and other questions
From: Michael Graff <[email-masked]>
Date: 10 Dec 2002 23:53:30 +0000
Lines: 72
Sender: [email-masked]

Add to this list:

(7)  Although ROIDs are used to specify what object the password is
     associated with in a <authinfo roid="foo-BAR">, there is no way to ADD
     an external foo-BAR to the list of contacts for a domain!

I restate that ROIDs and the whole concept of inter-registry linkage
is a very poorly thought out issue, and should be scrapped from EPP
documents ASAP.  It adds complications for initial implementations,
and from my point of view adds no benefits to any implementation until
the concept is better thought out.

I know there are pressures to get the EPP draft to the next stage, but
this one issue is a serious sticking point that IMHO will cause us to
be unable to properly handle a workable inter-registry linkage in the
future.

--Michael

Michael Graff <[email-masked]> writes:

> And after reading much more, I feel the mistake is that there are two
> handles for objects now, and that is becomming a pain in trying to
> implement EPP.
> 
> (0)  ROIDs are not well thought out, nor well integrated into the 07
>      draft at least.
> 
> (1)  A handle (like FOO1-ISC) is not self-describing.  Is that a contact
>      handle, a domain handle, or what?
> 
> (2)  Part of the handle namespace is client-chosen, part is registry-chosen.
>      On contacts, the local (and thus the global) identifiers are chosen
>      by the registrant, where domain and other ROIDs are chosen by the
>      registry.  This means the registry cannot fix (1) easily.
> 
>      Example:  Suppose a contact, "FLAME1" is created, and assigned
>      ROID of FLAME1-ISC.  Now, later, that contact is deleted.
>      Suppose a domain is created, "FLAME.ORG", and it is 
>      assigned the ROID of "FLAME1-ISC".  Now, that is no longer a
>      valid contact ROID.  All external references will be totally
>      confused.  WORSE, since domains and contacts can have passwords,
>      would:
> 
>         <authinfo roid="FLAME1-ISC">password</authinfo>
> 
>      allow me to modify other domains?  After all, FLAME1-ISC may be
>      listed as an external technical contact for FOO.COM, and I can
>      get the password right for the domain-versio of FLAME1-ISC.
> 
> (3)  The various <create> commands need to return the ROID an object was
>      assigned.  As things are now, I need to look up the contact using
>      <info> before I can use it in an <authinfo roid="whatever"> tag.
> 
> (4)  Using two names, one which is (in the contact case) derrived from the
>      other, seems pretty silly.  If you're going to do that, use only the
>      global (or use the URN concept to refer to external data,
>      mentioned in the mail archives and in my last post.)
> 
> (5)  The -FOO suffix doesn't really fit with the new world order of
>      URIs, URNs, and is different than how XML, the EPP protocol of
>      choice (yuck) would do it.
> 
> (6)  EPP is extensible.  Once other issues, such as how to notify
>      referrers of data, or even a good use for this sort of thing is
>      found, a draft can be written to extend EPP to handle
>      registry-side ROIDs.  Until then, I at least feel they complicate
>      an already complicated protocol, and should be removed for now.
>      Additionally, making it OPTIONAL gives the registry more
>      flexability into if it WANTS external references or not.
> 
> --Michael

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Hong Liu'" <[email-masked]>, [email-masked]
Subject: RE: EPP Compliance (Was Re: lastVerified: optional vs. extension)
Date: Tue, 10 Dec 2002 08:43:40 -0500
Sender: [email-masked]

> So what does it mean by implementing EPP standards by
> IETF for domain registries? Does it mean that it
> _must_ implement the following EPP "core" documents as
> is when they become RFCs?
> 
> - EPP base
> - Domain mapping
> - Contact mapping
> - Host mapping
> - TCP mapping (???)
> 
> Of course this is the minimum set of specifications.
> One can always implement additional features as
> extensions to domain/contact/host objects. 
> 
> [I don't know if TCP mapping should be included in the
> minimum set or not.]

Right now the only documents the IESG is considering for publication as
proposed standards are those that are in the WG document set as listed
above.  If a registry claims conformance to the _IETF_ standards for EPP,
the WG documents are the only documents involved.  As of right now the WG
set includes the TCP mapping document, but that could change if some other
transport document is ever completed.

It's also possible that another organization like OASIS could develop EPP
object mappings, and someone could claim to conform to the OASIS EPP
specifications.  That's cool, we have extensibility to allow this sort of
thing.  This does leave the door open for someone to develop a similar
mapping that's just different enough to prevent interoperability.  In the
ICANN world this could be resolved by negotiating requirements with
registries and registrars to conform to one set of specifications over any
other specifications to avoid interoperability issues.

-Scott-

Date: Tue, 10 Dec 2002 05:12:22 -0800 (PST)
From: Hong Liu <[email-masked]>
Subject: RE: EPP Compliance (Was Re: lastVerified: optional vs. extension)
To: [email-masked]
Sender: [email-masked]

Scott,

Thanks for the comments. I agree with your points. I
just want to validate them on the list. I think that
goes a long way to clarifying mis-conceptions that
some people may claim. 

So what does it mean by implementing EPP standards by
IETF for domain registries? Does it mean that it
_must_ implement the following EPP "core" documents as
is when they become RFCs?

- EPP base
- Domain mapping
- Contact mapping
- Host mapping
- TCP mapping (???)

Of course this is the minimum set of specifications.
One can always implement additional features as
extensions to domain/contact/host objects. 

[I don't know if TCP mapping should be included in the
minimum set or not.]

--Hong

--- "Hollenbeck, Scott" <[email-masked]>
wrote:
> > This discussion warrants a separate thread since I
> > believe it begs a clear answer to a fundamental
> > question: what does it mean by EPP compliance, in
> the
> > context of domain name registrations?
> 
> I'm not sure that the term "EPP compliance" has
> _any_ meaning.  Once we have
> RFCs it will be possible for implementations to
> claim conformance with EPP
> RFCs xxxx, yyyy, zzzz, etc., but that claim will
> have to be tied to the
> RFCs.  An implementation can conform to the core and
> transport RFCs, and it
> might conform to some other domain mapping
> specification if one is ever
> published by someone else.  In my mind, conformance
> is a measure of
> implementation adherence to some published
> specification(s), and we can't
> stop someone from trying to write their own
> specifications outside of the
> IETF.
> 
> > For example, can another domain mapping, which is
> 95%
> > the same with the current document, but with 5%
> > differences (not through extension, but via
> > modification), claim that it is EPP compliant for
> > domain registration? I would not think so, but I
> would
> > like to hear what the WG think.
> 
> Such a document could claim to be a valid EPP
> mapping.  One could also claim
> that an implementation of that mapping conforms to
> whatever RFCs the core
> and transport specifications are eventually
> published as.  One could not
> claim, however, that it conforms to whatever RFC the
> WG domain mapping is
> published as.  It might conform to the deviant
> domain mapping, but that's
> all.
> 
> -Scott-

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

Date: Tue, 10 Dec 2002 12:45:07 +0100
From: Stephane Bortzmeyer <[email-masked]>
To: Rick Wesson <[email-masked]>
Cc: Hong Liu <[email-masked]>, [email-masked]
Subject: Re: lastVerified: optional vs. extension
Organization: NIC France
Sender: [email-masked]

On Mon, Dec 09, 2002 at 08:39:19AM -0800,
 Rick Wesson <[email-masked]> wrote 
 a message of 36 lines which said:

> it sounds like you are policy adverse and have a preconceived notion on
> how Neulevel would handle the policy. Since your organization is lobbing
> the USG for .kids.us I am sure you have been involved in some policy
> development.

On an IETF mailing list, people are supposed to stand for themselves,
not for their company. Although this is wishful-thinking, in practice,
nobody criticized Scott's proposal on the basis of Verisign policy or
my remarks on the basis of AFNIC's policy. I suggest to continue that
way.
 
> What appears to be happening is that some registry operators are more
> concerned about the inconvenience of "public service" than publishing and
> ensuring accurate information within their data sets.
> 
> Are you are advocating the publishing of inaccurate information as a BCP
> as long as there is no way of knowing if the information is accurate or
> not? And that adding a mechanism like last-verified-date would require
> that some registry operators acknowledge that there is a problem?

As shown in your diatribe, this is clearly a registry policy issue,
outside of the scope of the WG.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Hong Liu'" <[email-masked]>, [email-masked]
Subject: RE: EPP Compliance (Was Re: lastVerified: optional vs. extension)
Date: Mon, 9 Dec 2002 16:00:09 -0500 
Sender: [email-masked]

> This discussion warrants a separate thread since I
> believe it begs a clear answer to a fundamental
> question: what does it mean by EPP compliance, in the
> context of domain name registrations?

I'm not sure that the term "EPP compliance" has _any_ meaning.  Once we have
RFCs it will be possible for implementations to claim conformance with EPP
RFCs xxxx, yyyy, zzzz, etc., but that claim will have to be tied to the
RFCs.  An implementation can conform to the core and transport RFCs, and it
might conform to some other domain mapping specification if one is ever
published by someone else.  In my mind, conformance is a measure of
implementation adherence to some published specification(s), and we can't
stop someone from trying to write their own specifications outside of the
IETF.

> For example, can another domain mapping, which is 95%
> the same with the current document, but with 5%
> differences (not through extension, but via
> modification), claim that it is EPP compliant for
> domain registration? I would not think so, but I would
> like to hear what the WG think.

Such a document could claim to be a valid EPP mapping.  One could also claim
that an implementation of that mapping conforms to whatever RFCs the core
and transport specifications are eventually published as.  One could not
claim, however, that it conforms to whatever RFC the WG domain mapping is
published as.  It might conform to the deviant domain mapping, but that's
all.

-Scott-

Date: Mon, 9 Dec 2002 12:02:28 -0800 (PST)
From: Hong Liu <[email-masked]>
Subject: EPP Compliance (Was Re: lastVerified: optional vs. extension)
To: [email-masked]
Sender: [email-masked]

Ed, Scott,

This discussion warrants a separate thread since I
believe it begs a clear answer to a fundamental
question: what does it mean by EPP compliance, in the
context of domain name registrations?

While the beauty of EPP is that it applies to many
different types of registries, it has to be a standard
set of extensions for a particular type of registries,
such as domain name registries. Or why bother spending
all the time producing the domain/contact/host mapping
documents to RFCs?

For example, can another domain mapping, which is 95%
the same with the current document, but with 5%
differences (not through extension, but via
modification), claim that it is EPP compliant for
domain registration? I would not think so, but I would
like to hear what the WG think.

Cheers,

--Hong
 
--- Joe Abley <[email-masked]> wrote:
> 
> On Friday, Dec 6, 2002, at 07:46 Canada/Eastern,
> Hollenbeck, Scott 
> wrote:
> 
> >> We already have a lot of registry-specific and
> inflexible
> >> stuff in EPP, mostly,
> >> but not limited to, the handling of name servers.
> EPP is
> >> clearly designed after
> >> Network Solution's registry model (before they
> were forced to
> >> open the registry
> >> to others), which is far from being generic or
> prototypical
> >> for the existing
> >> ccTLDs around the world.
> >
> > If this were true and the model were not of more
> general interest other
> > members of the WG would have shot it down long
> ago.
> 
> It is also important to remember that the domain and
> nameserver mapping 
> documents are extensions to the base protocol, and
> not integral to it. 
> There is nothing to stop a registry for whom the
> current documents are 
> not a good match from writing their own mapping
> documents that better 
> suit their purposes.
> 
> 
> Joe
> 

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

Date: Mon, 9 Dec 2002 08:39:19 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: Hong Liu <[email-masked]>
cc: <[email-masked]>
Subject: RE: lastVerified: optional vs. extension
Sender: [email-masked]

Hong,

> As I explained in another email, even from a technical perspective,
> adding this element is not as trivial as you described above. I would
> not repeat why it is different than "fax" here.

it sounds like you are policy adverse and have a preconceived notion on
how Neulevel would handle the policy. Since your organization is lobbing
the USG for .kids.us I am sure you have been involved in some policy
development.

> If it is in the base protocol, all registries will have to deal with
> it, whether they support it or not, in order to be EPP compliant. The
> business logic for registry policy will be driven down to the element
> level. We should try to avoid such design if we have an alternative.

Are you suggesting all registries do not have old, stale and out dated
registrant contact data and that end-users should not have access to the
accuracy of the data and that this should not be in the base protocol?

What appears to be happening is that some registry operators are more
concerned about the inconvenience of "public service" than publishing and
ensuring accurate information within their data sets.

Are you are advocating the publishing of inaccurate information as a BCP
as long as there is no way of knowing if the information is accurate or
not? And that adding a mechanism like last-verified-date would require
that some registry operators acknowledge that there is a problem?

-rick

Date: Mon, 09 Dec 2002 11:22:44 -0500
From: janusz sienkiewicz <[email-masked]>
Organization: LibertyRMS Co.
To: Rick Wesson <[email-masked]>
CC: Hong Liu <[email-masked]>, "[email-masked]'" <[email-masked]>, Ram Mohan <[email-masked]>
Subject: Re: lastVerified: optional vs. extension
Sender: [email-masked]

Significant changes in this case mean pieces of text that explain how relevant
epp commands and responses should handle lvDate element.

Regards,

Janusz Sienkiewicz

Rick Wesson wrote:

> On Mon, 9 Dec 2002, janusz sienkiewicz wrote:
>
> > I agree with Hong.
> > >From XML schema point of view, adding lvDate element looks like a simple
> > change (as complex as the fax element). From the implementation point of
> > view it is not that simple.  Significant changes may be required to EPP
> > object mapping documents.
>
> could you list the "significant changes" that may be required to EPP? as
> the statement above is tratitionally called hand-waving, you'll need to
> back yous statement up with some examples.
>
> -rick

Date: Mon, 09 Dec 2002 17:12:14 +0100
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: lastVerified: optional vs. extension
Sender: [email-masked]

Hollenbeck, Scott wrote:

> That message doesn't mention the bulk update issue at all, though
> in the thread that follows other folks note some issues with how the model
> makes it difficult to maintain consistent data views across all involved
> parties.

If anyone who has understood this model is unable to imagine how consistency is 
maintained should feel free to contact me off the list. As I said earlier, I 
don't think it make sense to discuss this any further here on the list.

> I think Jordyn summed up the situation quite nicely with the last
> sentence of this message:
> 
> http://www.cafax.se/ietf-provreg/maillist/2001-08/msg00119.html
> 
> "There are reasonable arguments on both sides of this debate, and no
> fool-proof solution has been presented that solves all of the issues
> raised."

Yes, let us close with this beautiful sentence having this nearly non-sensible 
whiff of "get lost, we've already made our decisions", which I complied with then.

> I'm done.
> -Scott-

So am I.

regards,

Klaus

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

Date: Mon, 9 Dec 2002 08:08:31 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: janusz sienkiewicz <[email-masked]>
cc: Hong Liu <[email-masked]>, "[email-masked]'" <[email-masked]>, Ram Mohan <[email-masked]>
Subject: Re: lastVerified: optional vs. extension
Sender: [email-masked]

On Mon, 9 Dec 2002, janusz sienkiewicz wrote:

> I agree with Hong.
> >From XML schema point of view, adding lvDate element looks like a simple
> change (as complex as the fax element). From the implementation point of
> view it is not that simple.  Significant changes may be required to EPP
> object mapping documents.

could you list the "significant changes" that may be required to EPP? as
the statement above is tratitionally called hand-waving, you'll need to
back yous statement up with some examples.

-rick

Date: Mon, 09 Dec 2002 11:04:16 -0500
From: janusz sienkiewicz <[email-masked]>
Organization: LibertyRMS Co.
To: Hong Liu <[email-masked]>
CC: [email-masked]
Subject: Re: lastVerified: optional vs. extension
Sender: [email-masked]

I agree with Hong.
>From XML schema point of view, adding lvDate element looks like a simple
change (as complex as the fax element). From the implementation point of
view it is not that simple.  Significant changes may be required to EPP
object mapping documents.

Treating the feature as an EPP extension seems to be a reasonable way to
go.

Regards,

Janusz Sienkiewicz

Hong Liu wrote:

> Rick,
>
> Please see my comments in line.
>
> Cheers,
>
> --Hong
>
> --- Rick Wesson <[email-masked]> wrote:
> > On Fri, 6 Dec 2002, Hong Liu wrote:
> >
> > > I concur with Scott's observation. I would say
> > that
> > > extension seems to be the way to go for
> > lastVerified.
> >
> >
> > Hong,
> >
> > My proposal was to have the follwoing XML in the
> > contact-1.0.xsd:
> >
> >   <complexType name="infDataType">
> > ...
> >       <element name="lvDate" type="dateTime"
> > minOccurs="0"/>
> > ...
> >   </complexType>
> >
> > You have advocated an extention. prposal is as
> > complex as the "fax"
> > element. Registries can express this critical value
> > that many
> > organizations are asking for or they may not.
> >
> As I explained in another email, even from a technical
> perspective, adding this element is not as trivial as
> you described above. I would not repeat why it is
> different than "fax" here.
>
> If it is in the base protocol, all registries will
> have to deal with it, whether they support it or not,
> in order to be EPP compliant. The business logic for
> registry policy will be driven down to the element
> level. We should try to avoid such design if we have
> an alternative.
>
> > Why do you prefer to add the burdon of an extention
> > whic is much more
> > vobers, requireing name space negoiation by the
> > server and extion
> > libraries for the client to address this ICANN and
> > IESG issue?
> >
> That is exactly the beauty of extension, and XML
> namespace separation. The server makes it explicit in
> terms of what namespaces it supports at session
> negotiation. XML parsing will fail right away if a
> client uses a namespace that the server does not
> support. The server business logic is a lot cleaner
> than handling it at the element level.
>
> Most importantly, we don't know whether the element by
> itself is sufficient for different policies to be set
> up. It is premature to incorporate it in the base EPP
> spec. What if different registries collect different
> data for the same purpose? Then you need to use
> extension anyway.
>
> >
> > -rick
> >
> >
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>
Cc: [email-masked]
Subject: RE: lastVerified: optional vs. extension
Date: Mon, 9 Dec 2002 10:15:24 -0500 
Sender: [email-masked]

> > 
> > Sorry, but I don't remember you suggesting anything other 
> than the .de
> > model, and I don't recall you ever addressing how that 
> model deals with bulk
> > updates efficiently.  If you did, would you please point me 
> to your proposal
> > in the list archives?
> > 
> 
> for example:
>    http://www.cafax.se/ietf-provreg/maillist/2001-08/msg00018.html

Thanks for refreshing my memory -- I was a bit confused between the .de
model and the minor differences you pointed out at the bottom of your
message.  That message doesn't mention the bulk update issue at all, though
in the thread that follows other folks note some issues with how the model
makes it difficult to maintain consistent data views across all involved
parties.  I think Jordyn summed up the situation quite nicely with the last
sentence of this message:

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

"There are reasonable arguments on both sides of this debate, and no
fool-proof solution has been presented that solves all of the issues
raised."

I'm done.

-Scott-

From: "Gould, James" <[email-masked]>
To: "'Stephane Bortzmeyer'" <[email-masked]>, Joe Abley <[email-masked]>
Cc: [email-masked]
Subject: RE: Standard mappings hardwired in EPP servers? (Was: lastVerifie d: optional vs. extension
Date: Mon, 9 Dec 2002 10:02:02 -0500 
Sender: [email-masked]

Stephane,

As an implementer I have to say that hard coding the "standard" mappings
with the server is extremely poor design and supporting new EPP
mappings/extensions can be easily made pluggable.  All that is needed is one
factory class per namespace along with a pluggable handler.  I've personally
implemented multiple EPP registries with the "standard" mappings and with
custom mappings/extensions, and none of them required modifying the core
server code.  

Jim    

-----Original Message-----
From: Stephane Bortzmeyer [mailto:[email-masked]]
Sent: Monday, December 09, 2002 4:58 AM
To: Joe Abley
Cc: [email-masked]
Subject: Standard mappings hardwired in EPP servers? (Was: lastVerified:
optional vs. extension

On Fri, Dec 06, 2002 at 10:59:11AM -0500,
 Joe Abley <[email-masked]> wrote 
 a message of 25 lines which said:

> It is also important to remember that the domain and nameserver mapping 
> documents are extensions to the base protocol, and not integral to it. 
> There is nothing to stop a registry for whom the current documents are 
> not a good match from writing their own mapping documents that better 
> suit their purposes.

Yes, but this could be a nightmare for the implementor of the EPP
server: if you distribute a shrink-wrapped server (wether free
software or closed), you need some sort of plug-in mechanism in the
server in order to support "alternative" mappings. It is not obvious
to realize. (/etc/epp.conf contains a relationship of
extension->module/class to load? And the registry develops the local
modules/classes?)

Let's try: how many EPP servers (whatever their legal status) have the
"standard" mappings hardwired in the code? I assume "all".

It is also a problem for the registrars: if you interact with several
registries and they use different EPP mappings, you lose a part of the
reason to have a standard protocol...

Date: Mon, 09 Dec 2002 14:42:04 +0100
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: lastVerified: optional vs. extension
Sender: [email-masked]

> 
> Sorry, but I don't remember you suggesting anything other than the .de
> model, and I don't recall you ever addressing how that model deals with bulk
> updates efficiently.  If you did, would you please point me to your proposal
> in the list archives?
> 

for example:
   http://www.cafax.se/ietf-provreg/maillist/2001-08/msg00018.html

> 
> Mow I'm getting even more confused.  We've gone from the provisioning
> perspective to the DNS resolution perspective, and as far as I'm concerned
> those perspectives are independent.  The provisioning system just needs to
> ensure that the information needed by the resolution system is available for
> proper deployment.
> 

Glueing the host records to the domain they belong to (regarding the DNS 
hierarchy) is IMHO not a provisioning requirement.

> BTW, EPP's host model does very clearly provide guidance to prevent cycles
> (though I'm not sure of what you mean by "cycles") involving out-of-zone
> hosts.  From section 2.5 of the current host mapping:
> 

Sorry for "cycles". Unfortunately, we don't have a short term for that cyclic 
nonresolvable dependency problem between two or more domains and their name 
servers, e.g. a.com -> ns.b.com, b.com -> ns.a.com.

I never said that EPP would not have prevention of those cycles if all hosts are 
in-zone.

 > [...]
> -Scott-

regards,

Klaus

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>
Cc: [email-masked]
Subject: RE: lastVerified: optional vs. extension
Date: Mon, 9 Dec 2002 07:51:42 -0500 
Sender: [email-masked]

> I'm not aware of any question that I left unanswered. In 
> addition, you mix up my 
> model and DENIC's current one. I once suggested a model that 
> has the flexibility 
> of DENIC (anyone can specify any name server, no separate 
> relational model for 
> in-zone and out-of-zone hosts) while having host objects. 
> Both models allow the 
> change of IP addresses of hosts used by multiple domains in a 
> single request. My 
> model additionally allows to even change the name of a host 
> used as a name 
> server in multiple domains in a single request.

Sorry, but I don't remember you suggesting anything other than the .de
model, and I don't recall you ever addressing how that model deals with bulk
updates efficiently.  If you did, would you please point me to your proposal
in the list archives?

> My model has a drawback regarding potential in-zone host name 
> resolution cycles, 
> but this problem is IMHO heavily overestimated and can be 
> handled during zone 
> file generation. A quick analyses of our domains shows that 
> nearly none of our 
> .info and .biz domains and only 2% of our .org domains fully 
> rely on in-zone 
> hosts. Even our com/net domains have a rate of less than 50%. 
> This is surely not 
> representative, and I expect that ccTLDs have a much higher 
> rate > 95%. So 
> depending on the registry, EPP's host model, where cycles 
> involving out-of-zone 
> hosts are not prevented, has little benefit to the 
> operativeness of the DNS. If 
> one takes the abilities of misconfigurations into account 
> which are fully 
> ignored by the current gTLD registries (contrary to many 
> ccTLDs), this makes 
> even less sense.

Mow I'm getting even more confused.  We've gone from the provisioning
perspective to the DNS resolution perspective, and as far as I'm concerned
those perspectives are independent.  The provisioning system just needs to
ensure that the information needed by the resolution system is available for
proper deployment.

BTW, EPP's host model does very clearly provide guidance to prevent cycles
(though I'm not sure of what you mean by "cycles") involving out-of-zone
hosts.  From section 2.5 of the current host mapping:

"When a host object is provisioned for use as a DNS name server, IP
addresses SHOULD be required only as needed to generate DNS glue records."

> Everything above I wrote at least once to the list and I 
> don't want to discuss 
> this in detail any longer. You said in a recent e-mail, that 
> you don't want to 
> make fundamential changes to the protocol at this point of 
> progress, which is 
> understandable to me. So if I ever have to use EPP on server 
> side, I'm going to 
> maltreat it until it fits my needs, whether it is 
> recognizable as EPP afterwards 
> or not.

No, I said I as document editor _can't_ make fundamental changes on my own
because of where we are in the document review process.  We've certainly
been over this ground many, many times in the past, but the IETF process
includes provisions to reconsider approaches if and when implementation
experience demonstrates flaws.  The process has a built-in mechanism to deal
with this situation in the way documents progress (or not) from proposed
standard to draft standard status.

I don't really care to continue discussing issues that the WG has dealt with
in the past, either, unless significant new information is somehow made
available.  I'm not the one who brought this particular topic up again in
the first place, though. ;-)

-Scott-

Date: Mon, 09 Dec 2002 13:07:15 +0100
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: lastVerified: optional vs. extension
Sender: [email-masked]

Hollenbeck, Scott wrote:

> 
> I (and again, others -- check the archives) continue to disagree with your
> assertions of model deficiency, and when we pointed out the issues with
> _your_ model (like the bulk update problem) you typically failed to respond.
> That's not a sign of not trying to understand -- if anything, it's a clear
> sign of trying to explore all of the issues in necessary detail.

I'm not aware of any question that I left unanswered. In addition, you mix up my 
model and DENIC's current one. I once suggested a model that has the flexibility 
of DENIC (anyone can specify any name server, no separate relational model for 
in-zone and out-of-zone hosts) while having host objects. Both models allow the 
change of IP addresses of hosts used by multiple domains in a single request. My 
model additionally allows to even change the name of a host used as a name 
server in multiple domains in a single request.

My model has a drawback regarding potential in-zone host name resolution cycles, 
but this problem is IMHO heavily overestimated and can be handled during zone 
file generation. A quick analyses of our domains shows that nearly none of our 
.info and .biz domains and only 2% of our .org domains fully rely on in-zone 
hosts. Even our com/net domains have a rate of less than 50%. This is surely not 
representative, and I expect that ccTLDs have a much higher rate > 95%. So 
depending on the registry, EPP's host model, where cycles involving out-of-zone 
hosts are not prevented, has little benefit to the operativeness of the DNS. If 
one takes the abilities of misconfigurations into account which are fully 
ignored by the current gTLD registries (contrary to many ccTLDs), this makes 
even less sense.

Everything above I wrote at least once to the list and I don't want to discuss 
this in detail any longer. You said in a recent e-mail, that you don't want to 
make fundamential changes to the protocol at this point of progress, which is 
understandable to me. So if I ever have to use EPP on server side, I'm going to 
maltreat it until it fits my needs, whether it is recognizable as EPP afterwards 
or not.

> -Scott-

regards,

Klaus

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

Date: Mon, 9 Dec 2002 11:43:59 +0100
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: Standard mappings hardwired in EPP servers? (Was: lastVerified: optional vs. extension
Organization: Gandi
Sender: [email-masked]

On Mon, Dec 09, 2002 at 10:57:40AM +0100, Stephane Bortzmeyer took time to write:
> It is also a problem for the registrars: if you interact with several
> registries and they use different EPP mappings, you lose a part of the
> reason to have a standard protocol...

Not necessarily, it depends how well the client is coded, and if it
knows the abstract the specificities of each Registry.
Not trivial, but doable IMNSHO.

Patrick Mevzek.

Date: Mon, 9 Dec 2002 02:16:04 -0800 (PST)
From: Hong Liu <[email-masked]>
Subject: Re: Standard mappings hardwired in EPP servers? (Was: lastVerified: o ptional vs. extension
To: [email-masked]
Sender: [email-masked]

Agree. I bet this is what the standard mappings are
for.

--- Stephane Bortzmeyer <[email-masked]> wrote:
> On Fri, Dec 06, 2002 at 10:59:11AM -0500,
>  Joe Abley <[email-masked]> wrote 
>  a message of 25 lines which said:
> 
> > It is also important to remember that the domain
> and nameserver mapping 
> > documents are extensions to the base protocol, and
> not integral to it. 
> > There is nothing to stop a registry for whom the
> current documents are 
> > not a good match from writing their own mapping
> documents that better 
> > suit their purposes.
> 
> Yes, but this could be a nightmare for the
> implementor of the EPP
> server: if you distribute a shrink-wrapped server
> (wether free
> software or closed), you need some sort of plug-in
> mechanism in the
> server in order to support "alternative" mappings.
> It is not obvious
> to realize. (/etc/epp.conf contains a relationship
> of
> extension->module/class to load? And the registry
> develops the local
> modules/classes?)
> 
> Let's try: how many EPP servers (whatever their
> legal status) have the
> "standard" mappings hardwired in the code? I assume
> "all".
> 
> It is also a problem for the registrars: if you
> interact with several
> registries and they use different EPP mappings, you
> lose a part of the
> reason to have a standard protocol...

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

Date: Mon, 9 Dec 2002 10:57:40 +0100
From: Stephane Bortzmeyer <[email-masked]>
To: Joe Abley <[email-masked]>
Cc: [email-masked]
Subject: Standard mappings hardwired in EPP servers? (Was: lastVerified: optional vs. extension
Organization: NIC France
Sender: [email-masked]

On Fri, Dec 06, 2002 at 10:59:11AM -0500,
 Joe Abley <[email-masked]> wrote 
 a message of 25 lines which said:

> It is also important to remember that the domain and nameserver mapping 
> documents are extensions to the base protocol, and not integral to it. 
> There is nothing to stop a registry for whom the current documents are 
> not a good match from writing their own mapping documents that better 
> suit their purposes.

Yes, but this could be a nightmare for the implementor of the EPP
server: if you distribute a shrink-wrapped server (wether free
software or closed), you need some sort of plug-in mechanism in the
server in order to support "alternative" mappings. It is not obvious
to realize. (/etc/epp.conf contains a relationship of
extension->module/class to load? And the registry develops the local
modules/classes?)

Let's try: how many EPP servers (whatever their legal status) have the
"standard" mappings hardwired in the code? I assume "all".

It is also a problem for the registrars: if you interact with several
registries and they use different EPP mappings, you lose a part of the
reason to have a standard protocol...

Date: Mon, 9 Dec 2002 10:57:40 +0100
From: Stephane Bortzmeyer <[email-masked]>
To: Joe Abley <[email-masked]>
Cc: [email-masked]
Subject: Standard mappings hardwired in EPP servers? (Was: lastVerified: optional vs. extension
Organization: NIC France
Sender: [email-masked]

On Fri, Dec 06, 2002 at 10:59:11AM -0500,
 Joe Abley <[email-masked]> wrote 
 a message of 25 lines which said:

> It is also important to remember that the domain and nameserver mapping 
> documents are extensions to the base protocol, and not integral to it. 
> There is nothing to stop a registry for whom the current documents are 
> not a good match from writing their own mapping documents that better 
> suit their purposes.

Yes, but this could be a nightmare for the implementor of the EPP
server: if you distribute a shrink-wrapped server (wether free
software or closed), you need some sort of plug-in mechanism in the
server in order to support "alternative" mappings. It is not obvious
to realize. (/etc/epp.conf contains a relationship of
extension->module/class to load? And the registry develops the local
modules/classes?)

Let's try: how many EPP servers (whatever their legal status) have the
"standard" mappings hardwired in the code? I assume "all".

It is also a problem for the registrars: if you interact with several
registries and they use different EPP mappings, you lose a part of the
reason to have a standard protocol...

Date: Sat, 7 Dec 2002 09:11:36 -0800 (PST)
From: Hong Liu <[email-masked]>
Subject: RE: lastVerified: optional vs. extension
To: Rick Wesson <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Rick,

Please see my comments in line. 

Cheers,

--Hong

--- Rick Wesson <[email-masked]> wrote:
> On Fri, 6 Dec 2002, Hong Liu wrote:
> 
> > I concur with Scott's observation. I would say
> that
> > extension seems to be the way to go for
> lastVerified.
> 
> 
> Hong,
> 
> My proposal was to have the follwoing XML in the
> contact-1.0.xsd:
> 
>   <complexType name="infDataType">
> ...
>       <element name="lvDate" type="dateTime"
> minOccurs="0"/>
> ...
>   </complexType>
> 
> You have advocated an extention. prposal is as
> complex as the "fax"
> element. Registries can express this critical value
> that many
> organizations are asking for or they may not.
> 
As I explained in another email, even from a technical
perspective, adding this element is not as trivial as
you described above. I would not repeat why it is
different than "fax" here.

If it is in the base protocol, all registries will
have to deal with it, whether they support it or not,
in order to be EPP compliant. The business logic for
registry policy will be driven down to the element
level. We should try to avoid such design if we have
an alternative.

> Why do you prefer to add the burdon of an extention
> whic is much more
> vobers, requireing name space negoiation by the
> server and extion
> libraries for the client to address this ICANN and
> IESG issue?
> 
That is exactly the beauty of extension, and XML
namespace separation. The server makes it explicit in
terms of what namespaces it supports at session
negotiation. XML parsing will fail right away if a
client uses a namespace that the server does not
support. The server business logic is a lot cleaner
than handling it at the element level.

Most importantly, we don't know whether the element by
itself is sufficient for different policies to be set
up. It is premature to incorporate it in the base EPP
spec. What if different registries collect different
data for the same purpose? Then you need to use
extension anyway.

> -rick

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

Date: Sat, 7 Dec 2002 08:40:29 -0800 (PST)
From: Hong Liu <[email-masked]>
Subject: Re: lastVerified: optional vs. extension
To: [email-masked]
Sender: [email-masked]

Rick,

I agree that there were different opinions on the list
regarding whether this should be optional or as an
extension. Applying Ed's metric, this clearly
indicates that this element _does not_ meet the
criteria of being optional. I can see the value of it.
So making it as an extension is the only sensible way
to go. 

Please see my comments in line.

Regards,

--Hong

--- Rick Wesson <[email-masked]> wrote:
> 
> > That's not an old topic - it's a current one...
> >
> > BTW - if there are folks unhappy with the
> declaration of consensus
> > about last-verified, speak up.  I've heard
> murmurs...
> 
> ahem...
> 
> In the atlanta wg I presented the element
> last-verified-date as optional,
> as the "fax" element is optional in a contact
> elelemnt of a domain
> registration.
> 

The key difference is "last-verified-date" is heavily
policy related, while "fax" is not. As I said in
another email, to make it useful, the policy framework
needs to be established. Just adding this element does
not solve the problem you intended to solve. In
addition, it may not be enough to collect all the
necessary information for your purpose. So let it be
in the extension allows maximum flexibility. If
different registries excercise different policies,
they can support different extensions.

Bottom line: Different policy framework may post
different requirements on information gathering and
verification. Since we don't know how such policy
frameworks may turn out, we cannot fix the protocol
based on the framework _we_ think that will become.

> I have reviewed the mail archives and the notes from
> the physical meeting
> and there has only been two (2) requests for this
> element to be a
> described in a extention once by Hong, and by Klaus
> There have been other
> expressions of support on the list such as
> 
>  
>
http://www.cafax.se/ietf-provreg/maillist/2002-11/msg00047.html

Correct. That indicates that people have different
views on making it optional in the EPP base. Does it
meet the requirements in Ed's metric for being
optional, the answer is clear: no. 

> 
> The notes of the physical meeting clearly state the
> issue about the
> element being optional...
>

I am not a lawyer, and I do not intend to interpret
the following literally. In short, arguing against it
being mandatory does not automatically translate into
supporting it being optional. There is a third
alternative: making it an extension.

> 
> EL: OK. On the mailing list, the last message on
> this talked about this
>      being
>      optional. Not everyone agreed that all
> registries. So this is the
>      question i
>      am most interested in. Should it be optional?
> RW: From the comments i have received it makes the
> most sense.
> JP: It doesn't seem to make any sense to make it
> mandatory. There are
>      all kinds of
>      bad things about iut.
> SH: I agree, it seems appropriate. The last comment
> was more strong
>      that it should
>      not be in the base, but i agree with RW on
> this.
> RS: Ditto.
> EL: We have documents in from of the IESG and I am
> not sure if we
>     want to make a
>      change at this stage.
> RW: The IESG knows about this.
> 
> an optional element is very diferent than an
> extention and the term
> extention was never presented, raised, or recomended
> durring the physical
> meeting.

What is important here is that IETF works towards
consensus based on discussions on the mailing list,
not on the spot at f2f meetings. That is the key
difference between IETF and other standards bodies
such as ITU and ETSI. 

> best,
> -rick

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>
Cc: [email-masked]
Subject: RE: * excuse * was:  Re: lastVerified: optional vs. extension
Date: Sat, 7 Dec 2002 11:34:51 -0500 
Sender: [email-masked]

> I hereby officially beg pardon. On the search in my archive I 
> discovered 
> that I mostly discussed this topic with other participants 
> and not with 
> you, so my memory deceived me. Therefore I deeply regret that 
> I made the 
> charge to you personally.

No problem -- disagreement is healthy in this environment as long as we try
to keep it professional.

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>
Cc: [email-masked]
Subject: RE: lastVerified: optional vs. extension
Date: Sat, 7 Dec 2002 11:32:39 -0500 
Sender: [email-masked]

> Well, at the moment I don't know which proposal you are referring to, 
> but let me say that external hosts were never a problem to me. The 
> problem I had and still have are the in-zone hosts - who is 
> allowed to 
> create them and under which conditions they are used for the 
> creation of 
> glue records. I explained more than once to you that your 
> model does not 
> have the high level of security/reliability you claim. I got the 
> impression that it wasn't a communication problem that you did not 
> understand me, but that you just *didn't want* to understand 
> me. I have 
> to admit that this really hurt me somewhere.

I (and again, others -- check the archives) continue to disagree with your
assertions of model deficiency, and when we pointed out the issues with
_your_ model (like the bulk update problem) you typically failed to respond.
That's not a sign of not trying to understand -- if anything, it's a clear
sign of trying to explore all of the issues in necessary detail.

I don't think I ever came across as rude or disinterested, and I stand by
the fact that several of your comments were incorporated into the drafts as
evidence of acceptance of your ideas.

-Scott-

Date: Sat, 7 Dec 2002 05:58:16 -0800 (PST)
From: Hong Liu <[email-masked]>
Subject: Re: lastVerified: optional vs. extension
To: [email-masked]
Sender: [email-masked]

Ed, Michael,

Just like Scott, I am not a big fan of ROID either.
Its usage in EPP is vague at best. But that is a
different thread of discussion.

What I would like to say is while the syntax of
lastVerified may look simple, the policy issues around
its usage is not. In fact, even the technical changes
to be made is _not_ as trivial as it seems. At least
three EPP commands will be affected:
create/update/info. In addition, you also need to add
<verID> for the entity who performs the verification.
Depending on the specific policy, this entity may be a
third party that is neither the registry nor a
registrar, and there could be more than one such
entity. 

One can imagine a scenario where the address info is
verified by a Business Bureau or a post office, the
tel and fax numbers are verified by a telephone
carrier, and the email address is verified by an ISP.
And each of these may have a different <verDate>
associated with it. Now, is lastVerified sufficient to
represent all these information? Of course not! That
is why we need an extension mechanism for a registry
to define what information elements are needed in
order to comply for a specific policy framework.

This may look like an extreme case. The point I want
to make is that it is _very_ dangerous to fix
something in the protocol (i.e., assuming a specific
model) without knowing what the policy framework is
for its collection and usage. This is very similar to
the privacy issue we are dealing with. For the latter,
the WG seems to going down the path of extension.

If your guys want to know the complexity of this type
of information gathering and validation, you can ask
the ENUM folks about telephone number validation.

The bottom line: if we all agree on Ed's metric and
apply it to this issue, the only sensible way to deal
with it is to use extension.

--Hong

--- Edward Lewis <[email-masked]> wrote:
> At 20:49 +0000 12/6/02, Michael Graff wrote:
> >I hate to keep bringing up old topics, but I don't
> see how ROIDs can be
> >left in the draft as they are now, when something
> that is trivial to define
> >(last verified date) is an extension, but ROIDs are
> required and at least
> >two implementors have stood up and said they're
> problems.
> 
> That's not an old topic - it's a current one...
> 
> BTW - if there are folks unhappy with the
> declaration of consensus 
> about last-verified, speak up.  I've heard
> murmurs...
> -- 
>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                        
>  +1-703-227-9854
> ARIN Research Engineer

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

Date: Fri, 6 Dec 2002 15:37:15 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: Michael Graff <[email-masked]>, <[email-masked]>
Subject: Re: lastVerified: optional vs. extension
Sender: [email-masked]

> That's not an old topic - it's a current one...
>
> BTW - if there are folks unhappy with the declaration of consensus
> about last-verified, speak up.  I've heard murmurs...

ahem...

In the atlanta wg I presented the element last-verified-date as optional,
as the "fax" element is optional in a contact elelemnt of a domain
registration.

I have reviewed the mail archives and the notes from the physical meeting
and there has only been two (2) requests for this element to be a
described in a extention once by Hong, and by Klaus There have been other
expressions of support on the list such as

  http://www.cafax.se/ietf-provreg/maillist/2002-11/msg00047.html

The notes of the physical meeting clearly state the issue about the
element being optional...

EL: OK. On the mailing list, the last message on this talked about this
     being
     optional. Not everyone agreed that all registries. So this is the
     question i
     am most interested in. Should it be optional?
RW: From the comments i have received it makes the most sense.
JP: It doesn't seem to make any sense to make it mandatory. There are
     all kinds of
     bad things about iut.
SH: I agree, it seems appropriate. The last comment was more strong
     that it should
     not be in the base, but i agree with RW on this.
RS: Ditto.
EL: We have documents in from of the IESG and I am not sure if we
    want to make a
     change at this stage.
RW: The IESG knows about this.

an optional element is very diferent than an extention and the term
extention was never presented, raised, or recomended durring the physical
meeting.

best,

-rick

Date: Fri, 6 Dec 2002 18:16:47 -0500
To: Michael Graff <[email-masked]>, Edward Lewis <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: lastVerified: optional vs. extension
Cc: [email-masked]
Sender: [email-masked]

At 20:49 +0000 12/6/02, Michael Graff wrote:
>I hate to keep bringing up old topics, but I don't see how ROIDs can be
>left in the draft as they are now, when something that is trivial to define
>(last verified date) is an extension, but ROIDs are required and at least
>two implementors have stood up and said they're problems.

That's not an old topic - it's a current one...

BTW - if there are folks unhappy with the declaration of consensus 
about last-verified, speak up.  I've heard murmurs...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

Date: Fri, 06 Dec 2002 23:20:49 +0100
From: Klaus Malorny <[email-masked]>
To: Edward Lewis <[email-masked]>
CC: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: objections, was Re: lastVerified: optional vs. extension
Sender: [email-masked]

Edward Lewis wrote:
> At 16:25 +0100 12/6/02, Klaus Malorny wrote:
> 

> 
> Can we get a summary of just what the problem is?  Pointers to the 
> archives are sufficient, or perhaps more words to this.  Over time the 
> way in which hosts (name servers) are associated with domains have 
> changed.  There is still some talk about *external* hosts.  (You mention 
> 'discussed heavily?'  In what venue?)
> 

It took place in August 2001, the thread was named "host transfers".

regards,

Klaus

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

Date: Fri, 06 Dec 2002 23:08:57 +0100
From: Klaus Malorny <[email-masked]>
To: Klaus Malorny <[email-masked]>
CC: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: * excuse * was:  Re: lastVerified: optional vs. extension
Sender: [email-masked]

Klaus Malorny wrote:
> Hollenbeck, Scott wrote:

> 
> Well, at the moment I don't know which proposal you are referring to, 
> but let me say that external hosts were never a problem to me. The 
> problem I had and still have are the in-zone hosts - who is allowed to 
> create them and under which conditions they are used for the creation of 
> glue records. I explained more than once to you that your model does not 
> have the high level of security/reliability you claim. I got the 
> impression that it wasn't a communication problem that you did not 
> understand me, but that you just *didn't want* to understand me. I have 
> to admit that this really hurt me somewhere.
> 
>> -Scott-
>>
> 
> regards,
> 
> Klaus
> 

Hi Scott,

I hereby officially beg pardon. On the search in my archive I discovered 
that I mostly discussed this topic with other participants and not with 
you, so my memory deceived me. Therefore I deeply regret that I made the 
charge to you personally.

regards,

Klaus

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

Date: Fri, 06 Dec 2002 22:31:30 +0100
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: lastVerified: optional vs. extension
Sender: [email-masked]

Hollenbeck, Scott wrote:
Hi Scott,

> Yes, thanks to you I have an understanding of what .de is doing and how it
> works.  You're quite incorrect, though, to claim that I or anyone else
> ignored the .de model or your points.  I (and several others) _disagreed_
> with your points.  That doesn't mean your position was ignored, and it's an
> assault on reality to claim otherwise.
> 

No, no. I have don't have any problems if there are multiple positions 
regarding a topic with good arguments for each one and not mine is taken 
at the end.
But regarding the discussion I'm referring to, it was like convincing 
the pope that the earth is a sphere and not the center of the universe. 
You insisted on your position without taking my arguments into account. 
At least this appeared that way to me.

> Don't forget that my last proposal for addressing out-of-zone hosts (which
> tilted towards the .de model, by the way) has also not been incorporated
> into the documents.  That example, and the reality of how your comments were
> addressed, is a measure of how the consensus process works.  I'm not about
> to suggest that my inputs on the issue were ignored just because the WG
> didn't go along with them, though.
> 

Well, at the moment I don't know which proposal you are referring to, 
but let me say that external hosts were never a problem to me. The 
problem I had and still have are the in-zone hosts - who is allowed to 
create them and under which conditions they are used for the creation of 
glue records. I explained more than once to you that your model does not 
have the high level of security/reliability you claim. I got the 
impression that it wasn't a communication problem that you did not 
understand me, but that you just *didn't want* to understand me. I have 
to admit that this really hurt me somewhere.

> -Scott-

regards,

Klaus

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

To: Edward Lewis <[email-masked]>
Cc: [email-masked]
Subject: Re: lastVerified: optional vs. extension
From: Michael Graff <[email-masked]>
Date: 06 Dec 2002 20:49:49 +0000
Lines: 33
Sender: [email-masked]

I hate to keep bringing up old topics, but I don't see how ROIDs can be
left in the draft as they are now, when something that is trivial to define
(last verified date) is an extension, but ROIDs are required and at least
two implementors have stood up and said they're problems.

--Michael

Edward Lewis <[email-masked]> writes:

> Let's go with the working assumption that last-verified will be
> defined as an extension.  (I.e., consensus says...)
> 
> The plan here is:
> 
> 1) An individual ID is worked on towards this end.
> 2) Although the mailing list is a fine place to talk about this, no ID
> on this topic is to be admitted until we get the base protocol to
> Proposed Standard.
> 3) We won't consider any milestones about this until we *consider*
> admitting the work.
> 
> ...I say this to keep us focused on getting the current set of
> documents to Proposed Standard, not to delay 'last-verified.'
> 
> At 8:02 -0800 12/6/02, Hong Liu wrote:
> >I concur with Scott's observation. I would say that
> >extension seems to be the way to go for lastVerified.
> 
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                          +1-703-227-9854
> ARIN Research Engineer

Date: Fri, 06 Dec 2002 21:36:57 +0100
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: lastVerified: optional vs. extension
Sender: [email-masked]

Hollenbeck, Scott wrote:
> Sorry, I missed a few points:
> 
> < The objects themselves are not extensible, you either 
> < have to live with them or you have to replace them.
> 
> Not true.  Each of the domain, contact, and host objects can be extended.
> For example, I have multiple individual submission Internet-Draft documents
> published that extend the domain object.
> 
> It's true that you can't _remove_ required elements from the objects, but
> definition of required elements if why we have a consensus-based process in
> the first place.
> 
> 
>>Error codes are not extensible, with the 
>>consequence that some existing registries put additional 
>>error codes in the free 
>>text elements (which are not thought to be parsed).
> 
> 
> Again, not true.  Additional errors and error codes can be defined using the
> extension mechanism.  If implementers are putting additional error codes in
> inappropriate free text elements they're extending the protocol improperly.
> 
> -Scott-

Hi Scott,

my understanding of "extensibility" is a bit different to to provide a 
single XML element which is a container for every possible extension. 
The problem is, like in any other project that aims to cover future 
developments, to have backdoors at the right places where they are later 
needed. You have some in EPP, of course, but on the other hand, in some 
other aspects EPP is so stringent, much more than it is required and 
more than a registry policy free protocol should have IMHO.

regards,

Klaus

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

Date: Fri, 6 Dec 2002 12:18:50 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: Hong Liu <[email-masked]>
cc: <[email-masked]>
Subject: RE: lastVerified: optional vs. extension
Sender: [email-masked]

On Fri, 6 Dec 2002, Hong Liu wrote:

> I concur with Scott's observation. I would say that
> extension seems to be the way to go for lastVerified.

Hong,

My proposal was to have the follwoing XML in the contact-1.0.xsd:

  <complexType name="infDataType">
...
      <element name="lvDate" type="dateTime" minOccurs="0"/>
...
  </complexType>

You have advocated an extention. prposal is as complex as the "fax"
element. Registries can express this critical value that many
organizations are asking for or they may not.

Why do you prefer to add the burdon of an extention whic is much more
vobers, requireing name space negoiation by the server and extion
libraries for the client to address this ICANN and IESG issue?

-rick

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Joe Abley'" <[email-masked]>, [email-masked]
Subject: RE: lastVerified: optional vs. extension
Date: Fri, 6 Dec 2002 14:54:53 -0500 
Sender: [email-masked]

> >> Error codes are not extensible, with the
> >> consequence that some existing registries put additional
> >> error codes in the free
> >> text elements (which are not thought to be parsed).
> >
> > Again, not true.  Additional errors and error codes can be defined 
> > using the
> > extension mechanism.  If implementers are putting additional error 
> > codes in
> > inappropriate free text elements they're extending the protocol 
> > improperly.
> 
> Do you have any examples of how this works?
> 
> Suppose I want to add an additional server system failure result code 
> (say, 2309, "openreg-specific failure of some kind"). How could I add 
> that in such a way that clients connecting to me could distinguish it 
> from some future revision of the spec that defines 2309 
> differently, or 
> some other registry which makes its own use of 2309?

This will be kind of long because of the examples.  Please bear with me --
references to the WG archives are included and listed below.

Interestingly enough, this topic was also discussed on the mailing list this
past August.  Roger Castillo Cortazar [1] brought up the idea of adding an
error code value for extension-related errors; I countered [2] with a
suggestion for one or two response codes that meant "look at the <extension>
for details".  It might be a good idea to follow that thread for a bit
before reading further since the idea for the need didn't pass WG muster.

To answer your specific question: One would have to work from an existing
response code, and the fact that extensions are unique should ensure that
there is no conflict in interpreting code collisions as long as the
extension code value is unique within the extension itself.

For example, you could do this to add a new response code or additional
code-related data to a success response:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
     epp-1.0.xsd">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <extension>
      <foo:extData xmlns:foo="urn:ietf:params:xml:ns:foo"
       xsi:schemaLocation="urn:ietf:params:xml:ns:foo foo.xsd">
        <foo:result code="1111">
          <foo:what>This is a sample</foo:what>
        </foo:result>
      </foo:extData>
    </extension>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54321-XYZ</svTRID>
    </trID>
  </response>
</epp>

Extension code value 1111 MUST be unique within the "foo" namespace to avoid
collisions.  You could do something similar with an error response:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
     epp-1.0.xsd">
  <response>
    <result code="2400">
      <msg>Command failed</msg>
    </result>
    <extension>
      <foo:extData xmlns:foo="urn:ietf:params:xml:ns:foo"
       xsi:schemaLocation="urn:ietf:params:xml:ns:foo foo.xsd">
        <foo:result code="2111">
          <foo:what>This is a sample</foo:what>
        </foo:result>
      </foo:extData>
    </extension>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54321-XYZ</svTRID>
    </trID>
  </response>
</epp>

One might argue that we really need a general error code that requires an
extension for additional information, but as I said above that idea didn't
pass WG muster earlier this year.

-Scott-

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

[2]
http://www.cafax.se/ietf-provreg/maillist/2002-08/msg00073.html

Date: Fri, 6 Dec 2002 12:12:39 -0500
Subject: Re: lastVerified: optional vs. extension
From: Joe Abley <[email-masked]>
To: [email-masked]
Sender: [email-masked]

On Friday, Dec 6, 2002, at 11:14 Canada/Eastern, Hollenbeck, Scott 
wrote:

>> Error codes are not extensible, with the
>> consequence that some existing registries put additional
>> error codes in the free
>> text elements (which are not thought to be parsed).
>
> Again, not true.  Additional errors and error codes can be defined 
> using the
> extension mechanism.  If implementers are putting additional error 
> codes in
> inappropriate free text elements they're extending the protocol 
> improperly.

Do you have any examples of how this works?

Suppose I want to add an additional server system failure result code 
(say, 2309, "openreg-specific failure of some kind"). How could I add 
that in such a way that clients connecting to me could distinguish it 
from some future revision of the spec that defines 2309 differently, or 
some other registry which makes its own use of 2309?

Joe

Date: Fri, 6 Dec 2002 11:24:27 -0500
Subject: Re: lastVerified: optional vs. extension
Cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
To: Klaus Malorny <[email-masked]>
From: Joe Abley <[email-masked]>
Sender: [email-masked]

On Friday, Dec 6, 2002, at 10:25 Canada/Eastern, Klaus Malorny wrote:

> Error codes are not extensible, with the consequence that some 
> existing registries put additional error codes in the free text 
> elements (which are not thought to be parsed).

We have spent time scratching our heads trying to find error codes to 
describe particular conditions in our EPP server implementation, and 
the idea of an extensible structure for error codes corresponding to 
the currently-documented functionality seems like a useful one.

There is also the issue that a future object mapping might introduce 
services with error conditions that are just not accommodated by the 
currently-specified set of error codes. This might lead to subversion 
of free-text error fields (as Klaus described) into machine-readable 
subcodes, or to the reinvention of much of the base EPP functionality 
in other protocols rather than reusing the work that has already been 
done here.

Perhaps a structure where a generic, fixed and base set of error codes 
could be extended with sub-codes that are particular to a server 
implementation, or particular to an object mapping specification, might 
do the trick. Clients unfamiliar with particular server sub-codes could 
happily ignore them, whereas those clients which have a need to obtain 
more fine-grained information could parse them.

If this idea seems interesting, I would be happy to come up with some 
corresponding text.

Joe

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>
Cc: [email-masked]
Subject: RE: lastVerified: optional vs. extension
Date: Fri, 6 Dec 2002 11:14:51 -0500 
Sender: [email-masked]

Sorry, I missed a few points:

< The objects themselves are not extensible, you either 
< have to live with them or you have to replace them.

Not true.  Each of the domain, contact, and host objects can be extended.
For example, I have multiple individual submission Internet-Draft documents
published that extend the domain object.

It's true that you can't _remove_ required elements from the objects, but
definition of required elements if why we have a consensus-based process in
the first place.

> Error codes are not extensible, with the 
> consequence that some existing registries put additional 
> error codes in the free 
> text elements (which are not thought to be parsed).

Again, not true.  Additional errors and error codes can be defined using the
extension mechanism.  If implementers are putting additional error codes in
inappropriate free text elements they're extending the protocol improperly.

-Scott-

Date: Fri, 6 Dec 2002 11:08:42 -0500
To: Hong Liu <[email-masked]>, [email-masked]
From: Edward Lewis <[email-masked]>
Subject: RE: lastVerified: optional vs. extension
Sender: [email-masked]

Let's go with the working assumption that last-verified will be 
defined as an extension.  (I.e., consensus says...)

The plan here is:

1) An individual ID is worked on towards this end.
2) Although the mailing list is a fine place to talk about this, no 
ID on this topic is to be admitted until we get the base protocol to 
Proposed Standard.
3) We won't consider any milestones about this until we *consider* 
admitting the work.

...I say this to keep us focused on getting the current set of 
documents to Proposed Standard, not to delay 'last-verified.'

At 8:02 -0800 12/6/02, Hong Liu wrote:
>I concur with Scott's observation. I would say that
>extension seems to be the way to go for lastVerified.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>
Cc: [email-masked]
Subject: RE: lastVerified: optional vs. extension
Date: Fri, 6 Dec 2002 11:04:22 -0500 
Sender: [email-masked]

> you do know that the world's largest ccTLD (.de) has a 
> different model currently 
> and that it works fine. But you chose to ignore it. We had 
> long discussions 
> about the sense and nonsense of the association between name 
> servers and the 
> domains they belong to. But finally you chose to ignore my 
> points completely. 
> You designed it your way, with the result that it is still 
> being discussed heavily.

Yes, thanks to you I have an understanding of what .de is doing and how it
works.  You're quite incorrect, though, to claim that I or anyone else
ignored the .de model or your points.  I (and several others) _disagreed_
with your points.  That doesn't mean your position was ignored, and it's an
assault on reality to claim otherwise.

Don't forget that my last proposal for addressing out-of-zone hosts (which
tilted towards the .de model, by the way) has also not been incorporated
into the documents.  That example, and the reality of how your comments were
addressed, is a measure of how the consensus process works.  I'm not about
to suggest that my inputs on the issue were ignored just because the WG
didn't go along with them, though.

-Scott-

Date: Fri, 6 Dec 2002 08:02:03 -0800 (PST)
From: Hong Liu <[email-masked]>
Subject: RE: lastVerified: optional vs. extension
To: [email-masked]
Sender: [email-masked]

I concur with Scott's observation. I would say that
extension seems to be the way to go for lastVerified.

--- "Hollenbeck, Scott" <[email-masked]>
wrote:
> > Here's my metric:
> > 
> > Make it optional if
> > 1) Everyone that will want to use it will do so in
> the same way and 
> > can agree on the syntax.
> > 2) Everyone will want to be able to make use of it
> at some point - 
> > even if not regularly.
> > 3) It's worth making a change to the core
> documents for this.
> 
> I don't think syntax is a problem, but based on the
> discussion so far I
> don't think we've met the "Everyone that will want
> to use it will do so in
> the same way" or "Everyone will want to be able to
> make use of it at some
> point" metrics.
> 

agree.

> > Make it an extension if
> > 1) Not everyone agrees on what is should look like
> or how it 
> > should be used.
> > 2) Not everyone will want the ability to make use
> of it.
> > Note that there is no #3 (would have been - it can
> be an extension 
> > after the core specs are at PS).  I won't say this
> because I refuse 
> > to consider extensions to a protocol that hasn't
> hit PS yet.
> 
> Both of these loom large based on the discussion so
> far.
> 

Agree. This is evident from the discussions so far.

> -Scott-

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

Date: Fri, 6 Dec 2002 10:59:11 -0500
Subject: Re: lastVerified: optional vs. extension
Cc: "'Klaus Malorny'" <[email-masked]>, [email-masked]
To: "Hollenbeck, Scott" <[email-masked]>
From: Joe Abley <[email-masked]>
Sender: [email-masked]

On Friday, Dec 6, 2002, at 07:46 Canada/Eastern, Hollenbeck, Scott 
wrote:

>> We already have a lot of registry-specific and inflexible
>> stuff in EPP, mostly,
>> but not limited to, the handling of name servers. EPP is
>> clearly designed after
>> Network Solution's registry model (before they were forced to
>> open the registry
>> to others), which is far from being generic or prototypical
>> for the existing
>> ccTLDs around the world.
>
> If this were true and the model were not of more general interest other
> members of the WG would have shot it down long ago.

It is also important to remember that the domain and nameserver mapping 
documents are extensions to the base protocol, and not integral to it. 
There is nothing to stop a registry for whom the current documents are 
not a good match from writing their own mapping documents that better 
suit their purposes.

Joe

Date: Fri, 6 Dec 2002 10:47:00 -0500
To: Klaus Malorny <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject:  objections, was Re: lastVerified: optional vs. extension
Cc: [email-masked]
Sender: [email-masked]

At 16:25 +0100 12/6/02, Klaus Malorny wrote:

>you do know that the world's largest ccTLD (.de) has a different model
>currently and that it works fine. But you chose to ignore it. We had long
>discussions about the sense and nonsense of the association between name
>servers and the domains they belong to. But finally you chose to 
>ignore my >points completely. You designed it your way, with the 
>result that it is still
>being discussed heavily.

Can we get a summary of just what the problem is?  Pointers to the 
archives are sufficient, or perhaps more words to this.  Over time 
the way in which hosts (name servers) are associated with domains 
have changed.  There is still some talk about *external* hosts.  (You 
mention 'discussed heavily?'  In what venue?)

>Finally, I wouldn't interpret the silence of many list members as consent.
>People have different reasons to subscribe to this list and different reasons
>to participate actively or not.

I know of a couple of efforts that are on going 'under the covers.' 
This isn't beneficial to anyone as the WG can't react to comments not 
made.  In the IETF world, silence is consent because no one is ever 
required to voice an opinion.  Since we don't have voting, 
membership, etc., we have to rely on vocal participation.

I hope that no one feels that they are at the mercy of EPP.  I've 
been trying to get anyone with any reservations about EPP's 
definition to speak up.  I tried unsuccessfully to get ccTLDs to 
participate at the Atlanta meeting, to bring up unresolved issues. 
If anyone is afraid to speak against EPP because of its origin, speak 
directly to either of the co-chairs - Jaap and myself.  Neither of us 
is in any way attached to origins of the protocol.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

Date: Fri, 06 Dec 2002 16:25:06 +0100
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: lastVerified: optional vs. extension
Sender: [email-masked]

Hollenbeck, Scott wrote:
>>We already have a lot of registry-specific and inflexible 
>>stuff in EPP, mostly, 
>>but not limited to, the handling of name servers. EPP is 
>>clearly designed after 
>>Network Solution's registry model (before they were forced to 
>>open the registry 
>>to others), which is far from being generic or prototypical 
>>for the existing 
>>ccTLDs around the world.
> 
> 
> If this were true and the model were not of more general interest other
> members of the WG would have shot it down long ago.  As I remember the
> discussion the WG felt that the model was the most reasonable compromise
> when all the alternatives (including the one you proposed) were considered.
> 
> -Scott-

Hi Scott,

you do know that the world's largest ccTLD (.de) has a different model currently 
and that it works fine. But you chose to ignore it. We had long discussions 
about the sense and nonsense of the association between name servers and the 
domains they belong to. But finally you chose to ignore my points completely. 
You designed it your way, with the result that it is still being discussed heavily.

Regarding ccTLDs like .de, one could of course use EPP as a protocol on their 
model, but effectively you would have to throw away half of it and reimplement 
it: The objects themselves are not extensible, you either have to live with them 
or you have to replace them. Error codes are not extensible, with the 
consequence that some existing registries put additional error codes in the free 
text elements (which are not thought to be parsed).
Well, the registry could transform itself to be EPP compliant (maybe with the 
need to change their whole business process). But this reminds me to a proverb: 
"If the prophet does not come to the mountain, the mountain has to come to the 
prophet").

On behalf of CORE, our company has implemented the client side for the Afilias, 
Neulevel, Neustar, GNR registries and is currently preparing the implementation 
for DotCoop, .CN via Neustar. We are thinking of whether and how to use EPP as 
an additional protocol for the two sponsored gTLDs CORE operates.

Having this as a background, my personal impression I got in the meantime is 
that EPP provides less benefits as one might expect. Each of the unsponsored 
registries has some specialities (despite the fact that they all use different 
versions of EPP drafts) that need special handling far, far away from the 
protocol level. Sponsored registries are even worse, as they need new requests 
in EPP and as they might introduce side effects not covered by the protocol.

As long as one has a library for the programming language one works with (which 
are supplied by most of the registries), the benefits EPP might have compared to 
other similar protocols vanish, esp. as EPP does not provide/support any new 
features like transaction management (similar to databases) or a more complex 
model of sponsorship (beyond the registry-registrar model).

Finally, I wouldn't interpret the silence of many list members as consent. 
People have different reasons to subscribe to this list and different reasons to 
participate actively or not.

regards,

Klaus

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Subject: RE: lastVerified: optional vs. extension
Date: Fri, 6 Dec 2002 07:52:28 -0500 
Sender: [email-masked]

> Here's my metric:
> 
> Make it optional if
> 1) Everyone that will want to use it will do so in the same way and 
> can agree on the syntax.
> 2) Everyone will want to be able to make use of it at some point - 
> even if not regularly.
> 3) It's worth making a change to the core documents for this.

I don't think syntax is a problem, but based on the discussion so far I
don't think we've met the "Everyone that will want to use it will do so in
the same way" or "Everyone will want to be able to make use of it at some
point" metrics.

> Make it an extension if
> 1) Not everyone agrees on what is should look like or how it 
> should be used.
> 2) Not everyone will want the ability to make use of it.
> Note that there is no #3 (would have been - it can be an extension 
> after the core specs are at PS).  I won't say this because I refuse 
> to consider extensions to a protocol that hasn't hit PS yet.

Both of these loom large based on the discussion so far.

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>
Cc: [email-masked]
Subject: RE: lastVerified: optional vs. extension
Date: Fri, 6 Dec 2002 07:46:47 -0500 
Sender: [email-masked]

> We already have a lot of registry-specific and inflexible 
> stuff in EPP, mostly, 
> but not limited to, the handling of name servers. EPP is 
> clearly designed after 
> Network Solution's registry model (before they were forced to 
> open the registry 
> to others), which is far from being generic or prototypical 
> for the existing 
> ccTLDs around the world.

If this were true and the model were not of more general interest other
members of the WG would have shot it down long ago.  As I remember the
discussion the WG felt that the model was the most reasonable compromise
when all the alternatives (including the one you proposed) were considered.

-Scott-

Date: Fri, 06 Dec 2002 10:31:52 +0100
From: Klaus Malorny <[email-masked]>
To: Hong Liu <[email-masked]>
CC: [email-masked]
Subject: Re: lastVerified: optional vs. extension
Sender: [email-masked]

Hong Liu wrote:
> Rick,
> 
> I think the same standards apply to both camps. I
 > [...]

I second Hong's objections. Up to now no registry I know supports this feature. 
So nobody can claim that this belongs to the base functionality of a registry. 
In this context I would like to remind you on a discussion I had with Scott in 
June 2001. There I suggested to add a field to the responses that reports the 
cost of a transaction, e.g. the registration fee for the creation of a domain. 
Scott rejected it as follows:

     I'd certainly prefer to keep registry-specific billing details out of the
     protocol.  If they have to be in there anywhere a registry could do whatever
     it wants in the <unspec> elements.  If you have a proposal in mind, though,
     please post it to the list to present a more complete picture and to gather
     other opinions.

The same argument applies to the lastVerified topic. It is registry specific, it 
is not required for the registration process in any way and therefore violates 
the KISS principle. As we discussed, a date alone has no value as registries may 
apply differnet policies *IF* they support this field. And maybe they have 
different verification methods for different kinds of entities, which they need 
to report, too. So this element might be insufficient on the other hand.

We already have a lot of registry-specific and inflexible stuff in EPP, mostly, 
but not limited to, the handling of name servers. EPP is clearly designed after 
Network Solution's registry model (before they were forced to open the registry 
to others), which is far from being generic or prototypical for the existing 
ccTLDs around the world.

Once a famous protocol designer (unfortunately, I don't know who it was) said, 
that in the aim to optimize a protocol, one should not ask what should be added 
to it, but what can be removed. In this sense, I suggest not to add this element.

regards,

Klaus

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

Date: Thu, 5 Dec 2002 23:53:25 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: Hong Liu <[email-masked]>, <[email-masked]>
Subject: Re: lastVerified: optional vs. extension
Sender: [email-masked]

> Think about client C and server S1 and server S2.  S1 and S2 disagree
> on last-verified date's meaning and usage.  Is there a need to keep
> the syntax the same?

the semantics of last-verified-date is the same as those for other date
elements that are published in other formats (whois/crisp) in the XML the
last-verified-date uses the same "type" as created-date.

I don't see a problem with a server interpeting this data.

-rick

Date: Thu, 5 Dec 2002 23:24:47 -0500
To: Hong Liu <[email-masked]>, [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Re: lastVerified: optional vs. extension
Sender: [email-masked]

At 20:06 -0800 12/5/02, Hong Liu wrote:
>Ed,
>
>Questions for clarification regarding whose opinion
>counts:
>- when you said users of EPP clients, do you mean
>registrars/resellers?

yup

>- when you said users of EPP servers, do you mean
>registries?

yup

>- when you said implementors, do you mean third party
>EPP software vendors?

uh, yeah, but that includes you (and Scott, Joe, Michael, Rick, 
et.al. - I don't mean to omit anyone, but you get the idea).

>- how about other people who do not fall into one of
>the above three categories, but are also concerned
>about this topic, such as regulartory agencies? The
>verification can be done via a third party other than
>the registry and its registrars.

no - they may influence the users, but let's keep this in 
perspective.  We are talking about whether to put last-verified as an 
optional element of the base protocol or in an extension.

>Also, questions for clarification on the metric:
>- are technical issues such as simplicity, continuity,
>and legacy data migrations key considerations?

I can't imagine that these are important here.  (Remember that we are 
just talking about last-verified date.)

>- is lack of established policy framework for the use
>of this element a key consideration?

I think so.  I'd hate to see two servers interpret the date different 
given just one way of expressing it.  If there are two semantics 
involved, two different ways of communicating should be present.

Think about client C and server S1 and server S2.  S1 and S2 disagree 
on last-verified date's meaning and usage.  Is there a need to keep 
the syntax the same?  It may be nice because it makes the parsing 
code the same.  But if you require them to be the same (optional 
elements in the base), you are forcing a decision to be made.  If you 
leave them to extensions, then as new interpretations of the 
last-date are made, syntax can be decided later.

(Also C can verify that it is using the right date semantics by 
looking at the XML - if you debug down to that level.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

Date: Thu, 5 Dec 2002 20:06:35 -0800 (PST)
From: Hong Liu <[email-masked]>
Subject: Re: lastVerified: optional vs. extension
To: [email-masked]
Sender: [email-masked]

Ed,

Questions for clarification regarding whose opinion
counts:
- when you said users of EPP clients, do you mean
registrars/resellers?
- when you said users of EPP servers, do you mean
registries?
- when you said implementors, do you mean third party
EPP software vendors?
- how about other people who do not fall into one of
the above three categories, but are also concerned
about this topic, such as regulartory agencies? The
verification can be done via a third party other than
the registry and its registrars.

Also, questions for clarification on the metric:
- are technical issues such as simplicity, continuity,
and legacy data migrations key considerations?
- is lack of established policy framework for the use
of this element a key consideration?

Thanks!

--Hong

--- Edward Lewis <[email-masked]> wrote:
> Here's my metric:
> 
> Make it optional if
> 1) Everyone that will want to use it will do so in
> the same way and 
> can agree on the syntax.
> 2) Everyone will want to be able to make use of it
> at some point - 
> even if not regularly.
> 3) It's worth making a change to the core documents
> for this.
> 
> Make it an extension if
> 1) Not everyone agrees on what is should look like
> or how it should be used.
> 2) Not everyone will want the ability to make use of
> it.
> Note that there is no #3 (would have been - it can
> be an extension 
> after the core specs are at PS).  I won't say this
> because I refuse 
> to consider extensions to a protocol that hasn't hit
> PS yet.
> 
> Everyone means 'all users of EPP clients, all users
> of EPP servers.' 
> Implementer's opinions don't count here - except to
> argue over my 
> choice of metrics.  Implementer's can report what
> they hear users 
> saying.
> 
> The question isn't the goodness nor evilness of
> last-verified.  It's 
> whether it is vital to the protocol.
> 
> PS - I refuse to poll the list.  That's voting and I
> won't stand for it.
> PPS - I don't have a preference, I'm a chair.
> -- 
>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                        
>  +1-703-227-9854
> ARIN Research Engineer

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

Date: Thu, 5 Dec 2002 21:01:01 -0500
To: Hong Liu <[email-masked]>, [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Re: action items from our meeting in atlanta
Sender: [email-masked]

While I'm at it, this discussion will be added to the action items 
list I submit with the minutes.  The need to clean this up was 
something I missed when going through the minutes from Kim.  Perhaps 
because the room seemed pretty much decided - no one called for a 
move to the list.

At 21:43 -0800 12/4/02, Hong Liu wrote:
>There are two major issues that have been extensively
>discussed on the list:
>
>(1) handling of external host
>(2) handling of last-verified

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                    +1-703-227-9854
ARIN Research Engineer

Date: Thu, 5 Dec 2002 18:57:10 -0500
To: Hong Liu <[email-masked]>, [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Re: lastVerified: optional vs. extension
Sender: [email-masked]

Here's my metric:

Make it optional if
1) Everyone that will want to use it will do so in the same way and 
can agree on the syntax.
2) Everyone will want to be able to make use of it at some point - 
even if not regularly.
3) It's worth making a change to the core documents for this.

Make it an extension if
1) Not everyone agrees on what is should look like or how it should be used.
2) Not everyone will want the ability to make use of it.
Note that there is no #3 (would have been - it can be an extension 
after the core specs are at PS).  I won't say this because I refuse 
to consider extensions to a protocol that hasn't hit PS yet.

Everyone means 'all users of EPP clients, all users of EPP servers.' 
Implementer's opinions don't count here - except to argue over my 
choice of metrics.  Implementer's can report what they hear users 
saying.

The question isn't the goodness nor evilness of last-verified.  It's 
whether it is vital to the protocol.

PS - I refuse to poll the list.  That's voting and I won't stand for it.
PPS - I don't have a preference, I'm a chair.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

Date: Thu, 5 Dec 2002 13:22:40 -0800 (PST)
From: Hong Liu <[email-masked]>
Subject: lastVerified: optional vs. extension
To: [email-masked]
Sender: [email-masked]

Rick,

I think the same standards apply to both camps. I
already stated my position and my reasoning in a
previous posting [1]. I will further elaborate if need
be. The burden of proof lies on both sides. I want to
see the reasoning from you why this element _must_ be
in the base EPP instead of as an extension. And I want
to hear from you why the effectiveness of this element
can be assessed without an established policy
framework.

Just to be clear: I am not against the utility of this
element. This is a nice feature to have IF armed with
the right policy framework. However, as others have
pointed out, this is a nice-to-have, but _not_ a
must-have, feature [2]. Most importantly, AFAIK, there
is no established policy framework that ensures the
accuracy of the data. Without it, it will be
garbage-in and garbage-out. Just adding a new element
does not really solve the problem you try to solve.
Both points indicate that this element needs further
study before it is incorporated in EPP, and thus
should be treated as an extension rather than as a
element in the base protocol.

Let's have a constructive discussion on the list. Just
getting frustrated by different opinions and
countering with accusations does not help. Please,
despite of our differences, let's have a good dialogue
on this issue. I stand to be corrected and convinced.

Regards,

--Hong

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

[2]
http://www.cafax.se/ietf-provreg/maillist/2002-11/msg00052.html

--- Rick Wesson <[email-masked]> wrote:
> 
> Hong Liu,
> 
> don't hold back --  post your thoughts on how to
> handle this issue. There
> was allot of support in the room and in the halls so
> please be specific in
> your alternate proposal.
> 
> hand-waving and promises of your reasoning at a
> later date don't count.
> 
> -rick
> 
> On Thu, 5 Dec 2002, Hong Liu wrote:
> 
> > two people on the list are for extension, _and_
> gave good reasons for
> > why, -:) [1]. I am for it to be an extension. I
> will reiterate my
> > reasoning once the co-chairs poll the list.
> 
> 
> 

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

Date: Thu, 5 Dec 2002 15:12:45 -0500
Subject: format of contents of <domain:curExpDate>
From: Joe Abley <[email-masked]>
To: [email-masked]
Sender: [email-masked]

[the list got dropped from the recipient list, for some reason. 
possibly the recent onset of the Canadian winter has slowed my synapses 
:)]

Begin forwarded message:

> From: Joe Abley <[email-masked]>
> Date: Thu Dec 5, 2002  13:16:21 Canada/Eastern
> To: Edward Lewis <[email-masked]>
> Cc: [email-masked], "Hollenbeck, Scott" <[email-masked]>
> Subject: Re: format of contents of <domain:curExpDate>
>
>
> On Thursday, Dec 5, 2002, at 10:06 Canada/Eastern, Edward Lewis wrote:
>
>> In either case, I'd certainly encourage Joe to re-raise this as an 
>> implementation consideration after we hit Proposed Standard.  This 
>> isn't an issue that is dead in the water, but it is one that is not 
>> sufficient to make us rethink the current drafts.
>
> I will make sure it is on our list.
>
> As I mentioned, though, my primary concern when I raised the issue 
> before was that it introduced a real operational problem. The 
> operational problem I described turned out not to exist, after more 
> thorough reading of the spec.
>
> If the decision is made to apply the suggested change after PS, it 
> would probably need to be lumped in with other, more substantial 
> changes; otherwise the version bump in the domain object schema would 
> impose an amount of work on server implementators which was much 
> larger than the (largely cosmetic) benefit of the revision.
>
>
> Joe
>

Date: Thu, 5 Dec 2002 12:09:34 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: Hong Liu <[email-masked]>
cc: <[email-masked]>
Subject: RE: action items from our meeting in atlanta
Sender: [email-masked]

Hong Liu,

don't hold back --  post your thoughts on how to handle this issue. There
was allot of support in the room and in the halls so please be specific in
your alternate proposal.

hand-waving and promises of your reasoning at a later date don't count.

-rick

On Thu, 5 Dec 2002, Hong Liu wrote:

> two people on the list are for extension, _and_ gave good reasons for
> why, -:) [1]. I am for it to be an extension. I will reiterate my
> reasoning once the co-chairs poll the list.

Date: Thu, 05 Dec 2002 15:09:29 -0500
To: "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, [email-masked]
From: Richard Shockey <[email-masked]>
Subject: RE: action items from our meeting in atlanta
Cc: [email-masked]
Sender: [email-masked]

A
> >
> > I'm doubtful that an answer saying 'we'll issue guidelines on this in
> > another (future) document' will settle these two items.  We need to
> > address these two directly to "pass."  However, it seems to me that
> > it would be a really good idea to have guidelines for privacy
> > extensions at some point - but I don't think that the promise of this
> > will qualify as a answer.
>
>This is the one I was talking about, but I'm not suggesting guidelines --
>I'm talking about a real protocol extension.  You may be right about Randy's
>desire, but so far there's been no WG support for the idea of tagging
>individual elements as suggested by the IESG.

exactly ... IMHO this is a major potential rat hole and before we start 
crawling down this path the IESG should make it very very clear what they 
are looking for and that they have a clear understanding that this is not a 
simple issue.

If W3C cant get their act together on these things .. its not going to be 
any easier for us.

BTW here are the notes from the W3C workshop on extending P3P held last 
month in Dulles,VA

#############

Dear all,

it has taken a while to publish the minutes as I was travelling and
became sick and had to recover.

But the minutes are finally published. There is no summary report yet.

The minutes are under:
http://www.w3.org/2002/p3p-ws/minutes/

but they are also linked from the Workshop - Homepage:
http://www.w3.org/2002/p3p-ws/

Best,
-- 
Rigo Wenning            W3C/INRIA
Policy Analyst          Privacy Activity Lead
mail:[email-masked]        2004, Routes des Lucioles
http://www.w3.org/      F-06902 Sophia Antipolis

>-Scott-

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

Date: Thu, 5 Dec 2002 11:49:54 -0800 (PST)
From: Hong Liu <[email-masked]>
Subject: RE: action items from our meeting in atlanta
To: [email-masked]
Sender: [email-masked]

Scott,

Please see my comments below. Cheers,

--Hong

--- "Hollenbeck, Scott" <[email-masked]>
wrote:
> > (1) handling of external host
> > (2) handling of last-verified
> > 
> > I would like to see a closure on each one.
> 
> Janusz's proposal [1] has had some support with no
> negative push-back so
> far.  Does it work for everyone?
> 
On a high level, Janusz's proposal seems fine with me.
I would like to see the actual texts in the spec and
check for consistency when they become available.

> The overwhelming feeling of the room in Atlanta was
> that the lastVerified
> element could be added as an optional contact
> element.  If you disagree,
> maybe we need a chair measurement of rough
> consensus.
> 
Not being in Atlanta in person, I am not in the
position to judge the feeling in the room. By reading
the draft meeting minutes, I did not get a sense of
the feeling for making lastVerified optional as
overwhelming. What I saw was that people did not want
it to be mandatory. But that does not automatically
translate into making it optional. There is a third
alternative: making it as an extension.

If I understand correctly, IETF WG decisions are made
via the mailing list. I would like the co-chairs to
poll on the list on this issue: optional vs.
extension. I will leave it to our co-chairs to
formulate the question to the list. So far, at least
two people on the list are for extension, _and_ gave
good reasons for why, -:) [1]. I am for it to be an
extension. I will reiterate my reasoning once the
co-chairs poll the list.

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

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

Date: Thu, 5 Dec 2002 11:20:32 -0500
To: "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, [email-masked]
From: Edward Lewis <[email-masked]>
Subject: RE: action items from our meeting in atlanta
Cc: [email-masked]
Sender: [email-masked]

Whether we promise guidelines or promise an extension, it's still a 
promise.  And I'm doubtful that a promise will be satisfactory.

Now, as to what it would take to answer Randy's comment, I'm not 
certain that we need a fully developed solution (meaning we don't try 
to solve the world's privacy policy expression problems) but a means 
to express policy statements at a finer grain that we now have.

At 11:00 -0500 12/5/02, Hollenbeck, Scott wrote:
>>  2) Randy's wanting more granularity in contact and
>>  <off-hand-it-escapes-me>
>>
>>  I'm doubtful that an answer saying 'we'll issue guidelines on this in
>>  another (future) document' will settle these two items.  We need to
>>  address these two directly to "pass."  However, it seems to me that
>>  it would be a really good idea to have guidelines for privacy
>>  extensions at some point - but I don't think that the promise of this
>>  will qualify as a answer.
>
>This is the one I was talking about, but I'm not suggesting guidelines --
>I'm talking about a real protocol extension.  You may be right about Randy's
>desire, but so far there's been no WG support for the idea of tagging
>individual elements as suggested by the IESG.
>
>-Scott-

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: action items from our meeting in atlanta
Date: Thu, 5 Dec 2002 11:00:33 -0500 
Sender: [email-masked]

> 1) Allison's wanting us to clarify the 'marketing' thing.  (I'm 
> deeply paraphrasing here - folks should look at the comment as it 
> appears in the archive).

I think I can handle this one in text.  All she really asked for was
clarification.

> 2) Randy's wanting more granularity in contact and 
> <off-hand-it-escapes-me>
> 
> I'm doubtful that an answer saying 'we'll issue guidelines on this in 
> another (future) document' will settle these two items.  We need to 
> address these two directly to "pass."  However, it seems to me that 
> it would be a really good idea to have guidelines for privacy 
> extensions at some point - but I don't think that the promise of this 
> will qualify as a answer.

This is the one I was talking about, but I'm not suggesting guidelines --
I'm talking about a real protocol extension.  You may be right about Randy's
desire, but so far there's been no WG support for the idea of tagging
individual elements as suggested by the IESG.

-Scott-

Date: Thu, 5 Dec 2002 10:37:38 -0500
To: "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, [email-masked]
From: Edward Lewis <[email-masked]>
Subject: RE: action items from our meeting in atlanta
Cc: [email-masked]
Sender: [email-masked]

At 8:53 -0500 12/5/02, Hollenbeck, Scott wrote:
>Ed, what do you think about the idea of a WG task to come up with some sort
>of a privacy extension?  If the IESG goes for that we can separate the issue
>from the rest of the documents (which allows them to progress) while still
>dealing with the issue.

Hmmmm (as opposed to hummmm;) ),

Seems to me that this looks like a promising way to go, but I don't 
know if this will mollify the IESG comments we have to date.  We just 
have two privacy ones and they are slight comments:

1) Allison's wanting us to clarify the 'marketing' thing.  (I'm 
deeply paraphrasing here - folks should look at the comment as it 
appears in the archive).

and

2) Randy's wanting more granularity in contact and <off-hand-it-escapes-me>

I'm doubtful that an answer saying 'we'll issue guidelines on this in 
another (future) document' will settle these two items.  We need to 
address these two directly to "pass."  However, it seems to me that 
it would be a really good idea to have guidelines for privacy 
extensions at some point - but I don't think that the promise of this 
will qualify as a answer.

That's my co-chair answer based on 'process' and not technical content.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

Reply-To: "Ross Wm. Rader" <[email-masked]>
From: "Ross Wm. Rader" <[email-masked]>
To: "Rick Wesson" <[email-masked]>, "Richard Shockey" <[email-masked]>
Cc: "Edward Lewis" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: action items from our meeting in atlanta
Date: Thu, 5 Dec 2002 09:53:52 -0500
Organization: Tucows Inc.
Sender: [email-masked]

heh...Rick pointed out that my last message made less than sense...:)

Take two: Is there any reason why this can't be parallel tracked? Or did I
miss something important? I mean there's nothing stopping us from continuing
with clean-up in the way that you and Rick are proposing while seeking the
guidance that we need. The two don't strike me as being mutually exclusive
or oppositive. Its a pain in the ass (my earlier point), but probably
necessary.

Feel free to ignore if this one also makes less than sense.

                     -rwr

Got Blog? http://www.byte.org/blog

"People demand freedom of speech as a compensation for the freedom of
thought which they seldom use."
 - Soren Kierkegaard

----- Original Message -----
From: "Richard Shockey" <[email-masked]>
To: "Rick Wesson" <[email-masked]>
Cc: "Edward Lewis" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, December 04, 2002 9:36 PM
Subject: Re: action items from our meeting in atlanta

> At 05:24 PM 12/4/2002 -0800, Rick Wesson wrote:
>
> >Rich,
> >
> >On Wed, 4 Dec 2002, Richard Shockey wrote:
> > >
> > > again I'd love to do it really .. I'm open minded, ..but how to do it
is a
> > > general architectural issue that IAB/IESG should provide guidance on.
IMHO
> > > this is a much larger issue the IETF will have to confront sooner
rather
> > > than later.
> >
> >I propose we use our extention mechs thats what its there for,
> >addressing unknown requirements....
> >
> >I'm wokring on a P3Pish example, if folks think that would help explain
> >this position.
>
> good, great .. but there are much larger issues here and it is in our
> collective interest to ask IESG/IAB on guidance
>
> your suggestion and examples would be most useful in a note to upper
> management types if our chairs believe this is a useful thing to do.
>
>
> >-rick
>
>
>  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Richard Shockey, Senior Manager, Strategic Technology Initiatives
> NeuStar Inc.
> 46000 Center Oak Plaza  -   Sterling, VA  20166
> Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
> <mailto:[email-masked]> or <mailto:[email-masked]>
>   <http://www.neustar.biz> ; <http://www.enum.org>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: action items from our meeting in atlanta
Date: Thu, 5 Dec 2002 08:53:28 -0500 
Sender: [email-masked]

> 1. Respond to the IESG comments.
> 
> Most of the comments are easily addressed.  A few need further 
> discussion (and are listed as separate action items).

Ed, what do you think about the idea of a WG task to come up with some sort
of a privacy extension?  If the IESG goes for that we can separate the issue
from the rest of the documents (which allows them to progress) while still
dealing with the issue.

There has been some work in the W3C [1] to describe a P3P preference
exchange language.  Maybe there's something there that we could use.

-Scott-

[1]
http://www.w3.org/TR/P3P-preferences/

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Hong Liu'" <[email-masked]>, [email-masked]
Subject: RE: action items from our meeting in atlanta
Date: Thu, 5 Dec 2002 08:49:07 -0500 
Sender: [email-masked]

> (1) handling of external host
> (2) handling of last-verified
> 
> I would like to see a closure on each one.

Janusz's proposal [1] has had some support with no negative push-back so
far.  Does it work for everyone?

The overwhelming feeling of the room in Atlanta was that the lastVerified
element could be added as an optional contact element.  If you disagree,
maybe we need a chair measurement of rough consensus.

-Scott-

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

Reply-To: "Ross Wm. Rader" <[email-masked]>
From: "Ross Wm. Rader" <[email-masked]>
To: "Rick Wesson" <[email-masked]>, "Richard Shockey" <[email-masked]>
Cc: "Edward Lewis" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: action items from our meeting in atlanta
Date: Thu, 5 Dec 2002 01:10:40 -0500
Organization: Tucows Inc.
Sender: [email-masked]

> good, great .. but there are much larger issues here and it is in our
> collective interest to ask IESG/IAB on guidance
>
> your suggestion and examples would be most useful in a note to upper
> management types if our chairs believe this is a useful thing to do.

Richard,

This is the second time this week that upper management types have asked me
to provide them with guidance so that they can determine what I think.

For the second time, I don't like it, even if I am wrong.

                     -rwr

Got Blog? http://www.byte.org/blog

"People demand freedom of speech as a compensation for the freedom of
thought which they seldom use."
 - Soren Kierkegaard

----- Original Message -----
From: "Richard Shockey" <[email-masked]>
To: "Rick Wesson" <[email-masked]>
Cc: "Edward Lewis" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, December 04, 2002 9:36 PM
Subject: Re: action items from our meeting in atlanta

> At 05:24 PM 12/4/2002 -0800, Rick Wesson wrote:
>
> >Rich,
> >
> >On Wed, 4 Dec 2002, Richard Shockey wrote:
> > >
> > > again I'd love to do it really .. I'm open minded, ..but how to do it
is a
> > > general architectural issue that IAB/IESG should provide guidance on.
IMHO
> > > this is a much larger issue the IETF will have to confront sooner
rather
> > > than later.
> >
> >I propose we use our extention mechs thats what its there for,
> >addressing unknown requirements....
> >
> >I'm wokring on a P3Pish example, if folks think that would help explain
> >this position.
>
> good, great .. but there are much larger issues here and it is in our
> collective interest to ask IESG/IAB on guidance
>
> your suggestion and examples would be most useful in a note to upper
> management types if our chairs believe this is a useful thing to do.
>
>
> >-rick
>
>
>  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Richard Shockey, Senior Manager, Strategic Technology Initiatives
> NeuStar Inc.
> 46000 Center Oak Plaza  -   Sterling, VA  20166
> Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
> <mailto:[email-masked]> or <mailto:[email-masked]>
>   <http://www.neustar.biz> ; <http://www.enum.org>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>

Reply-To: "Ross Wm. Rader" <[email-masked]>
From: "Ross Wm. Rader" <[email-masked]>
To: "Rick Wesson" <[email-masked]>, "Richard Shockey" <[email-masked]>
Cc: "Edward Lewis" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: action items from our meeting in atlanta
Date: Thu, 5 Dec 2002 01:08:36 -0500
Organization: Tucows Inc.
Sender: [email-masked]

> I propose we use our extention mechs thats what its there for,
> addressing unknown requirements....
>

That make complete sense to poor bus'nocrats like me, methinks.

Completely agree with this one (he says quietly whilst trying not to draw
attention to the fact that he hasn't posted for eight months)

                     -rwr

Got Blog? http://www.byte.org/blog

"People demand freedom of speech as a compensation for the freedom of
thought which they seldom use."
 - Soren Kierkegaard

----- Original Message -----
From: "Rick Wesson" <[email-masked]>
To: "Richard Shockey" <[email-masked]>
Cc: "Edward Lewis" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, December 04, 2002 8:24 PM
Subject: Re: action items from our meeting in atlanta

>
> Rich,
>
> On Wed, 4 Dec 2002, Richard Shockey wrote:
> >
> > again I'd love to do it really .. I'm open minded, ..but how to do it is
a
> > general architectural issue that IAB/IESG should provide guidance on.
IMHO
> > this is a much larger issue the IETF will have to confront sooner rather
> > than later.
>
> I propose we use our extention mechs thats what its there for,
> addressing unknown requirements....
>
> I'm wokring on a P3Pish example, if folks think that would help explain
> this position.
>
> -rick
>
>

Date: Wed, 4 Dec 2002 21:43:31 -0800 (PST)
From: Hong Liu <[email-masked]>
Subject: Re: action items from our meeting in atlanta
To: [email-masked]
Sender: [email-masked]

Ed,

Thanks for the summary. Please see my comments below.

Cheers,

--Hong

--- Edward Lewis <[email-masked]> wrote:
[snip...]
> 
> 4. Whether or not we adopt a work item for the SOAP
> 'as transport' draft.
> 
> A thread has been started on the list, but the
> results are luke warm for now.
> 

I would like to continue this work with a new
revision. I am just being distracted by other work
right now, but should be able to update the draft
before xmas.

> 
> 8. Other items.
> 
> Some other items are being brought to the list.  I'd
> like to clear 
> them up given that we want to complete #1.
>
There are two major issues that have been extensively
discussed on the list:

(1) handling of external host
(2) handling of last-verified

I would like to see a closure on each one.

> -- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                        
>  +1-703-227-9854
> ARIN Research Engineer

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

Date: Wed, 04 Dec 2002 21:36:11 -0500
To: Rick Wesson <[email-masked]>
From: Richard Shockey <[email-masked]>
Subject: Re: action items from our meeting in atlanta
Cc: Edward Lewis <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 05:24 PM 12/4/2002 -0800, Rick Wesson wrote:

>Rich,
>
>On Wed, 4 Dec 2002, Richard Shockey wrote:
> >
> > again I'd love to do it really .. I'm open minded, ..but how to do it is a
> > general architectural issue that IAB/IESG should provide guidance on.  IMHO
> > this is a much larger issue the IETF will have to confront sooner rather
> > than later.
>
>I propose we use our extention mechs thats what its there for,
>addressing unknown requirements....
>
>I'm wokring on a P3Pish example, if folks think that would help explain
>this position.

good, great .. but there are much larger issues here and it is in our 
collective interest to ask IESG/IAB on guidance

your suggestion and examples would be most useful in a note to upper 
management types if our chairs believe this is a useful thing to do.

>-rick

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

Date: Wed, 4 Dec 2002 21:10:35 -0500
Subject: Re: action items from our meeting in atlanta
Cc: [email-masked], [email-masked]
To: Edward Lewis <[email-masked]>
From: Joe Abley <[email-masked]>
Sender: [email-masked]

On Wednesday, Dec 4, 2002, at 17:59 Canada/Eastern, Edward Lewis wrote:

> 5. An SMTP mapping is all but dead in the water.
>
> Unless someone objects on the mail list, we're dropping all milestones 
> relating to SMTP.

This is certainly fine by us. None of the registries we have talked to 
have expressed any interest in doing EPP over SMTP.

> 8. Other items.
>
> Some other items are being brought to the list.  I'd like to clear 
> them up given that we want to complete #1.

We have a few outstanding issues with the current drafts, some of which 
we feel might be sufficiently interesting to warrant changes to the 
drafts before they proceed to draft standard. We are knee-deep in an 
impending code release right now, however, so we probably won't be able 
to make a useful summary of them until next week.

Joe

Date: Wed, 4 Dec 2002 17:24:56 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: Richard Shockey <[email-masked]>
cc: Edward Lewis <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: action items from our meeting in atlanta
Sender: [email-masked]

Rich,

On Wed, 4 Dec 2002, Richard Shockey wrote:
>
> again I'd love to do it really .. I'm open minded, ..but how to do it is a
> general architectural issue that IAB/IESG should provide guidance on.  IMHO
> this is a much larger issue the IETF will have to confront sooner rather
> than later.

I propose we use our extention mechs thats what its there for,
addressing unknown requirements....

I'm wokring on a P3Pish example, if folks think that would help explain
this position.

-rick

Date: Wed, 04 Dec 2002 19:47:41 -0500
To: Edward Lewis <[email-masked]>, [email-masked]
From: Richard Shockey <[email-masked]>
Subject: Re: action items from our meeting in atlanta
Cc: Edward Lewis <[email-masked]>, [email-masked]
Sender: [email-masked]

At 05:59 PM 12/4/2002 -0500, Edward Lewis wrote:
>In general action items (meaning - the WG needs to do this, except for 
>where someone's name appears):
>
>1. Respond to the IESG comments.
>
>Most of the comments are easily addressed.  A few need further discussion 
>(and are listed as separate action items).

as for 1 it relates in part to 3 and IMHO it is clear we need some IESG 
clarification or statement of direction here on how / if / when to add 
privacy tags to user collected data.

in principal I'm all for this but as a practical matter it could delay the 
existing work and considering how W3C may or may not be going in that 
direction I just do not think its a good idea for IESG to place a 
requirement here

again I'd love to do it really .. I'm open minded, ..but how to do it is a 
general architectural issue that IAB/IESG should provide guidance on.  IMHO 
this is a much larger issue the IETF will have to confront sooner rather 
than later.

given the fluid US OECD and EC policy swamp

Ed , Japp ...my suggestion is a carefully constructed note to upper 
management that there is a problem here...If you want my help in text ... 
privately let me know and I'll be happy to frame the problem statement and 
issues.

I smell sandtraps and ratholes here it took years for W3C to get any 
consensus on the puny little protocol they came up with

provreg IMHO is not the WG for constructing data privacy protocols in XML 
objects

geopriv is struggling with these issues as it is and it is very very rough 
sledding.

honorable work but do we want to go there?

>2. Come to a final understanding of UDP and EPP.
>
>There have been some words posted to the "outlawing" of UDP, one response 
>was to require stream based protocols.

outlaw UDP  .. my vote for what its worth

>3. Clarify the adoption of P3P concepts.
>
>P3P was written for website environments, not a business to business 
>situation.  This is reflected in some of our examples and needs to be 
>cleaned up.
>
>Rick Wesson volunteered to summarize a discussion on privacy issues. It 
>might be up to us to forge new ground here as we are one of the few 
>protocols that gathers personal information (for registration information).

Ok we can tackle this but the if privacy issues are to be a IESG 
requirement I think that calls for charter review and they should make that 
requirement clear.

>4. Whether or not we adopt a work item for the SOAP 'as transport' draft.
>
>A thread has been started on the list, but the results are luke warm for now.

I wont mouth off on this anymore..

>5. An SMTP mapping is all but dead in the water.
>
>Unless someone objects on the mail list, we're dropping all milestones 
>relating to SMTP.

good idea.

>6. Continue to progress on Guidelines.
>
>No sense of urgency, at least not until we get #1 above done.
>
>Two other action items...
>
>7. Clean up the milestones.
>
>After the meeting we talked and decided that the milestones on the web 
>page aren't sufficiently descriptive.  Before fixing them, #4 and #5 need 
>answers.
>
>8. Other items.
>
>Some other items are being brought to the list.  I'd like to clear them up 
>given that we want to complete #1.
>--
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Edward Lewis                                          +1-703-227-9854
>ARIN Research Engineer

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

Date: Wed, 4 Dec 2002 17:59:00 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: action items from our meeting in atlanta
Cc: Edward Lewis <[email-masked]>, [email-masked]
Sender: [email-masked]

In general action items (meaning - the WG needs to do this, except 
for where someone's name appears):

1. Respond to the IESG comments.

Most of the comments are easily addressed.  A few need further 
discussion (and are listed as separate action items).

2. Come to a final understanding of UDP and EPP.

There have been some words posted to the "outlawing" of UDP, one 
response was to require stream based protocols.

3. Clarify the adoption of P3P concepts.

P3P was written for website environments, not a business to business 
situation.  This is reflected in some of our examples and needs to be 
cleaned up.

Rick Wesson volunteered to summarize a discussion on privacy issues. 
It might be up to us to forge new ground here as we are one of the 
few protocols that gathers personal information (for registration 
information).

4. Whether or not we adopt a work item for the SOAP 'as transport' draft.

A thread has been started on the list, but the results are luke warm for now.

5. An SMTP mapping is all but dead in the water.

Unless someone objects on the mail list, we're dropping all 
milestones relating to SMTP.

6. Continue to progress on Guidelines.

No sense of urgency, at least not until we get #1 above done.

Two other action items...

7. Clean up the milestones.

After the meeting we talked and decided that the milestones on the 
web page aren't sufficiently descriptive.  Before fixing them, #4 and 
#5 need answers.

8. Other items.

Some other items are being brought to the list.  I'd like to clear 
them up given that we want to complete #1.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

Date: Tue, 3 Dec 2002 07:27:21 -0500
Subject: Re: <!DOCTYPE> declaration
Cc: [email-masked]
To: "Hollenbeck, Scott" <[email-masked]>
From: Joe Abley <[email-masked]>
Sender: [email-masked]

On Tuesday, Dec 3, 2002, at 07:22 Canada/Eastern, Hollenbeck, Scott 
wrote:

>> http://www.w3.org/TR/REC-xml#sec-prolog-dtd
>>
>> "Definition: An XML document is valid if it has an associated
>> document
>> type declaration and if the document complies with the constraints
>> expressed in it."
>
> The XML specs were written with DTD validation in mind, before XML 
> Schema
> existed.  XML Schema rewrites some of the earlier validation rules, 
> but the
> intent of the <!DOCTYPE> element is still present in the way the 
> instance
> document describes both the namespaces and the schema as part of the 
> first
> element.

Excellent, thanks for the clue.

Joe

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Joe Abley'" <[email-masked]>
Cc: [email-masked]
Subject: RE: <!DOCTYPE> declaration
Date: Tue, 3 Dec 2002 07:22:54 -0500 
Sender: [email-masked]

> On Tuesday, Dec 3, 2002, at 07:08 Canada/Eastern, Hollenbeck, Scott 
> wrote:
> 
> > The <!DOCTYPE> element is not used in XML Schema instances 
> -- it's only
> > needed when a DTD is used to validate the document.  All of the 
> > examples are
> > both well-formed and valid, and you can confirm that by 
> running them 
> > through
> > a validating parser like Xerces-J.
> 
> Right, they definitely don't look like they contain errors.
> 
> What is confusing me is that the XML spec is quite specific in saying 
> that for a document to be valid, it MUST have a <!DOCTYPE> 
> declaration 
> as its first element. That makes me wonder whether validating 
> parsers, 
> following the letter of the spec, might mark them all invalid 
> for that 
> reason.
> 
> http://www.w3.org/TR/REC-xml#sec-prolog-dtd
> 
> "Definition: An XML document is valid if it has an associated 
> document 
> type declaration and if the document complies with the constraints 
> expressed in it."

The XML specs were written with DTD validation in mind, before XML Schema
existed.  XML Schema rewrites some of the earlier validation rules, but the
intent of the <!DOCTYPE> element is still present in the way the instance
document describes both the namespaces and the schema as part of the first
element.

Like I said, though, you can confirm that a validating parser that
understands XML Schema will digest the examples properly by simply parsing
the examples.  You can find files (to save copying and pasting time) here:

http://www.verisign-grs.com/files/

and here:

ftp://ftp.verisign.com/pub/epp/

-Scott-

Date: Tue, 3 Dec 2002 07:16:51 -0500
Subject: Re: <!DOCTYPE> declaration
Cc: [email-masked]
To: "Hollenbeck, Scott" <[email-masked]>
From: Joe Abley <[email-masked]>
Sender: [email-masked]

On Tuesday, Dec 3, 2002, at 07:08 Canada/Eastern, Hollenbeck, Scott 
wrote:

> The <!DOCTYPE> element is not used in XML Schema instances -- it's only
> needed when a DTD is used to validate the document.  All of the 
> examples are
> both well-formed and valid, and you can confirm that by running them 
> through
> a validating parser like Xerces-J.

Right, they definitely don't look like they contain errors.

What is confusing me is that the XML spec is quite specific in saying 
that for a document to be valid, it MUST have a <!DOCTYPE> declaration 
as its first element. That makes me wonder whether validating parsers, 
following the letter of the spec, might mark them all invalid for that 
reason.

http://www.w3.org/TR/REC-xml#sec-prolog-dtd

"Definition: An XML document is valid if it has an associated document 
type declaration and if the document complies with the constraints 
expressed in it."

Joe

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Joe Abley'" <[email-masked]>, [email-masked]
Subject: RE: <!DOCTYPE> declaration
Date: Tue, 3 Dec 2002 07:08:25 -0500 
Sender: [email-masked]

Joe,

The <!DOCTYPE> element is not used in XML Schema instances -- it's only
needed when a DTD is used to validate the document.  All of the examples are
both well-formed and valid, and you can confirm that by running them through
a validating parser like Xerces-J.

-Scott- 

> -----Original Message-----
> From: Joe Abley [mailto:[email-masked]]
> Sent: Tuesday, December 03, 2002 5:23 AM
> To: [email-masked]
> Subject: <!DOCTYPE> declaration
> 
> 
> My reading of the W3C XML spec seems to suggest that all the request 
> and response documents in the current drafts are well-formed, 
> but none 
> of them are valid (in the XML sense) since none of them include a 
> <!DOCTYPE> declaration as their first element.
> 
> My experience with XML parsers is somewhat light, but it seems 
> reasonable to me that a valid document is more likely to play nicely 
> with a validating parser than an invalid document.
> 
> Seems to me like there might be an argument for requiring 
> that request 
> and response documents MUST be valid (and hence include a <!DOCTYPE> 
> element). Alternatively, it could be specified that clients 
> and servers 
> MUST accept a <!DOCTYPE> element if it's present.
> 
> In any case, I think some mention needs to be made of <!DOCTYPE> 
> declarations, unless I am suffering delusions about what the 
> standalone="no" attribute means in the <?xml> decl.
> 
> 
> Joe

Date: Tue, 3 Dec 2002 05:23:14 -0500
Subject: <!DOCTYPE> declaration
From: Joe Abley <[email-masked]>
To: [email-masked]
Sender: [email-masked]

My reading of the W3C XML spec seems to suggest that all the request 
and response documents in the current drafts are well-formed, but none 
of them are valid (in the XML sense) since none of them include a 
<!DOCTYPE> declaration as their first element.

My experience with XML parsers is somewhat light, but it seems 
reasonable to me that a valid document is more likely to play nicely 
with a validating parser than an invalid document.

Seems to me like there might be an argument for requiring that request 
and response documents MUST be valid (and hence include a <!DOCTYPE> 
element). Alternatively, it could be specified that clients and servers 
MUST accept a <!DOCTYPE> element if it's present.

In any case, I think some mention needs to be made of <!DOCTYPE> 
declarations, unless I am suffering delusions about what the 
standalone="no" attribute means in the <?xml> decl.

Joe

Date: Mon, 2 Dec 2002 23:38:12 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Joe Abley'" <[email-masked]>, <[email-masked]>
Subject: RE: "ok" status on domains (and other objects)
Sender: [email-masked]

There are more pressures than can be percieved for these drafts to be
published. We move should forward with what we have and work on
interoability and publishing a BCP on running EPP based name registries.

-rick

On Mon, 2 Dec 2002, Hollenbeck, Scott wrote:

> > I think the spec needs to be well-done before it is published as an
> > RFC. At the moment it seems medium-rare.
>
> I disagree for the very reasons cited by Ed.  We're bound to uncover issues
> as people gain additional implementation experience, but that's the whole
> reason that the IETF has a process for moving to "proposed" and "draft"
> standard status.  Plus, given that multiple other implementers have
> developed software to earlier (and ongoing) versions of the specs without
> raising the "concerns" that you have, I'd say "medium-rare" is a
> mischaracterization.
>
> -Scott-
>

Date: Mon, 2 Dec 2002 23:31:21 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: Richard Shockey <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: milestones, was Re: a week later...
Sender: [email-masked]

Richard,

On Mon, 2 Dec 2002, Richard Shockey wrote:

> At 09:32 AM 12/2/2002 -0800, Rick Wesson wrote:
>
> > >
> > > Given that SOAP is still evolving, putting this on the experimental track
> > > might make sense if there's really sufficient implementation interest.
>
> I certainly would have no objection to experimental track.. I just hope
> folks will understand that over time the uses for this protocol may expand
> ...and as such people MAY wish to use transport layers that have a wider
> base of support and tool kits available.
>
> Over time I think folks will see the value of this work ..

I understand where you are comming from -- there is alot of general
interest in SOAP. So submit the I-D, the IESG is gonna ask us to take a
look at it any way.lets see the draft, there is nothing preventing you
from droping a copy to this list.

I think the number of things that can be provisioned over EPP is much
wider than this group has experence with. Having to manage a mult-ventor
SIP phone deployment is just one such endevor I'd love to see some folks
EPP standardize, but not in this wg. Lets charter specific groups to do
specific work.

best,

-rick

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Joe Abley'" <[email-masked]>
Cc: [email-masked]
Subject: RE: "ok" status on domains (and other objects)
Date: Mon, 2 Dec 2002 20:10:42 -0500 
Sender: [email-masked]

> I think the spec needs to be well-done before it is published as an 
> RFC. At the moment it seems medium-rare.

I disagree for the very reasons cited by Ed.  We're bound to uncover issues
as people gain additional implementation experience, but that's the whole
reason that the IETF has a process for moving to "proposed" and "draft"
standard status.  Plus, given that multiple other implementers have
developed software to earlier (and ongoing) versions of the specs without
raising the "concerns" that you have, I'd say "medium-rare" is a
mischaracterization.

-Scott-

Date: Mon, 02 Dec 2002 16:35:59 -0500
To: Rick Wesson <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
From: Richard Shockey <[email-masked]>
Subject: RE: milestones, was Re: a week later...
Cc: "'Edward Lewis'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 09:32 AM 12/2/2002 -0800, Rick Wesson wrote:

> >
> > Given that SOAP is still evolving, putting this on the experimental track
> > might make sense if there's really sufficient implementation interest.

I certainly would have no objection to experimental track.. I just hope 
folks will understand that over time the uses for this protocol may expand 
..and as such people MAY wish to use transport layers that have a wider 
base of support and tool kits available.

Over time I think folks will see the value of this work ..

>I'd go one step further... an individual submission is ok too.
>
>I wouldn't be sad to see this group go into hybernation or declare success
>and close. I hope the mailing list would continue but let the IETF work
>finish.
>
>I will implement a EPP over SOAP+HTTPS should someone draft something
>up. I'm all for interopability but if there is just two folks looking at
>running this stuff I don't see the need to task the wg with the burdon of
>a standards track document.
>
>let the SOAP draft be an individual submission of an experemental
>protocol.
>
>best,
>
>
>-rick

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

Date: Mon, 2 Dec 2002 16:04:52 -0500
Subject: Re: "ok" status on domains (and other objects)
Cc: Michael Graff <[email-masked]>, [email-masked]
To: Edward Lewis <[email-masked]>
From: Joe Abley <[email-masked]>
Sender: [email-masked]

On Monday, Dec 2, 2002, at 14:30 Canada/Eastern, Edward Lewis wrote:

> At 18:25 +0000 12/2/02, Michael Graff wrote:
>> Once it gains RFC level, regardless of how firm the mud is, people 
>> tend to
>> point at it and say "but the RFC says..." and worse, "but the 
>> implementations
>> all do..."  The latter isn't bad, for "it's as good, but different" 
>> but is
>> IMHO a serious mistake to have for things that can be added later, 
>> once
>> they are more thought out.
>
> The problem is that the IETF has traditionally done a poor job of 
> setting expectations.  Perhaps provreg should take it upon ourselves 
> to add a note to the introduction to our documents to reinforce what 
> is said in 2026.  I don't know, I'm just saying.  The reason I think 
> that this may be applicable here is that a lot of the folks reading 
> and implementing to the documents haven't been properly warned of the 
> limitations of what an RFC is and what the standards level mean.

I don't think we can assume that TLD managers are going to read the RFC 
before they start referring to it in the "Required Compliance" sections 
of their RFPs.

In the eyes of RFP-writers, I think "RFC 8192" rolls off the tongue 
nicely and has the feeling of standardisation about it. On the other 
hand, "RFC 8192 with Michael's proposed changes to deal with the ROID 
issue, not the original idea but the one he posted after Scott 
commented on his first proposal; oh, and we want to be able to delete 
an authinfo attribute from a domain, which RFC 8192 does not allow" 
sounds decidedly non-standard and awkward.

If we wind up with twenty registries all supporting different 
variations on whatever description of EPP is first published in the RFC 
series, then we're not tremendously advanced on where we are today. 
Registrars will still need custom code to talk to different registries, 
and registries will still face expensive migration exercises whenever 
they decide they need to move from one set of registry software to 
another.

I think the spec needs to be well-done before it is published as an 
RFC. At the moment it seems medium-rare.

Joe

Date: Mon, 2 Dec 2002 14:30:22 -0500
To: Michael Graff <[email-masked]>, Edward Lewis <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: "ok" status on domains (and other objects)
Cc: [email-masked]
Sender: [email-masked]

At 18:25 +0000 12/2/02, Michael Graff wrote:
>Once it gains RFC level, regardless of how firm the mud is, people tend to
>point at it and say "but the RFC says..." and worse, "but the implementations
>all do..."  The latter isn't bad, for "it's as good, but different" but is
>IMHO a serious mistake to have for things that can be added later, once
>they are more thought out.

The problem is that the IETF has traditionally done a poor job of 
setting expectations.  Perhaps provreg should take it upon ourselves 
to add a note to the introduction to our documents to reinforce what 
is said in 2026.  I don't know, I'm just saying.  The reason I think 
that this may be applicable here is that a lot of the folks reading 
and implementing to the documents haven't been properly warned of the 
limitations of what an RFC is and what the standards level mean.

>Needless to say, most of the above is directed at the ROID stuff.

I ain't saying you are wrong.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

To: Edward Lewis <[email-masked]>
Cc: [email-masked]
Subject: Re: "ok" status on domains (and other objects)
From: Michael Graff <[email-masked]>
Date: 02 Dec 2002 18:25:57 +0000
Lines: 22
Sender: [email-masked]

Edward Lewis <[email-masked]> writes:

> The document set is currently close to reaching Proposed Standard
> state.  ("Close, but no cigar" can apply at any time.)  Once the
> documents reach this stage, they are still by no means "done."  Our
> Area Director, Patrik, asked that we stick around as a WG until the
> documents reach the Draft Standard state.

I understand the distinction here, but my concern is that putting something
that is, IMHO, very poorly thought out both in terms of implementation in
this protocol and how it will ever, indeed IF ever, be used in operation
is a serious mistake.

Once it gains RFC level, regardless of how firm the mud is, people tend to
point at it and say "but the RFC says..." and worse, "but the implementations
all do..."  The latter isn't bad, for "it's as good, but different" but is
IMHO a serious mistake to have for things that can be added later, once
they are more thought out.

Needless to say, most of the above is directed at the ROID stuff.

--Michael

Date: Mon, 2 Dec 2002 09:32:55 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Edward Lewis'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: milestones, was Re: a week later...
Sender: [email-masked]

>
> Given that SOAP is still evolving, putting this on the experimental track
> might make sense if there's really sufficient implementation interest.

I'd go one step further... an individual submission is ok too.

I wouldn't be sad to see this group go into hybernation or declare success
and close. I hope the mailing list would continue but let the IETF work
finish.

I will implement a EPP over SOAP+HTTPS should someone draft something
up. I'm all for interopability but if there is just two folks looking at
running this stuff I don't see the need to task the wg with the burdon of
a standards track document.

let the SOAP draft be an individual submission of an experemental
protocol.

best,

-rick

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: milestones, was Re: a week later...
Date: Mon, 2 Dec 2002 10:21:14 -0500 
Sender: [email-masked]

> (I admit that I don't have a list of the implementers handy, so I'll 
> call out names of the ones I can think of: Scott, Bruce, Dan, 
> Michael, Jordyn, as well as Hong and Rick - what do you guys think?)

I know that some of the VeriSign software developers are interested in SOAP
because tools are easy to find and allegedly easy to use.  I personally have
concerns from a performance perspective about adding additional XML and HTTP
layers, but I'll concede that there are probably environments in which ease
of development might outweigh performance.

Given that SOAP is still evolving, putting this on the experimental track
might make sense if there's really sufficient implementation interest.

-Scott-

Date: Mon, 2 Dec 2002 10:17:57 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: RE: "ok" status on domains (and other objects)
Sender: [email-masked]

As a chair, I should back up what Scott says.

The document set is currently close to reaching Proposed Standard 
state.  ("Close, but no cigar" can apply at any time.)  Once the 
documents reach this stage, they are still by no means "done."  Our 
Area Director, Patrik, asked that we stick around as a WG until the 
documents reach the Draft Standard state.

What often gets lost is what it means to "become an RFC", as well as 
what Proposed and Draft mean (I even reverse them myself).  Recall 
that an RFC is "Request For Comments" and not "A Standard."  An RFC 
is just a reviewed, perpetually archived document, as opposed to an 
ID.

A description on the Standard levels is in RFC 2026, but I won't bore 
folks with the trite "go read it."  I'll make a stab at abstracting 
the difference between PS and DS here.  To go from PS to DS, 
implementations appear, implementation issues are fed back to the 
documents, and an interoperability report is needed.  So, it is 
recognized that places in which a PS is unclear will pop up and be 
fixed on the way to DS.

But what happens when a change is more severe than an implementation 
adjustment.  This can force a document set to be published at PS 
again.  Good or bad?  Depends on whether you are more concerned about 
getting it right or getting it done.

One last point I want to make about changes.  Sometimes an issue will 
be settled in a WG and then come up again once new folks come along 
with a fresh perspective and find issues.  This might uncover a 
show-stopper that needs to be revisited and maybe even cause 
documents to be published again at the PS level.  Sometimes, however, 
the new approach might be better, but the existing approach is still 
sufficient.  In this case, it pays to stick with the old.  Recall 
that "sufficient" means that it meets the requirements.  The hard 
part here for the WG is to get the proponents of the new approach to 
realize "yeah, you're right, but..." without causing serious rifts.

So - if something is an implementation detail or clarification, no 
sweat.  If something is an improvement but the existing way is still 
good enough, let it lie.  If something is a show stopper, then we 
need to at least understand the impact.  At that point, we'll consult 
with our friendly AD (who is also an implementer here) and see how we 
want to progress.

To those thinking that we are done at "becoming an RFC" - be aware of 
what that means!

At 21:15 -0500 11/26/02, Hollenbeck, Scott wrote:
>We need to understand something: the protocol documents have almost
>completed IESG review.  I don't have a lot of liberty in making changes to
>documents that have completed both WG and IETF-wide last calls (other than
>dealing with editorial issues) unless _serious_ issues are discovered.  In
>my mind, _serious_ means that a large number of WG participants agree that
>something needs to be changed _now_ and the chairs declare that we have
>consensus on the need for such a change.
>
>The answer to your first question is "yes".  I will _try_ to deal with
>wordsmithing the text to more fully explain that the default "ok" status is
>set and unset as a result of other explicit status-setting operations.  I'm
>not open to the idea of changing status behavior unless we enter into the
>_serious_ issue state as described above.
>
>-Scott-

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

Date: Mon, 2 Dec 2002 10:00:03 -0500
To: Edward Lewis <[email-masked]>, [email-masked]
From: Edward Lewis <[email-masked]>
Subject: milestones, was Re: a week later...
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I've heard no replies to the message below.

During our meeting in Atlanta, two folks had expressed support for 
this effort.  One is the document editor (in abstentia) and the other 
is Rick Wesson.  I know that most of the other implementers were not 
able to make the meeting, so I want to get more discussion on the 
mailing list.

(I admit that I don't have a list of the implementers handy, so I'll 
call out names of the ones I can think of: Scott, Bruce, Dan, 
Michael, Jordyn, as well as Hong and Rick - what do you guys think?)

I also want to hear from those who constitute "users" that are 
listening in.  If you want this, say so.  If you want this, be 
prepared to press an implementer to say it will be done.  I'm 
sympathetic to the plight of folks who want something but are unable 
to find an implementer (be it a lack of money, etc.), but as a WG we 
really need to focus on solvable problems (and without 
implementation, there will be no solution).

The reason I'd like to kick off this discussion is that I want to fix 
our milestones (beyond just changing the dates) to give us a better 
sense of where we are going.  As part of this I want to know if the 
group should commit to one (or fewer) of the following:

     XXX 03 Submit EPP on SOAP to IESG for Proposed Standard
     XXX 03 Submit EPP on SOAP to IESG for Experimental

At 14:20 -0500 11/26/02, Edward Lewis wrote:
>...and I'm already more that a week behind the mailing list.
>
>What I want to address in the short term are the milestones for the 
>group.  The way we've listed milestones in the past has been "not 
>good enough."  I.e., our milestones should have something like 
>"submit document A to the IESG for proposed standard."
>
>The question I have is about the SOAP document.  In the face-to-face 
>meeting there was interest from two people in 
>implementing/supporting the effort.
>
>The question: do other implementors want to discuss this document as 
>part of the WG?
>
>I'm not asking if it is worthy, or whether it is to be, for some 
>version of the word, mandatory.  I just want to know if this is a 
>topic that is worthwhile for the WG's effort.  (A good idea that is 
>of interest to just one person does not need to involve a WG 
>discussion.)
>
>If the answer to the question is yes, then we'll have a milestone:
>    <some date> Submit EPP mapping to SOAP to IESG for Proposed Standard
>
>We can also declare it to be Experimental or just Informational too, 
>the PS label is used for demonstration purposes only.
>
>So, if you are interested in implementing a mapping to SOAP, please 
>state your case.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

Date: Mon, 2 Dec 2002 09:35:46 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: raw, uncooked notes from the meeting in Atlanta
Cc: [email-masked]
Sender: [email-masked]

Here are, in an unprocessed form, the notes taken by our scribe, Kim 
Davies, in Atlanta.  Comment on them should go to me.  Since the 
notes are so comprehensive, I'm working on adding an "action item" 
intro to them.  I was going to do this before send this to the list, 
but it seems that there's already been calls to see this by those 
unable to attend the meeting in person.

~~~~~~~~~~~

IETF provreg Working Group
==========================
9.00-11.30 Slot, IETF 55, 19 November 2002

Chairs: Ed Lewis and Jaap Akkerhuis
Author: Kim Davies

IESG Comments on EPP Drafts
---------------------------

Comments by Ed Lewis (EL)/Scott Hollenbeck (SH):

1. Do we place mailing list names and URLs in RFCs?
A: Removing that section.

2. Would like a stronger Security Considerations section, Wants it to say
    that that EPP "MUST NOT be used over a transport mechanism that does not
    provide confidentiality", or "All transport mappings for EPP..."
A: Incorporated. Clear text passwords are used, so privacy is required.

3. What is "authorization token"?
A: Changed to "authorization information" to be consistent with rest 
of document.

4. Does EPP need the login/pass command if it is using TLS authentication?
A: Yes, TLS is using machine to machine authentication. user-level 
authentication
    gives greater granularity. Some greater explanation is needed.

Scott Bradner:
1. More strict about congestion control protocols require an IETF 
standards track congestion
    control such as TCP or SCTP.
A: Will address this later in response to another comment.

Bert:
1. example.tld is not an approved example.
A: Was not aware of the convention for example TLDs. They will be 
changed appropriately.
    What should be used for IPv6 examples?
Patrick Faltstrom: Will ask the IESG for guidance.

Randy:
1. Why is there no granular privacy options for domain/contact mappings.
A: Raised some discussion. Extensions allow policy to be codified on 
a case-by-case
    basis. Needs to be discussed by the WG.

Allison:
1. <replacement text for managing congestion>
A: <will discuss later>

2. Define "marketing" add a more neutral definition.  More 
explanatory material will
    be added (from P3P website or similar)

3. How does IESG and the community check XML (as opposed to ABNF or 
MIB checking)
A: Available checkers from W3C etc.
PF: IESG may more thoroughly define this in the future, only just 
implemented requirements
     on ABNF grammars.

4. Suggest that limiting the number of TCP connections is not a good 
thing for net
    services. change MAY establish to SHOULD NOT. A server MAY limit 
becomes SHOULD limit.

Discussion
----------
SH: Any problems with the suggested replacement text (from Allison 
Q4) that clients should not
     establish multiple tcp connections, and the server should limit 
connections.
Rick Wesson (RW): Ignores practices in common place
Jon Peterson (JP): ...
EL: This is used to address server load, not network load. This also 
has considerations
     for both.
JP: We might want to recast the sentence to consider that.
RW: It would be nice to have the actual language rather than the substitutions.
..
RW: Seems we are touching up language that ignores that operationally 
this happens
     (multiple connections) normally.
EL: SHOULD NOT helps convey that it is discouraged, and that 
implementations shouldn't
     make this default behaviour.
Patrik Faelstroem (PF): The definition for SHOULD NOT does not forbid 
it if there is a
     justification.
RW: It is good to encourage clients not to do it.
JP: It contains a provision for clients and servers. If the server 
limits the number of
     concurrent connections it will persuade the clients not to.
PF: The client should not just open multiple connections without 
justification. The
     server can still reject the connections. The important reason for 
including the
     wording is that those claiming to the conformant to this RFC will 
only implement
     software with concurrent connections only when it is really 
needed. i.e. Clients
     should reuse open TCP connections rather than open new 
connections wherever possible.
<no more comments>

Transport Comments (congestion and reliability, Allison-1)
--------------------------------------------------
EL: This is the suggested wording from Allison. "The transport 
mapping MUST be onto a
     transport such as [..] and so forth".
     The last part is a concern that SMTP runs over TCP, that the SMTP 
store-and-forward
     may drop transactions. The first part is that the Layer 4 
connections don't impact
     the network.
PF: Also note, the second part, talks about SMTP/BEEP doesn't include 
any MUST or
     SHOULDs. This is a reminder for transport mapping authors, that 
they need to think
     about these issues and contain some wording on these matters.
EL: Any comments on the proposed text?
SH: Not advocating this position, but Eric B-W's comment was that his 
work on UDP
     transport would be affected by this.
PF: I suggest that because Eric brings up this issue, that the WG 
summarises the issue
     that Eric has and pass it back to Allison. You could get Eric to 
do this. I dont think
     that the WG should declare rough concensus and ignore Eric's 
comments without consulting
     with Allison.
RW: When did Eric make this comment?
EL: In recent weeks, and I think it was alluded to in the SMTP draft.
SH: I think it was right after the IESG comments were sent to thelist.
Simon ??: Many UDP protocols handle this like RPC implementations 
that do retries,
     backoffs etc. It should be in the transport mapping. We shouldn't 
expect anything
     more from the transport ADs.
JP: I'm surprised by this. Is there some reason for using UDP? Seems 
to be this is
     a real long-shot, and neednt go to Allison unless people think it 
is credible.
PF: My feeling in IESG discussions, is that the experience from the 
Transport ADs,
     that messages with one round trip (from SIP etc.) but as the 
protocol grows you
     implement retransmissions and backoff algs, so over and over 
again people who
     use UDP fails.
RW: I dont feel it is appropriate to do this over UDP. I think that 
without a draft
     on this we should just move on.
??: Dont make it completely illegal though, some of the stuff I am 
doing is very lightweight,
     where if a connection fails it can just be retried. Other people 
are doing things with
     UDP that are illegal.
RW: More specific?
??: (not appropriate for WG)
EL: BEEP mapping failed because no-one wants to work on it as a 
group. We have new
     mappings coming in - do we want to work on those in this group? 
Does the doc go
     out prohibiting UDP or just not mentioning UDP? We could just 
ignore datagram
     protocols, say something. I dont want to specify how to do this 
over a datagram.
     I'm not sure how to approach this - leave it unmentioned? I'll 
talk with Patrick
     about that.
PF: Summarise the issue. See if people don't want it prohibited to do 
this kind of
     mapping, and then start a dialogue with Allison. I don't hear a 
clear concensus that
     doing UDP is completely stupid.
EL: I think we're done with this item.
SH: Are you going to take the action to coordinate this with Allison.
EL: Yes, it will go on in the minutes.
PF: Try to talk with her here.

Privacy comments
----------------
EL: The last of the major talking points in the IESG comments 
involves privacy. Allison
     had this specific comment regarding marketing purposes. And then 
Randy's comments
     on privacy meta-data on a more granular level, down to objects 
and aspects and so
     on, rather than the whole session. Where do we want to go with this?
SH: Lets begin with a little explanation on how we got here. Since 
the beginning, the
     topic of privacy came up 1-2 years ago, and a few folks proposed 
a strawman proposal
     on granular privacy tagging - but it never came forward, so we 
went around in circles.
     Instead, we punted to the extension mechanism in the protocol now 
- so specific
     privacy policies can be implemented with the extension mechanism. 
So if email addresses
     are private, an extension could tag the element for this purpose. 
There isn't a lot
     of text describing privacy and using extensions to implement 
this, and we could do
     this if necessary - but the IESG did not ask for this, it asked 
for more specific
     privacy.
JP: In a P3P sense, it is clear cut how it is used. But in this B2B 
context, what does
     this mean for contacting for marketing purposes? What does it mean?
RW: In the context for the P3P sense, it only appears to be 
applicable for web pages.
     There doesn't seem to be any way to do this, it is an immature 
way to address the
     privacy issue. I don't know if what we have is extensible. I like 
that approach.
     Different registries can develop policies. But putting a tag on 
each and every
     element seems like a simple way to solve a problem - but as we 
don't have any\
     operational or policy sense on this, we have no way of knowing if 
it will work.
Rich Shockey (RS): I want to concur with Rick on this. The idea that 
privacy is assocated
     with objects is a good idea. We dont have a standard to apply to 
the EPP objects
     at this stage. Last week in Dulles, VA, the W3C had a workshop on 
P3P on its applicability
     outsibe webpages. They do not have a workplan, or anything 
associated to present.
     We could go down this road, but int he absence of any other 
technology (and I would
     assume the W3C will take years), as much as I'd like to see 
something implemeneted,
     i dont see how we could practically do it.
RW: Privacy is good. Some way of enhancing a registrants, or 
expressing that privacy,
     is good. I just want a mechanism that is more flexible and tested.
RS: I am in total agreement. This could delay the work by orders of magnitude.
EL: There are two types of granularity... Per-item and per-purpose.
SH: I was asked if I had any opinions. Personally, I think the 
protocol addresses this
     requirement. It allows us to move forward without putting 
restrictions on how
     it is defined in the future. The protocol still depends on the 
extension mechanism
     to define what private means. The document implies that you must 
use the ext. mech.
EL: One suggestion was that, and if you see Randy's comment, that the 
contact details
     are the ones needed privacy and maybe we only define it for those objects.
RW: If we have something that worked for all situations, we would 
appreciate it if we
     could just take something and use someone elses work. We may not 
be qualified
     to do this kind of work.
JP: This is a common refrain, we had the same thoughts in geopriv. We 
have nothing there,
     and we don't have anywhere to go.
RS: That's funny, because we are looking to geopriv.
RW: It doesn't exist - are we the right people to develop it? Should 
it be in the context
     of another group?
EL: Maybe we are the right place because we are one of the only 
places dealing with these
     matters.
RS: My personal suggestion would be the WG chairs ask the IESG for 
clarifications,
     with the comments we have no technical basis or competency to 
tackle the issue.
EL: I want in the minutes that the P3P, where the documents come 
from, is a good documents
     but we're not sure is applicable.
RS: I am happy to post the results from the Dulles WS, they are 
working on this and
     congniscent of the limitations it has. There are companies that 
are looking to do
     clever things with this. But is there a body of work to apply to 
provreg and EPP?
     No. When could we see one? God knows.
JP: IESG's comments suggestion seems to only be some tweaks - and 
that we are on the right
     track. Maybe we are doing a good job, and we shouldn't decide to 
change focus and do
     something else entirely.
EL: ...
RW: We have not just the registrar-registry model, but we have 
reseller chains that
     must express this information and how it applies. It might be 
somewhat clear in the
     simple R-R model. I believe there is a whole lot of work to be 
looked at here.
RS: This is a question on how the policy can be passed to 3rd and 4th 
parties in a chain of
     trust. To make it perfectly clear, if there was a way to do this 
in a reasonable
     or rationable way - we need a few proposals on how this could be 
done without
     complicating the process too much. I think the extensions 
proposals are the most
     reaosnable way to do this.
EL: I do want to .. i'm not sure if we have to worry about. Right now 
we are looking at
     the EPP protocol for R-R. Do we need to look at the EPP protocol 
from registrar to
     registrant? Does it need to be addressesd now?
RW: If you are not talking about privacy, I agree we dont need to address it.
EL: Why is it special for privacy?
RW: It is the entity that is making the registration, so if you have 
reseller chains,
     in a privacy context, there is a lot of liability - countries, 
laws etc. and it is
     not at all clear to me how it will work.
EL: I think we are done with the IESG comments. We have to discuss 
UDP, Privacy, etc.
     so we can't just rubber stamp it. But we have addressed most 
comments apart from
     these few things.
SH: A request for clarification. Is there going to be a WG response 
to take back to the
     IESG? If we ask the IESG for clarification, then we have to 
rediscuss it here.
EL: I think we can have a mailing list discussion over the next 2-4 weeks.
SH: I would like to see some kind of position.
EL: Some new issues have come up. Passing informaton up and down. We 
could sit down
     and consider types of privacy.
RW: I would suggest we enumerate the kinds of things we have looked 
at. We shouldn't
     go down the road of defining privacy as it is too much work.
EL: Another comments is this doesn't apply as this is B2B.
SH: I think the P3P discussion, and privacy, are somewhat seperate.
EL: I think based on the fact we have these small comments that we 
only need to make
     small changes.
SH: There is no indication we have got this completely wrong.
     Who is going to make that happen? Our chairs?
EL: Our chairs.
??(RW?): I volunteer..

EL: We have two things to think about - UDP and privacy.

2.5 other issues with the base 10m

     Last-Verified and External Hosts

RW: Several weeks ago, a number of groups have an issue with WHOIS.
     -quality assurance
     In the context of registrant data.. one being the postal element, on how it
     can change - not in the db, but in the real world. Such as change 
of a zip code
     or reassignment of a street address. PSTN elements change over time too -
     phone numbers get remapped. It is happening in India at the 
moment, where the
     length of numbers are getting changed. In the US, Area codes changes. If we
     had a registration 10yrs ago in the LA area, and the area code 
would be remapped
     and would change. Then the data in our systems isn't being 
remapped or changed.
     I advocate a position where we identify the time since a contact 
acknowledged
     that they have accurate and correct information .

     The proposal is for a last-verified-date, since the registrant 
ack'd the data
     is accurate. It would be optional in EPP for the contact.

     Comments?
<none>
EL: OK. On the mailing list, the last message on this talked about this being
     optional. Not everyone agreed that all registries. So this is the 
question i
     am most interested in. Should it be optional?
RW: Fromt he comments i have received it makes the most sense.
JP: It doesn't seem to make any sense to make it mandatory. There are 
all kinds of
     bad things about iut.
SH: I agree, it seems appropriate. The last comment was more strong 
that it should
     not be in the base, but i agree with RW on this.
RS: Ditto.
EL: We have documents in from of the IESG and I am not sure if we 
want to make a
     change at this stage.
RW: The IESG knows about this.

EL: The other item is the external host, external objects.
SH: OK, here is another can of worms that was discussed in great 
details 1-2 years
     ago. TO set the stage. We have an issue with repositories being 
authoritative
     for objects in other repositories. i.e. Hosts being used as 
nameservers, being
     renumbered etc. This causes management issues if the entity that 
owns the host
     doesn't sponsor the object in the registry. An alternative 
proposal was that
     each client sponsored its own copy of these objects, allowing 
each client to
     manage their own. Hopefully there was no restrictions on this, prevents hi
     jacking. It allows for bulk updates, you change one objects and 
it percolates
     through all objects that are associated. This is something we 
need to resolve
     before we move forward.
JP: I am not sure about this issue. I can't speak for Hong.
SH: Hong's objections were this per-client copy, but instead these 
sorts of objects
     are managed by the server. I don't like the owner word, I forget 
what the arguments
     against what that were - it seems rational. If we assume no 
objects belong in the
     registry if they are not authoritative, we can throw out these objects and
     make nameservers attributes of the domain objects. This has 
problems with bulk
     updates.
EL: The fear is that using the same nameserver for a lot of zones, 
that would mean
     a lot of changes if I change nameservers.
RW: We have to do it one way or the other, and each has consequences. 
I think we
     have made a decision and it is a good choice. We have a 
significant amount of
     operational experience about this choice. I have not heard 
significant comment
     about this apart from Hong.

EL: Any other comments on the base spec, outside the IESG and our 
current discussions?

EL: Next on our agenda is a transport mapping on SOAP. Hong is not here so Jon
     Peterson will present on that.

EPP/SOAP
--------
JP: My slide is what i believe are the issues with the draft. Why 
would you want to
     implent this? SOAP is more widely deployed, so it may be easier 
to use a SOAP
     envelope to talk EPP. You need to define a small amount of 
persistent session data
     inside the SOAP header. It is relatively straight forward. THere 
are some issues
     that were disucssed on the list that are unyet resolved. These 
are error codes, do
     we want to constract actual transport protocols used by soap, and 
how does this draft
     fit with existing deliverables od the provreg charter. Is this 
charter work? DOes
     the initial charter of provreg consider this appropriate. Is SOAP 
perceived to be
     valuable?
RW: Is soap an actual transport. It is a layer of indirection. There 
are a numbner
     of bindings defined to another protocols but it is not an L4 transport.
Andrew Newton (AN): One of the motivations of using SOAP is that 
abstracts you from the transport,
     and you can use any number - but are there any non-TCP transports?
JP: I'd be surprised if there isn't.
AN: No there isn't one.
     RW: What is the status of the draft? Informational or Standards 
Track? If Info.
     I think this is great. I am a SOAP implementor and I think it 
sucks. But that is
     just the state of affairs today.
EL: Hong has submitted it that he would like it as a WG item. That means the WG
     takes over. If we think this is just a cool idea for Hong to work 
on, that is
     fine.The charter does say we should look at transport mappings. 
It is perfectly
     OK for the group to say yes we love this idea - we could do that 
- and it could
     be standards track. I'm not saying that we have 4 people who 
would love to do this.
AN: SOAP is not a transport. Some people see this as a magic answer that would
     solve all their problems. This has happened with other RPC protocols.
Leslie Daigle: If you want to discuss using SOAP, you should come up 
with architectural
     reasons for going there.
EL: Yes that is an important question.. "Why?" Why are we doing this?
JP: Given how minimal the mechanism is, this is something I am here 
to ask what the WG
     thinks.
EL: We have already thrown out BEEP mapping because no-one else 
wanted to work on it.
     There was nothing wrong with the proposal - it was not mature - 
but its proponents
     didn't pursue it any further. The problem is we had not concensus there.
RW: To answer some of Leslie's question. This is exactly why BEEP 
didn't work. We
     didn't have the tools or constituency. Right now, the fastest way 
to deploy the
     service (as long as you dont want too many people to use it) is 
to use SOAP.
EL: If we are talking about EPP, we are going to layer requirements 
on the transport.
     With SOAP being this general, how can the document address all 
the transport layers.
RW: We should have a set of requirements that the SOAP transport must 
use. Just like
     the TLS over TCP.
JP: I think Rick is correct with the SOAP approach. We would rely on 
profiling on constraining
     you to particular transports.
EL: Does this have promise? Might this be an interesting thing? DO we 
want this in the charter?
(yes)
EL: Who would implement this?
PF: Including specific requirements all the way down the stack to IP 
- i.e. not just using
     HTTP.
RW: There has been no analysis.
EL: If we invite this into the WG we will start working on it. I want 
to make sure before
     we do this. Before we do this, I want to see sufficient 
well-spread interest in this.
     If only 1 person wants to do this, they can experiment all they 
want without IETF
     involvement.
PF: I agree with your concerns concerning new bindings. Regarding 
whether the transport binding
     is part of the charter. I wil require a review by the WG or 
mailing list if the WG doesn't
     exist. The mailing list can not go away if the WG dies. I hope 
the WG winds up within
     6 months. You will still do the review, it doesn't need to be in 
the charter
     Milestones/Deliverables need to change.
RS: The document can independently proceed, and the IESG reviews it?
PF: Exactly. It wont be stopped by the WG if it is not in the 
deliverables. The WG/ML will
     still need to review it.
EL: The IETF will not get in the way of this. I'm not saying that we 
are going to kill this by
     not putting it in the WG. What I am after is how mahy people are 
willing to commit time
     and resources that would indicate it should be a WG item?
RW: If you're looking for low hanging fruit for a second transport 
implementation, this is
     it. For me to implement this would take all of a day. It is just 
not a big deal.
JP: Just one thing about that - i think it is a reasonable barrier to 
entry to insist on finding
     a few implementors to make it a WG item. I think this is the 
wrong forum to ask this question.
EL: This will go to the ML.

PF: One thing, BTW, I take the constraint of transport protocols as 
an action item.
JP: I definately think it should not be characterised as a L4 protocol.

EL: The other item on the agenda, is the SMTP draft. This is an 
example of skepticism
     raising over the years. People have said they are all for an SMTP 
transport, with 3-4
     volunteers. Finally someone wrote a document. Further discussion 
has not happened as
     the author is unavailable at this time. SMTP is something people 
have liked over
     time; Are there people who would like to implement SMTP transport

     OK, No hands showing here. This iwll go back to the ML, but it 
could be we don't pursue
     this. Anyone think this is a great loss?

     No. Ok. We may ask to remove a milestone. We only have that and 
one other milestone.

EL: Next item on the agenda is the only other WG document we have, 
that Scott has, the
     guidelines for extending EPP. I would like to see this doc extend 
very quickly.
     (Sidenote: We also need to discuss the milestones, some have been 
done and subsequently dropped)
SH: This doc was first published a few months ago, as a result of 
some screwy ways of
     extending the protocol in some independent documents. The only 
comemnts I have received
     is from Ed, there has been very little discussion otherwise. I 
wanted some WG discussion
     before implementing those comments.
RW: This is the part where we talk about other docs?
EL: I'd like to talk about the guidelines first?
EL: The intent here is to give people a leg-up on extending EPP. The 
idea came up about a
     year ago. How many people are implementors in this room?

     OK, so it is the minority here. So in this case it is best 
discussed on this list.

EL: Ok, other documents.
RW: I wanted to find out if there was interest in writing a BCP for 
domain registries over
     EPP. Is this a good idea? It would be an idividual submission. It 
doesn't have to be a WG
     item. ... Sounds like a resounding no.
EL: Yeah I think it is not a WG item, but that doesn't stop you.

EL: Next item is discussion on the future of the WG. It seems to me 
there are some things
     still to work on. The IESG comments will require a little bit of 
work, the SOAP is
     a consideration with more than 1 implementor in the room will 
want to take a look at,
     and we'll ask for input from the ML. That could wind up as 
another item. It sounds like
     SMTP will be tabled indefinitely or killed, not for the lack of 
interest but no
     need to implement. So, the extensions guidelines draft which 
shouldn't be controversial,
     the iESG commnents, and the SOAP draft - and I think that is 
pretty much it. If there
     isn't anything else, we can close the meeting. I would like to 
get copies of the
     slides.

PF: Wait... I was just looking for Allison. I asked her about UDP. 
Hwer experience has shown
     those using UDP do broken thing, so they want to ban UDP. So that 
is the message back
     from Allison. So you need to make some kind of statement and 
engage in discussion with
     the transport.
EL: I might make a post to the ML that we will outlaw UDP, and see 
what kind of flames we get.
PF: I think we will also have a discussion within the IESG, if this 
kind of requirement exists
     there needs to be some kind of statement.
EL: OK, so I think we're done.

ENDS
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer