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

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

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBVM6L9p018012 for <[e-mail]>; Tue, 31 Dec 2002 23:06:21 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gBVM6LqM018011 for ietf-provreg-outgoing; Tue, 31 Dec 2002 23:06:21 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBVM6K9p018006 for <[e-mail]>; Tue, 31 Dec 2002 23:06:20 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id RAA00519; Tue, 31 Dec 2002 17:06:16 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <ZHNYAAK2>; Tue, 31 Dec 2002 17:05:48 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'janusz sienkiewicz'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Updated (and hopefully the last) EPP Privacy Proposal
Date: Tue, 31 Dec 2002 17:04:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBVFi29p016029 for <[e-mail]>; Tue, 31 Dec 2002 16:44:02 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gBVFi27p016028 for ietf-provreg-outgoing; Tue, 31 Dec 2002 16:44:02 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBVFi19p016023 for <[e-mail]>; Tue, 31 Dec 2002 16:44:02 +0100 (MET)
Received: from dev3.int.libertyrms.com ([10.1.2.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 18TOYZ-0007fh-00; Tue, 31 Dec 2002 10:43:51 -0500
Message-ID: <[e-mail]>
Date: Tue, 31 Dec 2002 10:53:15 -0500
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3custom i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>
CC: [e-mail]
Subject: Re: Updated (and hopefully the last) EPP Privacy Proposal
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

"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





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBVDtQ9p015498 for <[e-mail]>; Tue, 31 Dec 2002 14:55:26 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gBVDtQgh015497 for ietf-provreg-outgoing; Tue, 31 Dec 2002 14:55:26 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBVDtM9p015492 for <[e-mail]>; Tue, 31 Dec 2002 14:55:23 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA12638; Tue, 31 Dec 2002 08:55:16 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <ZHNX0Z2D>; Tue, 31 Dec 2002 08:54:49 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Joe Abley'" <[e-mail]>, "'janusz sienkiewicz'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Updated (and hopefully the last) EPP Privacy Proposal
Date: Tue, 31 Dec 2002 08:53:29 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBULTF9p010504 for <[e-mail]>; Mon, 30 Dec 2002 22:29:15 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gBULTFKg010503 for ietf-provreg-outgoing; Mon, 30 Dec 2002 22:29:15 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBULTE9p010498 for <[e-mail]>; Mon, 30 Dec 2002 22:29:14 +0100 (MET)
Received: from dev3.int.libertyrms.com ([10.1.2.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 18T7TB-0001xx-00; Mon, 30 Dec 2002 16:29:09 -0500
Message-ID: <[e-mail]>
Date: Mon, 30 Dec 2002 16:38:30 -0500
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3custom i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Updated (and hopefully the last) EPP Privacy Proposal
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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">[e-mail]</contact:email>
> <contact:email>[e-mail]</contact:email>
> Both of the above mean "do not disclose this email address to third
> parties".
>
> <contact:email dnd="false">[e-mail]</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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBUIVp9p009514 for <[e-mail]>; Mon, 30 Dec 2002 19:31:51 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gBUIVpnJ009513 for ietf-provreg-outgoing; Mon, 30 Dec 2002 19:31:51 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from fep03-mail.bloor.is.net.cable.rogers.com (fep03-mail.bloor.is.net.cable.rogers.com [66.185.86.73]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBUIVn9p009508 for <[e-mail]>; Mon, 30 Dec 2002 19:31:50 +0100 (MET)
Received: from isc.org ([24.103.90.17]) by fep03-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <20[e-mail]>; Mon, 30 Dec 2002 13:31:13 -0500
Date: Mon, 30 Dec 2002 13:31:45 -0500
Subject: Re: Updated (and hopefully the last) EPP Privacy Proposal
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: [e-mail]
To: "Hollenbeck, Scott" <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.103.90.17] using ID <[e-mail]> at Mon, 30 Dec 2002 13:31:12 -0500
Sender: [e-mail]
Precedence: bulk

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">[e-mail]</contact:email>
> <contact:email>[e-mail]</contact:email>
> Both of the above mean "do not disclose this email address to third
> parties".
>
> <contact:email dnd="false">[e-mail]</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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBUEAa9p007978 for <[e-mail]>; Mon, 30 Dec 2002 15:10:36 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gBUEAasL007977 for ietf-provreg-outgoing; Mon, 30 Dec 2002 15:10:36 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBUEAY9p007972 for <[e-mail]>; Mon, 30 Dec 2002 15:10:35 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA00932 for <[e-mail]>; Mon, 30 Dec 2002 09:10:31 -0500 (EST)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <ZHN47FGW>; Mon, 30 Dec 2002 09:08:49 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Updated (and hopefully the last) EPP Privacy Proposal
Date: Mon, 30 Dec 2002 09:08:46 -0500
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

In 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">[e-mail]</contact:email>
<contact:email>[e-mail]</contact:email>
Both of the above mean "do not disclose this email address to third
parties".

<contact:email dnd="false">[e-mail]</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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBOJfh9p001760 for <[e-mail]>; Tue, 24 Dec 2002 20:41:43 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gBOJfh5p001759 for ietf-provreg-outgoing; Tue, 24 Dec 2002 20:41:43 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBOJfd9p001754 for <[e-mail]>; Tue, 24 Dec 2002 20:41:39 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gBOJfaYm055907; Tue, 24 Dec 2002 14:41:36 -0500 (EST)
Received: from [192.149.252.235] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA02310; Tue, 24 Dec 2002 14:41:35 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b0dba2e668be551@[192.149.252.235]>
Date: Tue, 24 Dec 2002 14:42:53 -0500
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: milestone discussion
Cc: [e-mail], Jaap Akkerhuis <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBNDSS9p021712 for <[e-mail]>; Mon, 23 Dec 2002 14:28:28 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gBNDSSA9021711 for ietf-provreg-outgoing; Mon, 23 Dec 2002 14:28:28 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from jupiter.jmi.co.kr ([211.45.79.102]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gBNDSO9p021706 for <[e-mail]>; Mon, 23 Dec 2002 14:28:26 +0100 (MET)
Received: (qmail 13308 invoked by uid 525); 23 Dec 2002 22:29:25 +0900
Received: (qmail 13191 invoked from network); 23 Dec 2002 22:28:45 +0900
Received: from unknown (HELO polo.jmi.co.kr) (211.45.79.31) by 0 with SMTP; 23 Dec 2002 22:28:45 +0900
Received: from ran.ietf.org (ran.ietf.org [132.151.6.60]) by polo.jmi.co.kr (8.9.0/8.9.0) with ESMTP id WAA29287 for <[e-mail]>; Mon, 23 Dec 2002 22:30:12 +0900 (KST)
Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18QSEg-0003kC-00 for [e-mail]; Mon, 23 Dec 2002 08:03:10 -0500
Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18QSBW-0003eS-00 for [e-mail]; Mon, 23 Dec 2002 07:59:54 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27469; Mon, 23 Dec 2002 07:54:51 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-jseng-idn-admin-02.txt,.pdf
Date: Mon, 23 Dec 2002 07:54:49 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

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


	Title		: Internationalized Domain Names Registration and 
                          Administration Guideline for Chinese, Japanese and 
                          Korean
	Author(s)	: J. Seng 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
[e-mail].

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:
	[e-mail].
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="[e-mail]"

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

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

--OtherAccess--

--NextPart--





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBNCwJ9p021537 for <[e-mail]>; Mon, 23 Dec 2002 13:58:19 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gBNCwJOo021536 for ietf-provreg-outgoing; Mon, 23 Dec 2002 13:58:19 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBNCwF9p021530 for <[e-mail]>; Mon, 23 Dec 2002 13:58:18 +0100 (MET)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27469; Mon, 23 Dec 2002 07:54:51 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: [e-mail], [e-mail], [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-jseng-idn-admin-02.txt,.pdf
Date: Mon, 23 Dec 2002 07:54:49 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

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


	Title		: Internationalized Domain Names Registration and 
                          Administration Guideline for Chinese, Japanese and 
                          Korean
	Author(s)	: J. Seng 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
[e-mail].

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:
	[e-mail].
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="[e-mail]"

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

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

--OtherAccess--

--NextPart--




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBJH2X9p019492 for <[e-mail]>; Thu, 19 Dec 2002 18:02:33 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gBJH2Xsa019491 for ietf-provreg-outgoing; Thu, 19 Dec 2002 18:02:33 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBJH2V9p019486 for <[e-mail]>; Thu, 19 Dec 2002 18:02:32 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gBJH2SYm062890 for <[e-mail]>; Thu, 19 Dec 2002 12:02:29 -0500 (EST)
Received: from [204.152.189.47] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA22734 for <[e-mail]>; Thu, 19 Dec 2002 12:02:27 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b02ba279e2201e7@[204.152.189.47]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Thu, 19 Dec 2002 08:16:01 -0800
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: RE: EPP Compliance (Was Re: lastVerified: optional vs. extension)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBIHmM9p008658 for <[e-mail]>; Wed, 18 Dec 2002 18:48:22 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gBIHmLhD008657 for ietf-provreg-outgoing; Wed, 18 Dec 2002 18:48:21 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from kahua.nona.net (nona.net [193.80.224.122]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBIHmK9p008652 for <[e-mail]>; Wed, 18 Dec 2002 18:48:20 +0100 (MET)
Received: from localhost (localhost [127.0.0.1]) (uid 1000) by kahua with local; Wed, 18 Dec 2002 18:48:12 +0100
Date: Wed, 18 Dec 2002 18:48:12 +0100
From: [e-mail]
To: [e-mail], [e-mail]
Subject: mod_epp - first (pre)release
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
Sender: [e-mail]
Precedence: bulk

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
[e-mail], [e-mail]




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBHCb59p024190 for <[e-mail]>; Tue, 17 Dec 2002 13:37:05 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gBHCb59H024189 for ietf-provreg-outgoing; Tue, 17 Dec 2002 13:37:05 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBHCb09p024178 for <[e-mail]>; Tue, 17 Dec 2002 13:37:00 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA04713; Tue, 17 Dec 2002 07:36:57 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <Y6AA92A5>; Tue, 17 Dec 2002 07:31:20 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Stephane Bortzmeyer'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Another Privacy Proposal
Date: Tue, 17 Dec 2002 07:35:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Stephane Bortzmeyer [mailto:[e-mail]]
> Sent: Tuesday, December 17, 2002 4:03 AM
> To: Hollenbeck, Scott
> Cc: '[e-mail]'
> Subject: Re: Another Privacy Proposal
> 
> 
> On Mon, Dec 16, 2002 at 02:44:04PM -0500,
>  Hollenbeck, Scott <[e-mail]> 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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBH92s9p022782 for <[e-mail]>; Tue, 17 Dec 2002 10:02:54 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gBH92son022780 for ietf-provreg-outgoing; Tue, 17 Dec 2002 10:02:54 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBH92m9p022774 for <[e-mail]>; Tue, 17 Dec 2002 10:02:53 +0100 (MET)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id gBH92YgV1370387; Tue, 17 Dec 2002 10:02:35 +0100 (CET)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id 367BE10FA2; Tue, 17 Dec 2002 10:02:34 +0100 (CET)
Date: Tue, 17 Dec 2002 10:02:34 +0100
From: Stephane Bortzmeyer <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re: Another Privacy Proposal
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.28i
X-Operating-System: Debian GNU/Linux 3.0
X-Kernel: Linux 2.4.18-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
Sender: [e-mail]
Precedence: bulk

On Mon, Dec 16, 2002 at 02:44:04PM -0500,
 Hollenbeck, Scott <[e-mail]> 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.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBGJjK9p016444 for <[e-mail]>; Mon, 16 Dec 2002 20:45:20 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gBGJjKCd016443 for ietf-provreg-outgoing; Mon, 16 Dec 2002 20:45:20 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBGJjJ9p016438 for <[e-mail]>; Mon, 16 Dec 2002 20:45:19 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA10304 for <[e-mail]>; Mon, 16 Dec 2002 14:45:17 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <Y6AG0PDS>; Mon, 16 Dec 2002 14:44:20 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Another Privacy Proposal
Date: Mon, 16 Dec 2002 14:44:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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>[e-mail]</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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBDGpb9p020898 for <[e-mail]>; Fri, 13 Dec 2002 17:51:37 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gBDGpbbo020897 for ietf-provreg-outgoing; Fri, 13 Dec 2002 17:51:37 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBDGpa9p020892 for <[e-mail]>; Fri, 13 Dec 2002 17:51:36 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gBDGpZYm032045; Fri, 13 Dec 2002 11:51:35 -0500 (EST)
Received: from [192.149.252.235] ([192.149.252.235]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA09659; Fri, 13 Dec 2002 11:51:35 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@ops
Message-Id: <a05111b0bba1fbcf25e55@[192.149.252.235]>
Date: Fri, 13 Dec 2002 11:52:26 -0500
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: what I'm doing now
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBDFfk9p019946 for <[e-mail]>; Fri, 13 Dec 2002 16:41:46 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gBDFfk2r019945 for ietf-provreg-outgoing; Fri, 13 Dec 2002 16:41:46 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBDFfj9p019940 for <[e-mail]>; Fri, 13 Dec 2002 16:41:45 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA27645; Fri, 13 Dec 2002 10:41:42 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <Y45QC0HA>; Fri, 13 Dec 2002 10:36:14 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Antony Perkov'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: date-time values in EPP
Date: Fri, 13 Dec 2002 10:40:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Antony Perkov [mailto:[e-mail]]
> Sent: Friday, December 13, 2002 9:49 AM
> To: '[e-mail]'
> 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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBDEmu9p019269 for <[e-mail]>; Fri, 13 Dec 2002 15:48:56 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gBDEmum0019268 for ietf-provreg-outgoing; Fri, 13 Dec 2002 15:48:56 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBDEms9p019263 for <[e-mail]>; Fri, 13 Dec 2002 15:48:55 +0100 (MET)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <YDTPBSKL>; Fri, 13 Dec 2002 14:48:50 -0000
Message-ID: <[e-mail]>
From: Antony Perkov <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: date-time values in EPP
Date: Fri, 13 Dec 2002 14:48:46 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBDDtL9p018875 for <[e-mail]>; Fri, 13 Dec 2002 14:55:21 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gBDDtLJ6018874 for ietf-provreg-outgoing; Fri, 13 Dec 2002 14:55:21 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBDDtJ9p018869 for <[e-mail]>; Fri, 13 Dec 2002 14:55:20 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA22521 for <[e-mail]>; Fri, 13 Dec 2002 08:55:17 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <Y45Y8MCD>; Fri, 13 Dec 2002 08:54:26 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Document Status
Date: Fri, 13 Dec 2002 08:54:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBCEBF9p008837 for <[e-mail]>; Thu, 12 Dec 2002 15:11:15 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gBCEBFwP008836 for ietf-provreg-outgoing; Thu, 12 Dec 2002 15:11:15 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBCEBE9p008831 for <[e-mail]>; Thu, 12 Dec 2002 15:11:14 +0100 (MET)
Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id gBCEBBOG073276; Thu, 12 Dec 2002 15:11:12 +0100 (CET) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: [e-mail]
Subject: Re: last chance to comment 
In-reply-to: Your message of Thu, 12 Dec 2002 08:56:06 -0500. <a05111b00ba1e457885a3@[66.44.62.240]> 
Date: Thu, 12 Dec 2002 15:11:11 +0100
From: Jaap Akkerhuis <[e-mail]>
Sender: [e-mail]
Precedence: bulk

    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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBCDtU9p008733 for <[e-mail]>; Thu, 12 Dec 2002 14:55:30 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gBCDtU7P008732 for ietf-provreg-outgoing; Thu, 12 Dec 2002 14:55:30 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBCDtT9p008727 for <[e-mail]>; Thu, 12 Dec 2002 14:55:29 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gBCDtSYm094140; Thu, 12 Dec 2002 08:55:28 -0500 (EST)
Received: from [192.149.252.235] ([192.149.252.235]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA05181; Thu, 12 Dec 2002 08:55:19 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@ops
Message-Id: <a05111b00ba1e457885a3@[66.44.62.240]>
In-Reply-To: <a05111b00ba1c37df11b6@[192.149.252.235]>
References: <a05111b00ba1c37df11b6@[192.149.252.235]>
Date: Thu, 12 Dec 2002 08:56:06 -0500
To: Edward Lewis <[e-mail]>, [e-mail]
From: Edward Lewis <[e-mail]>
Subject: Re: last chance to comment
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBC9Hw9p006881 for <[e-mail]>; Thu, 12 Dec 2002 10:17:59 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gBC9Hwl2006880 for ietf-provreg-outgoing; Thu, 12 Dec 2002 10:17:58 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBC9Hu9p006875 for <[e-mail]>; Thu, 12 Dec 2002 10:17:57 +0100 (MET)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id gBC9HpOG072413 for <[e-mail]>; Thu, 12 Dec 2002 10:17:51 +0100 (CET) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id gBC9Hnfe072412 for [e-mail]; Thu, 12 Dec 2002 10:17:49 +0100 (CET)
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBB3WR9p023713 for <[e-mail]>; Wed, 11 Dec 2002 04:32:28 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gBB3WOYm062359; Tue, 10 Dec 2002 22:32:25 -0500 (EST)
Received: from [66.44.58.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id WAA03396; Tue, 10 Dec 2002 22:31:20 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1 (Unverified)
Message-Id: <a05111b00ba1c37df11b6@[192.149.252.235]>
Date: Tue, 10 Dec 2002 20:54:47 -0500
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: last chance to comment
Cc: [e-mail], [e-mail]
Content-Type: multipart/mixed; boundary="============_-1172544961==_============"
Sender: [e-mail]
Precedence: bulk

--============_-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                                          [phone]
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

JVBERi0xLjIKJcfsj6IKNCAwIG9iago8PC9MZW5ndGggNSAwIFIvRmlsdGVyIC9GbGF0
ZURlY29kZT4+CnN0cmVhbQp4nK19Wa9mu5LUe/2K/QhIfCzb6ekRRCPxeFtX4vmqRA9o
V0M3FyT+PRkR6WFVt5Cg0ZFO7fCaPOQQTqf9PZ/09eC/+Pfnrx9//+PvvxLL1j8/f339
uz/++Dd/2b7MPo99/fGvfvi1r3+NR3Jvn57mVxrzYyN9/fHXv/jL//zXf/vf//wPf/q7
P3/9+z/9+U9ff/gff/r+2z//r3/5x//y4y/++PWHH3/wT/ynHwkP1efrV/yVvr5/pPy8
/nr8r7/58Xc/nk/++tsfudfxaeUrp1E/OfuTXtI/JXlJGx+bXpmaPxO4zk8bjkv/TDxh
DeU/f+SW28e/kJ/aPv7db5Q8n+7PPv7W5v+2VD/V4Rx8VXvKp+GVqXzM8Io68yc1L8n9
U/3ltfsdwMX/V1GDLoB7i/dYWddS/3QCb5A5fuwz8WAan55xu42m+j/pM70u1lGTVj9W
FsgcAtzrMM0no+HfeLR8Rn6XeOfgnuINyv486u1dPc2HrWZvThPwl/Vkn1QFv9Gv3icp
bu21ojJ6DzuZw7C+hKdbvz8MyIra0Ms0bHdJQ4vSnM+n9q/zueEtpDThL4xWyegpQgxV
SR905PPMT91fSl73kg+UdEByvIf7p+lxlxabfqXHZ7w38Nf8uNAS+Fu9v9izRC2j93zQ
ns/AN8fQ6D5DAKPbvdfWJe9d3NYHmuJi81AO8JrOTmrJ+wcvtvypQ3L24AkXoxRyN201
/W92a/x9qP1f/St/xbRP98Li4u7iDQXIg6JUzGXR/+2WPoBeDKFd0CtjFLAo8B5Hl/Fx
b2P28ShQF5f1hMtGmUelXSBR4EMPfWo9fUYHZmOb4WEfFEkvYWkdY4TRSnpraS6ZdjSp
uHJCnqt3PuSy2IjaLU0q/rnsd9Zm+EzxAZ51w+w9/VA8VkF/qGS1Z8i0V39+Cj/Q2UrV
FhV8vNmofnL18gqV9mlonXfPgzHz56FjgdFdpVDF1x29q/vU5A1H/kjdo6C4pOOyVY54
cSuV/S1tdopS8d7vRYPcYL5UwV8wLY0q5rfA2HgLHjawSnQW7POTJYAqKE+D9lIGMTzF
ex7148tLzjJcS6TKMMiKRKrCAFXXQ9dwVACWMOD3gl79Zxzow+Va5KBzsKqLFP91Zaio
hDdG2lu9N54sW5M6X9C8x1HiA5DHHlGbk5Ky4KDVPgNsMN/UscaONBcIqA4GMG+IAXZR
g6TsG9A//qC51X8gglOCZW7SCq3oEvn1ie7qDmNlZULIHHtriF0RJBO5sk5ZqtDdwhte
6eo7OOgF5mdhPIDR69cd3p8QM7wh4ZPeKbXpk2FP4UxR8gy+a3gl4Q4KBmu4v8oB/N4B
XS3rmqr+QKn1t4t0ZS0IqysAxmjUFGM1oQjDxRzdVd1YUa5GmmyUDzjNyoDiJGqU19dN
EgwYAI1/jCWvuXHrHMnGB2hv8Gb/QleHlyGT68RhymqHk7Za+F4oHUynwVDinZl3Lkxv
NT4pX3e468ED3rEJeuzihI61JsPrEEKHvkAnEQ/VQEKxcF9q7OrOOg4qqmP6CDUlACw/
b03yEQUGxUvJCNys0qC4YaBvkIqgLm6q2PGVkttcDiF9FYPTvN1oFcBP8ZKyLvkHdN9D
0ZHWVoMdXYrNL5krZzd6Bv8S7jJXCahr77K+NmnyF6z+lWfIdkWJfwP0pvewovhgd8WB
kwKAfIAzrWujRBMhMQTRVbiRsHJ4RtY7DNWBRPUmgI/7+ymvrOqgVEKOMZy/tU1mExIA
HXLmME2mU6wsSrxq7XM1f8FBg07jpAK3yYnSa+rhR2SlernR/dPzhf+G9YY1Qz/t4YIy
tiqlBOAwi9np2gTfSk1eHgBEZEgeCNuktW+uSSRq0YQGLewbHwveHviXMOBuIuEb2nBj
29kTrp+Nj2dIMcwuzN5vJfYhB2kYYxYUKllzo0QL7ZiPODspdmFQMLHgKDDZQRAe8KUG
HUHNSZ4lBT2LNgGS/hUybt662CHeQ+1voUvuIuTl1WTBRfJ6omsl1P1Xib+RXe3cBTXa
n4Md31UZ4WAqZIqQjNFQgGbgtezOXQKasswG2QMA+roL4HXUeupDeuKpTvKzsd6Le1dJ
LyF5SSyB7ma9V9XEN4uta6tCsGfz6/cqHzGB4XQDEdwxi5gOzCYkJ5jtuFtA8feCzs1S
DkilrSSYdP4y7cPNDu291xuuwXt3lAtmiGGQORRYsL0uLzicFImsyaQNe6CAPw85GK73
mMxhbGCfYWzGBZ38l7oGDyUdzKOJ7xkd7CMRxHcAyE0LZ3e61iDE3klFejbIkPzN5D1U
S7GBgdki9aPDXqHExRTP9CThGpx2FtHDEe7bRGd0rZESDqe0Tz8w0TOE+8T73N5MzbUg
q93NUYbsOi1BTZ0xxu2gxlOkAUoONkJr7a6bYw6mSrVqYELhzFTyoJVUmUHb+0+V0Ayz
xDjVgjL1pL6yUE/rN6YdZ0NWyRQ5Xm9Q3UMkXSeDWvttbID7o2KbS4+kufGGA8071Drk
i9wa1niMR7qPsQbg6BUNB661LrUdDXNGH/pMcwPaJNfTQOBMLq4rINBlUdxXlP615zG9
h+nlsHYJubdnrGvuDSWPmNa2g9GmFhPGKCmSJkyBBpViUJW3kkoNjyoP9NIx+fOrPO4a
lxLPRru64gsbFjrwSXbuAoc+mT5epCgb5yBm8HSgXROxEz4xKekT9J9MwThQ0xU+2LnX
Gu2cTuDIW2gxpg9ZZuvFlya4flrTZZCf6dOVsmYQqOBjopojADs20YjrmivoI6AHdWMN
uiyYFXtING8bBvee1BmJ0HTWmOqBLvtPvkQMQYEmSfcX+9xZtjdoanlgjvqaHT4ciooX
4nMGWuiPVCozPIa/z8fO0oFjRXtWASwjlNynGNVivLrzEEjGFG9UE2NcWauU5LAgHqzT
tvTh7b2wwNX92s7dSyatCrDrRHm8AZxnbwxuGM6dBW7JakQzKr5ay3buBOwFGj/C6PFn
3Qp7kpLeM9t27l6R/MnLtwcK114QVosw0nMj8AQ8CkNZFepLeBgMqmdSd4Kf8nU5rjEQ
YXAxujV4YknuRnK+sBMfkbdTQkEnVyptVcXhQBCmpLI0BzYBkpF8NkWi8XRQmZJcGkht
FnZ7WyIQESXeH7OofyFJqUVI0T1ZbxuHN/Xqnjs4M/ZXDvHOgG7VSjozZ6+z/1M1OW/4
oCujzFgFE1wdBk9adn8FpSzPoCZ/r0BXefwCSGLoKof1oT76jVvgttXyyjZ8XWK59Kc0
ToZ+bW0pTihSl69zsUU4iCZ1wRzBjlVQQn2dOGQ8TtXGhKQJhE33dxBSABLcuW6tPt3T
c42TvKDLjh+09udmOsVlhNPL6Eu3ZJoaBPQ+a1cYquQsnw2f4O9PJMCJ814CCmaBVsc1
RH38MwgupXxhuIsV/WQBAgUYtHg6l0eUP+Q68IkxXnc8lJrsig8+A7lLRbiG7DI24yVD
Vh+T4UqseEttAjRCBo4R13ploy2viSGhO4+Zl6tDgdvxqk5OeC2l3YfDv07AZsIMEmGs
QCgSPlLpPpp7lYwqpzWnppvyLpx4488dFS0poibdNdv5sOMiqpRJWBf+eWzUvoOG3wci
OFTA3UmrwLQkAK6VKAGNHrMXmlW04CO+vu+YLRgqX1AQx2kHYi5yeR4X7UYaAHLnEuGy
30SGRCiX6kjBFJhitzEQ3Gix2cEwycYKPRGjYhyDgzFtxYHd3vhb6FAZqdTosboB/bOh
ecKuVSRChTEyyiXnVFCvujEDNA+kYpVgWEFozyPNnW7BI951jA2ja/sSiWU/infjFalk
0LUURHur3NrDXnN1BQsCmZqwAU4rnhvvVu8SlxgGBSDf+A51A1TTBDhnlUsBPERCt8ac
1UFhnDe8Gmo2y3ZrAZdfM7cSeV5T1rskXmgWPeocC91jnL8iGDwFqOMyKYBn4l6sSlZo
zvDuqpBpwPEgsPzzxyqoT5ZN8X8zcCpfa32FgF2AGRwR65iowrxzVRgLLPnqAvNhnntN
aMHVBYi51FcXXCWatZfqlIGhdi3lOYZ/R8WKAC3GQ2GvVf7Kh/UJuIxxRRA0b4gwj6Yp
q8CFZE1LH/Qm5sGXJzanRsHZ5Ruj4HKPiE+NvKbGBS8BpzARW7RlyxmEv2zRPQJeYYBu
Vu8Tz8XqS6vpYvUHktUTLhZfEH66WH1B1OHF6r3EblbvON+svsAIv1i9614+rL7AT1ys
vjAUf7P6Av28WL23bR6mAHBYfVwTqwfYrL5Qpzerd4NnF6vfMJQRcNlOzNoOq/ceKW/b
ipDcxeobanuxeszv36we8+YXq29YFlk0vjQfusPqC6I4N6v3CvSb1Wu8gtUT7CbGuKpW
7WL1qNNm9VgWLaMlLXtzvZRwLaaWUWtEOKSaI+crgLbgUsXpEpIO6cYcJYfWec/a401G
+BNWcDj0PuwRTUgQeksI942YTwPTmGhmQBCrUy7+ulbdh0w+WOhkq3sCfKhTZbjqmsBd
DaQyx9q3PU/awOv8REyD8LQo1r5fJVxI905p9C8mT6gei7Vvgp9aJqbwF5+YXuvEhFwM
LhOxurEAqJKW6wmxfKO4+mRPVoWFYabRwNQWrXRRq2iTjx6r0Tm89jDrIDOYR3ACyLoW
/pUP0juAFwJjXdS2g0ZdfOrCGIxbQlaMoSqCXWlBhFOTSDYEi02N9xJsG2WY58z+JvHm
zOFF4g3s+ZB4w5LtIfFuKceLxJvPgm8S77huEk9wSDzhIfG6NUi8YS34IvGWR3uTeEOC
yiHx5uUXiTes5N4k3pILyiHxlmrfJJ7gkPi4Jo5uSZTtYC4vHBJvyad0F4n3D7WbxC98
SPx1B0m843qTeOIXifcSu0k88CbxBIfExzWSdMvPuEi8gXrfJN4ysgs2ifc+nJvEE2wS
T3RIvH8k3STeO8FuEu+9Vt8k3ju13iTeUliDIPELHxJ/7qCdN6QCHRJ/dVIUZCjNIfGW
Jd6LxKMFbxJvPmQXiXc4LxLvEvcOH7ms55vEuyrkm8Qv1blJPLvtkHh1cJB4Q3LGReI5
GDeJNyQLHBLP0Tsk3ttbbxJvOQx3kHjK5UXiFz4kfpVsEr8fCRLvr6w3iQ+RWPYDuSiH
xLs9M7O8SI6V2S+ScyBJDuEiNQ7aTXIM7PtFcrzkuUmOlTFukmPIfHiRHEMmzSY5ViBK
h+QYYw83yXES2G+S47hukkNwSE5cE8kB2CTHMM87JMcr8VwkZ8NwxYBbtrBWVA90PX/J
ng/FRXLMSr9JjllNb5JjSHu4SY4hz2GTHH/fvEiOz07mi+SYueG5SI7GK0gOwW5ijCtr
ZfmQHNbpkJyoaHNZfbkXmJfLvcCoXu4FSX0v94KQ/e1eGucs4V5aKrd7aZreLPfCW5d7
gem93QsXXl/uBcHBy73QYB73Um2+3QuYxuVemNK33IuJYS0HoWvhPTCRut0L8g9e7gWZ
Hbd7qcle7iXw5V7OHXIv0LnbvQC/3QsU73YvlTwn3EtN+XYvuib3UXO73Uu18nYvmGFd
7qX2ftxL7f1yL0CXe6nPfLkXTGpv9wJe+HYv1svLvVjrL/cS+HIv+47QMB+4y72cTloF
Jb/cS63Py73AcLzdC1jy5V4Q+r3cS3vaW8WRFnK7lxbJpMu9hOq83Au67XIv7ODlXmDZ
bveCwXi5F0zIL/eC0bvcCxJ7bvdS03i5F8jl7V4CX+4lSo57WY8s9wK6frsXicSyH83a
cS/D7Yf3VkXKbKeT4UqbFyCpFwtrWMvzb0xMTbhux/QXVyeLjMdYtrQZi8pd7teQq0pT
qIH0Nz4QhNOQ+pimyMjxSQmVeJRP4aJJwDlAhuTqmnkDB65hprmhz4PI8zC/iJJRlGOB
p807uTO5z2cM/hmCn9IJTLZ4DbM0CENHLiyke8JI2UgMJIf9dpZvI4/IkVArh2kpHDk3
+NLoTA/AE5OxRxuT+W7fP7g4Dgma8K5VK/tlouc6V3YDe78E4TklVXGRgwdTH4Yx0dN7
JxYSrhIOqFI0XEzUT0z+/nWVFMXA/A+NcuXUDEGqxCFNy/Cg2RhTCAdTEergkH4p7Urj
q24tqgCuLc82kTRk6leYyukEIFSG2UQ2/SmmLik/3ab80MF7iFcJupXZz4i5ZnS81jGX
WmJFOARUi90uFI2dCHHDzHHkvFOGCGhgGYjStchF9wf1qTVDRQaH1uThVTCCA4mbzJZS
vw6EXi8cPb+V0DvYrjkixsy7M8MK1+XEVVJgdb+vEiQNTDlq79Eq5uuNGEPgp3hijYkF
/0ag/4l1qfaG5Ds1p1hgdibW8TC7xn33UwUYyOBsnJDkK77JaKbSRf09U8kPiPThPWmv
IJhEJkPR5rKGFcy424HdYvluFdQudYN1BCZ5cisNLUhWdnPx92ouUsrnXoabv5Uwz7Im
mRCwzUnYvpbbJqDcMMWf8FsWYFrcKt9SscKZ64Euc/VKvvD2VAmpbKTT7BI5NqSq3hsW
ChaJ05VrYvycDO27wNtQMV1pEYiiQ6yY4DAzRKpxZEQB6CVXR/oy4jVvBun8fr4YpBfk
i0FWZFQdBunweTHIau25GWQ1ZaKSQRIcBkl4GKRuDQbpwG4GWZHE+GKQ7k/HxSArOPZh
kBWTnJtB1uJ9fRhkLdo6QAZJcBhkXBNBrJiGXQzS/fZ4MciKyc/FIP1D42aQCx8Ged1B
BlmR534xSOIXg/SSdjNI4M0gCQ6DjGtkiBWB88MgawFHuhhkNW4IWQyyWk6bQRJsBkl0
GKR/pNwMsmLF7WKQtSiqfBikd2q/GaTjdDPIhQ+DPHdIiUp5LgZ5ddIq6O1mkBWLCBeD
rHZW2eIO056g9QJztnAYZEX26M0gK5adLgbpsm83g1yqczNIdtthkOrgYJAuseNmkByM
m0FWTFMPg+ToHQZZsVx3MciKRb+LQVIuLwa58EW8omQzyP1IMMiKPSkXgwyRWOYDseHN
ILFJCl811fnXKYnJxfePtZHKS9pHW4kYHa+YH3EvwcZBxU+JE4YeWccuwLUytTZxsw4B
V92Y6EJ4wgC6NRbJ/D3aSRLLaF4TRi0j1r9gBPcrPF8a17LbXaLVggpHQuJXuVTlOEb4
SQKko1xYJUQ3NC4BVQRPinac9aKqG+Mbjgds1G61KxWcZvTtGQHYr5O+pOW1iuWWV0Jz
BZd+JTS/SpDQ7AX1ndBcMT+6Epor9oxcCc3+teeV0FyxlnYlNDuue2WDgGPELGLCk9Cs
W1ePck3uJDRXEMuzHrPgGiOYj1dC810So47dK1dCs2NylahKGEQlNBPeCc0VFu6V0Fy5
QnUSmr0n+k48JviphGZdiHRlf6rdCc3rvT9/nJKR74RmVXO/V9WMhOa4tio00p3QfF69
5AQW5pITrzNSbH+tvx+7QokHMpRIuEKHFRtqrlBiRebvK5RYkY97hRIrskOvUGLFdOgV
SqzIc92hxIoJ1RVKrDCur1BiBS+5QomOT2YVwQklxjWFEgF2KLFiu9EJJVZ00wklbhg2
pF9+p4/nCiV6D7zjDP6xfoUSKyZiVyixIi/8FUqsmEbcocSKFNsdSqxDG6g2zO0VSqxI
kr1CiRqvmHARrCaucVWt5gklsk4v8WhP4/zn14IP6fm3eMP4pwoiPwXj4IPiWMloYFtu
Hhf++SNy3s4NWGCMG5hXIPPTuLtzz9swCHNYmMs1I5llTYuw6wQTjekuPKWdnOj/TBkt
7WhcmNJE43vuwLrTwBuq9kyyXW4v7TPObCrgmmGMZmuDXsww7pJGZcSElHYUCV24A7G1
r5V74bB9Yt/SZBZ+xWR8RO489694yVgSEnMRhF26piN+Nxgis41jJzfI02zal7OsamBa
UfmAfYf31YymMvv7wRYr/0RbO+DcMDR+VDtVXARRJ7ExAVfu2N9ElJRinrmiWzHrRd4C
VpmhAjMt1cN2uYE3P1r7RdY6VWJGJGTjJ9jkLhkkZ4ylYOAx887cRkWWuTCe8Eacy+iK
MZCYor/nE2E4ocI0UOy+orFCl3A1v5tq3hlv+bkdqUtiC29Ek1O9xGdbTFHX+DdsmG95
r1ov1drGuWFSGrOwP/wfDxEo+fdDBLAhdmLmj/56eIjAv/3z95/+7s9/+vpnnxpQ4C2R
CoDsPtSvMLOI+YGdaZ4wzcoXNCblxuzfiX6R+ykVBo3pxUXZSqdkdBGpwpBbpGJXY4kp
5xHhPWQboiII2MypNfeoWEYscmCMCzKeF/wWLMjEIJcroGYl/5MlWWklyAth7nXmRuiC
yStaGBhfwPLOfQciilWpu0gg4H5yPlHlDpAog8TwKT0VRGZ0ZwUy95GWVEgKUIJwNBKR
H2ZrY7cnEseTZaXZGNNyFkaNXM6e+w4ky6RCarIbmNCpq4cCrQ7SuGLIneYzZ517fH2g
ucEcjRuRFqIbXHLWAQHrDR0UgaJbGvM2B5xG/F3ZcHeYSoxdsCrFEqlSsJrI0MtVeZYH
a5doYWAK6Y2VJqUwM6Ypw3IW5YEZcf8wAaS4GjCnLevwBlRFdyBtBulEiZ6rINTFuGAh
RcVHk/KXmL/FxFnkLuWibNGkezPt7rpWmV2KXfGFiV+8QsHgvfzs1HhnhNE31N4uwoL9
P0w95laiDWusVu8CzBEMQ1v1qsFd0ZSUUZUyW6ZklVy+IMcjF32vMFkNz1QIU+MbB5n0
hl1yFagpaxG8pcVolo7OSwK7hRpX/T3mLR5I4o3gZqkr1/MhGft1l5jmhyx5kAD6MFe/
1CoDg0BAGTcu0Te7hNGxgilQZoIwkyaZ30DAXslM4Qa8hoC3wqLUqcTiOtXHKSobvYIG
BVwKVDq9BO1J3H+VyHgi1ANlWJlnBVq6MuVKVSOMkzHCb0FkliPE8hSVUFaZ5gxtqIp1
s9Ur9RPdH337c49AGfWMwBIUrCo2GfQQi6o8+YJAAnoxUa0PjK3wu+CpEg3YKryQRtrf
yhTYh/2F8D82ElS1AHmVOcetLVIHa1j+WIkrhniWNHJ8mAQ7aSq4+xaZp5VZ9Au6X+WC
1i7I3DRRsImFaab8FiYZ+ht3ViYrxqXGDRJMPoV0bZyCYZ+SzKWb8zhYpunlI2/8U+2s
dt/BRcGV8lpiN2XRUQN8gE6rIGEABg7RtswE5geg6S/qWo/MZlzgzs5iJgVesOq4jo0R
xcHVqUTnznRWpCnwbzaQ7JwQozQYFPfKKBO1DblHw4oZvMrDvcQFxyuEqXm429tLmBVa
cMAAaomUEzQHbhHfDvxTegfjue+QdbPEFMUNy/ZbwsbkY6ZssqVK7UVoj73nboJR6HNH
5/RiPz+4nWfDSQZz3s/d6/SbMxK5mbgfy1JLZaRYmRnh7LNf8tt19S4U25JEtUwZT45m
GyL5BZE9JqE3UvuCKR+T0Bl63NCqkjt3AZagcnwAH8/yblh9QbcFxgOJ8YJVQuZBDrKf
wahmJmYPenmkTMIwWiwPy3QgUpbb8u0lK28cW/cLPXzhlnsvqRJBx4QS3wUtRT+vgspQ
BySb+dY1MnxpG6vMIXLWYTLrYoMy1Lx1mVW8Bx29DC+PyejbUAdchhqcoM3bUN8l8cbB
GJGoIDPM02FhVTQzjEkVy8QqBrPnJ2dgNGNDCd/Yg7IgEh2k6lGgvYTUfHY/TSA2VmcB
NCLYJGAQYqZtl366gKk8+XQBiE4/XC/g7gLsyX13wVUi79daF/cMXt9IN4ppgJsMXOOW
XMJvtYk57822YW7GSd2GmhUcO431BZl1pk5rLJJMX+3ieOuBoj0WKvnWKxrkSAuW3/IV
5AbY4sN09rQlhI1wOYa1D9E9Ak41uLlr78/mrl0dv7jrhuKunU44uCpmBjd3Bft6cVcQ
j5u7wmLc3DXi1hd3xR75m7vymJaLuyJS8OauWGS5uSvCg5u7KnS4uWtcE3d1cLgr9n9f
3LWn5+auC4Y+Ai7zCTN0cVeozYu7Yjpyc1esoNzctff+G3fFoSpv7srTfjZZxe7/i7v2
MB2BtFF5c1eO1+KuXSqmFmpc9Xd/Lu6KGv0j5oQd2m/mhFDGxZzmM2/mhG3XL+aEuMbN
nAZdXjCnMevNnMasN3PirYs5jVlezGmM8WJOY6SbOQ0o9mFO2DT/Yk4IqtzMqfNbMnY9
ahXUR5eCFw1ly1x4/MackDZ0M6eRy4s5Bb6Y07lDzAlBo5s5Ab+Y01C0aTMnpGyIOSmX
YzMnXRA1GiXfzGmYvZjTwNTkMKfBXUViTiNUNZjTkBdZzGloEXozpxE7TRdzQrz8zZz6
LC/mhEOibuYU+GJO+w7p1njyzZx2/yyMs9oOc8KpIjdzwukOb+Y0+nMzp9HbzZyGc/IX
c5rP82JOE+06zClU5sWc0GcXcxqKd4g5QVRv5oSReDMnHGRxMScGyw9zQvzvxZwQILyZ
E4KZN3MKfDGnKLmY03pmMScctHIzJ8nEMh0zzc2c/l8Delj5HcaA3n/7h//6P//hP//1
/4eAXhAWQ1xtDLG4wsze5yFfurDo2cFDUfBTkrhln0QOuYUPlStSPx8pHszDuua9SSsT
Vymmie8ZkrosMjWR4MCH81zoW8iezuwxwqLdVq+SxK0+TCCTInI/FoRpUugJfm4PRhj8
yJ6mjbeSakOQluYu4NDhTQsjEkZVzFxWsIQm4My80QRon5J2m/AaDa2lrJhNwAdrY+MY
YrWnySxxF5fy+ZbdXw0IXrQaEKTIkC/4SHATFzUM51b0YAI1qbdrkqHnLilJAmUXg8eN
VKYQHjzciA4Ee8ffrQX1FBxJur0K0lNji2Xj4CbSOxi4AEFtuZ0tp4jsxnMHIuyYZfLq
Hg3ejqOuyhrUwqhJ9Ekon/Fchz1r4YYOn88n2IRfRwOwfYZbQ0OaufflkvfUV9x3l4wn
KDg1wXH52l2WhoQj9gakURZRQp4pb0W0tlS9p58Ik+Egi7ZIe6Alk9ifEuHq+kJk5Nyg
QkJjNOGOn681eSKg2+ZBE4TfP5bb1a2cQGDbS9HG1oAlLza6Ciz6xrgNhtWgRDbsI7O0
4t2mDRtZOyO4cfbBt2yKfCxcmZXMJ6KkcVjXBMBwPEAJ99s2DLarB+IGaU1WiueGNpR6
uwtK3VqFzG9kzg1u9s3aGBR9FVq1+iq0Cnu8WltapR1gSXMg8WuOKVssurDk7QglT7yY
e67BSvmU/5M03xB+iiibFW1lItEfHR6T4Kc85rC4FqaIRyPkA7H/tF2mqij1tCDlNnMr
CnpiKBXWkoQciwt1XYv66BC4d3VlKHJSCacxv04BbGaVVnD/DTfsTmYWE0QQFqnPRasu
TFvHMQRU6IA2wtYGLhqtrvVIK7mI75SinU+JBJkOnJxdmyarJkWNG8sgKziBdwqEdWZF
eC0agIMM0tdvDTzDiADKPWM0TA9HWZNGQ56wop05cvhPAdd+DatfJA6Yik1tc2EnF9rh
hX8eS3Xu4G4KqxJusl8j7jrLsvTwiVVm4fu0Ebs5Igwb3tpGUksV1zG7JLhtSD4sET83
qCF4JZU6WooE6CAI6ImA3wsWmoboGXsXJNpoBPg4Bc3McOf+Knoq5NoAL53a3hvJUCuE
I9uK7K1SdjTfqvZAk9lyfJ7tVxoT2q0+Qc+bqTcfnkBzYGxRvEpmkO2Hjp+ZawyZjOj8
pmMcOH+B+ah1xOrG6ssKinu6Enkva2ZCoZFQHbFDCsXvLo1JFC+XhoyH26Vhgfp2acgc
fbs0ZJveLq3RKYRLa7KJy6W1M/dPKW5d3Y733C4NuRbHpQktl9aaXS7tQnJptMiXS1PA
K1xaxMaWS4vY2HJpCqPJZTWd+3ngfLs0RNsul6ZqbJfW1rlm26U17R7cDqv19nJpZH4v
l4aZwu3SSIKOSwt4ubR9g8wt5pOXS2u9vl1ai3NylkvDsN0ubfVVuLTVV+HSIEVvl4a4
we3SmIl8ubSQtyOUiBttlxZzWeyW0O4hkTMveLomt4bor2GuW/uBvej46V2A7JpgdtiE
I27hdp17xQzlsRonzTYc4jgZuOL+VYMNJN/FJre+TtUSRJwgluJxnBg29cwPAws8/9Vh
VSgtbDHqPscaI7Bpnri4wyiGYw7bGbKuQ43OGCGSPCPOWVH7CjVT/HfsuoaYGSosplGQ
Yw2B7zo8nUduwOL1dbw6o2TYSLjuCF8fLd5wnSm1CybPUePUmB1gmms/3MSLxLU4Qh/x
6F3DXz9WuN4w38kmK40mFJ38syCOCBgr1IiC3hWNLDz513A4J4OPAnMdeiaRwvaaa8UB
G6QGfziBFKNs+L0gllDygS48mtvkD3cO6fgVBUgdlk8oHLOstOVJETbvBuzjnEzcW6OH
wMW0Cz475MoCJCBxKqcTKW3Urr5wYwKOFhgPBNnad0yc+mg4T5ZZNDCf6P4RP7Wx5X19
AoEJblTqWmuJOAr3mKXw/VMyi3OfqmLS0I9RI6AHs7Dh5UT3DUqx4QsYDNXvgPCTsSSh
xFND+KUxLsXq2kAUrOtoPwLM3RPzUHVtFIyt29Q5Fpja9SU0c9ExLJlG2UdKVUIwETvt
cPCm1Bhf0a6xrkoOnm/tcsGAMbak8e+fWuTghiteMibG+5u6qDB4UZZMRJhaJ8gbfopD
zkoRX0OqGFtbtDF2dPqIzcQDcwgsNv7FHYnnDhpCs2QI6YltgC18BUqwcRrd0TnMokLz
ibXAjXfKj5egVggzU+1h+hmCHhvE4oMQDoBvEjGIw0Q2Ekn5oExTRSih2ocPjeKyU2fQ
Dl2v4K6GQd630FrqkjGcz117Jl2AHp75OOn3QFoznULLktLJ4+JIqkaSqpULFluUa8TL
uSTTtIt1cvKDY7mSACVj0lHz2mDTbSqcfHURJZNDYhLGJ0vPuEbA5SD+jRcOHQSgS71p
6FrU825XxE54Jg9SO7vsZdiIQhuk+cRqdkAGSiOpSAVJzpIHMqGhOfIdCiOwNrl+GKFy
BJpgwmo/I2Tgb7ARUwC3ziIZwrXOv4oO9BHQCb30qGjRjPATTte66l9Z8YDHYM+zfez/
Ns5pXKXDQjbWpBjn/I9/8cf/8FXrPzvMqbNSkALAH6/RGS1J0HKcuGfKFTRkayGihZ9Q
4JKIl8wNvwNi0sUD6RyWN9QhaDXrYCEkxFWe/Da+dj0qRc8e4wFQhP4oA58lbsWBRFzo
zDpi4ElMyV1fwtNck94fJjy1fLh+f0Ed1TYi5JdyNH/VwcLPR/OwOhdczlIzLclhxQpB
4lNSuMbh70+aS9ARwa7khwLFGZsAl4kn+/MJCeICbkBtJeH5JxYnpg2+p2hmRAXjwzof
jiyZh9IM0VyGztYiGLNpLSXdyArKE0eOesDJNDPDj0blsIEM3TJxm2usUy9aJYnpzujP
/mgd8R+X6CmUjKJZkHZE2KPjApu6ypABy0jujFMCDL+TVeNANR7gQ6o3FCfm3y3Ooguo
piGkS8q74CPWih55uK6fJdoBhkhpwB4ZgYIgnAyE5xJEozIc8NSYhuVnid8uIStaEgg+
OMeG+MGboatLgK8SizyLpMO80tRBhqMduaxc6TqaM5pkpintokmBS7zG+lHg+NDPLdLr
u4R01zohLgqMKzsSee9DMJNEYR9a2hmS9BxzW8D9bRDlms+3sc7BuILeHXB9mxvU8zYe
N0xxGB3zcLbxGHAuqwuGFEFVbBZDrhVe/lqUYKTY2xMLDEjIx0E+T1Nq6nQTzI3np4Q/
WKZxw/6Cp59RrUxc+D43g05ZfZW0opUX/6RWQrEveVCYuHxOb6qqJltEXz0yrZ7OD21z
dZj6eQXpVt0l33cJPC4KpvhtHLRMBeGyAUicQI2Es4ApXcpzoE4AAKRGUG7rBvnRFuKA
zS7l4UF+l/I47rfyuJ3Jb+UxpF8f5eEi0qU8YCxv5blLpDyzl5fyzD6O8kyuy24JBgwJ
TgG3BOOMDrMjwfGln3uA5qU9hiT22pYEvyAlmNWT/WYoVv0ZEkwQ5nn1u/7WCG04GMGg
eR52De2Wj8W2VCkc0J1saXCJZQT+GJdgUYz1e0NFMp7C39uxwoQ0SgQvl6zfS9CaWFIk
nTsiecYjz7xSPJUDxh+T4HlUFEyGnQt/6DAAtmml5bm5RNH16IiTy7Jplw89B01ZNsme
PMmF+XNFC+OV+DGIct/RtarR5wZDgeSA3LPuf2sNANn0pBnI90HHmY4r4EIcOr08OgNO
G3issMO1f9FKuFvG9XQJcgDNy/r9qINdXMk0Tkkcj5KfWLPSmC1Hb/jBtiIx1u5t4znZ
RYsuvWs5igtyC+Mno4qeiJI0dOqgIqA8uI4H1OEAzbwxa1W5PrRuyEWVhEykC9eiTWOn
ZDx6IulcDyzCcB148uc00SvxxNKCcq08Srog67aOSwsVYVptXHv4k358kC5ydC1mMMMH
A9sVJUD6PJqJxVlMG3CSI9d+61RX29A++aU5pe0fQZJqkIwfxUGu7KU4yMK+FQdbsi/F
sfm74iCo/lYcBOLfioNU7604OHVmKw7OiboUhyenvRQnFrQuxeHv8l2Kc7AUJ/ClOOcO
Pn4pDk6+uxSnzJfiWHopDvLC34pj7aU41i/FsX4rDi8ttbD6VhycmfxWHKRk34oTY7YV
x9LvimPPW3FwHMKtODzj76U42L1wK07pb8UJfBRn3xBqUcZbcSz9rjjIWL8VB6dH34pj
/XfFwVLSrTj1uRSnPi/F0bVQHK5BXYqDjPCX4uA4h1txsOR0Kw6y3F+KU7Od+e7/BjCO
MBJlbmRzdHJlYW0KZW5kb2JqCjUgMCBvYmoKMTA5NTAKZW5kb2JqCjMgMCBvYmoKPDwK
L1R5cGUgL1BhZ2UKL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1BhcmVudCAyIDAgUgov
UmVzb3VyY2VzIDw8IC9Qcm9jU2V0IFsvUERGIC9UZXh0XQovRm9udCA8PAovUjYgNiAw
IFIKPj4KPj4KL0NvbnRlbnRzIDQgMCBSCj4+CmVuZG9iago4IDAgb2JqCjw8L0xlbmd0
aCA5IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicrb3Jjm1Jsh02v18R
Q1KAQtt79yEJaErwSQVonAoWGyGyHqgqDvgh/F/5WsvM3XZUQoBUrxKFG+Z7n3O8sb7z
5zN9PPjP/v36/dd//fVP+///9SNx3P/5+v3j3/7p1//yv/WPWj+f+vGn//hrP/v4n/Gx
tIdGWh+5tM+S08effv9X//Tffvv+L3/77x//5q9//W//929/+frzv/7T//Xrf/3Txz/x
y/+PX2m/ntrz8bv9lT6+f6X8vP569l//+ddffj2f+eO//NpPxueTP3Lv6XNkfLKl9jn2
QEqf+2Oprr5//iO30T/z3HB7Pp+54fp89vTx9WvPs36Wjjeez9b3G6V/zv0NbfbPim9I
6zO3/Y1P/+wDnyhr78xeWS/7yf5E2d+Z0obx8fKkz1wE7Hdzynsb7Fmq83PuZ21PKgVw
z3VNvO0jNQ/MgZ+ude9hn/jmzJ8BgFnU9pmHP5vps+xl4d+85/ysz7af1Wd8Js655vn5
dHzzXm27q6xl4hf2Lgz+Uu0L88UnRvrs+MRebeUBtL0Dde9Eyw+/o+V9tAs7Vz57vXCv
BZ/c33FG9g7tuQa4YpM2XD8X9rYtnAo/YSM6UBx2Sr3aPpXPkogePlLyZ96/nPYMeMot
f+6JpbmXjSPt43NlHsMzP7nx+1v3tu7ptMkjxbZyNQS4rUUT4LM5hQurfKaqfU34ntE+
q7Z1/xLQaS8gAVnKwBT3xDa6RfgcsY9gWycOIq/PuaeO7a4D6LbxFyjQmiFoWe3zwQgW
O4Rua29i3T+c8lr4GAGssw2ipp6lah/UT6W9ioF3695tfnUaledR90Zhvb6vdW/gCLDt
/BdOo+Ln+iaWNfZR/Mf/CZtQsbg8N/Ltrfs9jIyNTQ24c0b2RtWFZT/Y0Q3viZW9iDkF
YBH7Bf79bX+P2TA9gJuMXuDeTHzLppOCgwXW4MNc/tzLbwKwjXtNzcDvX/c38WrdmP3w
exqwfx/C3jF8zz7vvHTQQpmxBnZsw8CAPZW9pfWC4CFF72ugFZHb/sIOGJ8tK3PXAfhy
8bcvt+9TWba+yqOOI53o08VCcs+fa4NjM8G94AJqJ0C8qZ+pCfwWB1jVXq0tcXq5gLcd
cOOc2JYPbKQkkhqPHHMBoxJQEWgwN+2IwOrGkL3yPDM4M37OGO1rYK9hD2y+opGaSaaz
in84aRwcKYkLMLy62DcXuJwh35YAq3yUZyPFZjqGfGkPjInd2ODmWgAzzvuAnfKAJ6WB
vbGpCTEzPt6wzr2+TQcEsKOboPZ3EMRZLBK1Xt2YYZ/bqMOTmVhUefbWZYmCzZwGXi8V
zHmfdf3Ed2+c68XBvPYWdyMDDWyZgDPaLHEva/8m/l5EOwKY11PIpvisbFrYIiEvbEMO
cMHXcRU2sAUINuh8eiNbBRoBb+aBMZONsPuv8MbeI8IFG7ARb5AtAm7ki46Ka695nwp3
Z68KMIAONCOAdzeT6cOfge3tv7HYdcH9dcbIObB5dvts2uS95r2H2M99HK0K4DLnp0Hf
kpaQw2vzvgrOvv+FmF4bBzcvTKU3MLS90vJpm7ppbnBTiz4xycv22gd4wsaNCgxymKw9
k9+eN0REK1NxOODZJB8YpOFDDmuRt7rigRWACX8dgtmKwAN2ZV+wwQHKOmDtn+IAPtAp
MPbHOzBik8JDqQnRU+YhHdIXeNMs2jbQEkT+tA0GE6ucUKV2YqKKh7FMHG6KwAoa2bEx
QZzec5nk2sJ6Bh652sQ0xCOL8HJPYU+FZO9wULxsBMe6cSeHj2xagSxfff/E/sUCnjcc
JYx97PV2nID4R9q737EIzfn3ODKBGt8a2b9b0tbAKEg3W9yosOFJteDAKZnic0b2EilI
BzWRsokNcnhCtBPANuxv6Uvg9y/nrXoV6hl/eaPlxBFvtXVLij23Dtz48hUJ/DYwb7Yl
Kefvh5H9jVgd1kTFr1AVK6nbCT9JANXRrRYsgdiGSqVmg9TiMLJxmVPfiAmOnfZRprDq
/WKbZ2/vCeQtV2uxEwCf21xln9XGW56A884MzJfuvxWu/GNkI+Ee2BhXxI0HecQe6ZAv
hPmRvZ9bRwjwlqBkJT5Qu5TtSUWwZNgN0Ks2URLgGWVIM4LcxAI9Q6/6juJ72rxnlFOH
/uFnZKCf0d4DrDqcURixUwdHk7JuP0cB5lOZ0vjA2KpAacsYwDL6QWgf2ae1iXmfUuex
bsUQZzTBnQjgyGfyB5vY9KlMWjpwt8O8I8PIYNL00TTP92qa+M1S/ZlPCFSxPn5O+eJJ
2RpAwJM951qpYOrvhwSTtkoGNnTAAowguAGy9wJtr5UId+waF0HGv0dotGx4gZkVcB8I
hrzZPCYO9XEJbzZT2eKrlEFba0/lE5/f2wRjMIPn4inMsySRVaF47pFHSupWWoEvBUxv
mxbktwAoCxNPXs+2cvcIMO2WL1I54rsAu/jgXgU3TKDzEIAuBcowBUcg0ShKibpZjHEY
TIhYCf5g+lVtZPqm6j08ioUv/D4aV91To2pMwcs5pAvmDIPOTFFOoONs99eRG+u8zOAi
4Eu0c9XftQnLiR6Y0xs9+mb8e/8cQ/pDPelbesP8owEJV54DfqBnqnjUtjZ7dPhLTCmH
F7YQnfZCLR+H/XQoEMduwyzbfIxdmkWyUcXNIlDANjT2yKD9mIckPA1lMK1tmG3D1mFi
0yK3OG9swtraXGmF0tLX1RotGDMvHPx2ytkagfQiszBeI53ESPs/y6ZqeGOrcNRraapv
SUspSUVpkH/DGDepvFcMGmqlGoaYLVLgdhk0ZHDsCbvTiE2uPJXWH5naxlUNJheVDDhv
QG+ypYJS65YfmMaWRVIs62YMHT8Kjg9/xcOdlTZmwLbX6HYgBFzoeNSoJ8HqnXRJZZJA
e5z0KoxHfPOTqGNXqArYo2WWjMOzmzZ5RgaVM/pSJvd90FGA3wbbMBhTwrmfxxXIDyeP
/40Z8DVAQKjCb5lkVtiSSlqvmvmgkP+6grRD7xUKdlpZe2TAPDnn36G6m0aO3zDSuswZ
RumxwnRaFZJ+0Q9nxlx9Bg1VHO8iSA8MDKu9vgqrS8pzAhvdK15bioqJnZH9TTNL26NL
rkwoIiYpH6j1ZVvxZpgOTh4OgdEuFo3Nzd3dNw7osnhuATaTS16Q/R+MgGsPLQRW3ISr
rn+4Y8Bh8seGNd035DTa30AdbMPlk1+YP8X09/HhFzNQ59vAtRmh7HYjnb1jHYT3/cu9
FfXZ6ibVbODOAlx16pmizGFaJjSx7hv7h/mFNBtshVDTez57ZKDtkZ8smW8Bjs1N5KmQ
1crHuQ/qgcX0bS+sja6zX3ZdoT4fp9HWwvGhLToecEnj2HvqHP4+II1YgRtx9gCVtu9j
Tm+5sujZpXYDcBpDN3BAqSTjtAHj140icsMPMQc+wYTn+/TMl1apSO4DblRuoWlh26Ex
zABOelRNFePInircvWDemzHWRPN90XVCAGeeqTnrWakg7C1X6aHZaE7VfB9rA28mi+1g
dXsq6bMZi21a/Waj/Mwij8PyjhpPgAKXdp49q4nbgFfGAeExlZjzATBX4EaD5rlReslR
lDtnCnEyA7LvNSdxPvDOjrWIXCAKHsLmw7kjsP6q8GtCKPzRSHmMGZgHao8UeegqddkN
N7lNHZaA4UJ8pIKN3G/Q3A0lezJXKLSZzoUX6T3NNqbJVjYQjuDgIXP8oi27kX3/Q38m
PbYEeHpFx8Fn20TCtGD18OgpRvd5TDh3zcmk098r4VE/dDlWGFdUA3HUWBj9JRv76hJA
JaVjcfasGT72Jnx0GPb+dG/KY9hA3r+F+yRRFCrmh0hFhof31yyH+5uUa8qRlIGFgZTB
tV6kDFR5k3JF7OSSMoREIGXo8C9SBs5HUobvIpIyVPY3KVNVCaS8ZVgk5dL6D1LeVtuL
lPMal5QBBFLmMyPlkp4XKW+5/4OUgRRvUobuG0m5kDkbKQMIpKxnItWyNbFAyqWtNylv
pTmSMmyqQMrbXv5ByiWVFylv8/1FyvAXvkl5r/wH4f79CKJXb1IuT3uRMvA8kjL8lG9S
LpvZRVK2uQslt2X0g5RhggVS3lpQJGV4/F6kbPh1SLky2GKkXI04jZT1zEiZFswlZXip
3qSMJy9SLuV5kXLBvJyUi7i2k7KeGaFuK+5FyljTm5SBDZGUsYBIykaGl5ShVh9StjBN
7fvbXqGcPVLeoZza94aHUE7teZ1QDgEzPvi3cwEEym4o5wUylFMRdg2hnNpWPqEcAjeU
Q/CGcvSqK0dtrhjK2XB5h3Jq26roDeXsqYwQytmac32FcipMtBDK2UhTTiiHgC8Xfx+m
t7H/Fcp5jTCUsw/hCaGcDfYTyiFwQzkEbyhHrxr2wti5oZwKiyCGcvZ6Wgzl1LbV+RDK
qTARXqGcvZ31Fcp5Dyx8x8atVyinwpwOoZyLIwrlOF5d7OubCh35zDbZYxO/9/vx6VWa
Gk1GNiiub/U8pwDv7Wru0+PAnirdeJMBuQ3P49MjwHWKtQL8Pt57vQpmmZK+Z12/657a
3mVXkQ1yDXlQZZJDL0KF7t069hatpg3H0Q4iExhCF/AlSZrtGQNMjMToVXMN1IHYeQ5w
dxPqjkxYfXSR8suly8FNNzjPYb4vkNV+sY7971iK44AyEOZjSMph+G8Vw7KRCZd/0f5u
s7bC3mIUrDNw7LDJ6j3d+wajWvsLSI4Oji37SrpRr70GBoxINh1TgFVKJ22DYeYbBjld
7n7Jk7zBAl+cUR3e3iKMfETeNh7rMz7Mp+MId7FywpHf3hHGBnspRhi3Cb5ChHGDJUQY
t8E/XhHGTaAjRhg3XE+EkcCNMBK8EUa9ahHGDaQYYawLJBQjjHUhjnsijHWVHiKMdYGB
hQhjnX2FCGOdpZ8II4EbYdQzCyDWWVuMMNbJ2NyNMO4v7jHCWCfSJm6E0eEbYQxvPMKa
UWOEkfArwrhHSowwAj4RRgI3wmjPOMs65wgRxrqe+oowVkTtboRx7+E8EUYCJ8JI6EYY
9488McK4N6HECOPetfqOMO5NrTHCWOdm7yHC6PCNMN43xNtnHSHCGDbJB/ZhhgjjxoAU
I4xYwTvCWNdWHW+EsS4JrQP28fIdV5j6IcK4SSHFCKOTTowwcttuhFEbbBHGDbQYYeRh
xAjjXkEPEUae3o0w7vXWGGGsSEMJEUbiZYgwOnwjjD5yIoz3I4owbvSpMcJoKGH8Y693
3AhjHkxlanC+PIpeAEUw0CEZqKrt3W3PXtvzgj2uekYK5YPwG78jWmH4hQBDVRQpBG8o
QK+aO2x/z2CamKQaZ7aKizUHTa41RDmzCza+H0b8C6cCsIhU7e1pD8SJ+aUIkMbJUgje
eN3+MkWjyc4ALlG8gZvVtuX+dwxU8ZQ8GW9pCYyuwBNmALcA9iEhzpG6h970CaeNuDls
QcI5rrMFBvoWwEnUXlsQRhSsawgcPdfTuWF6YhieJECO8QDZCX7/cl+6XhUzbkjJovFu
4CZE6YA+kNMxeh8s8mH0yyXx3t1jEVA2+sAVj3ukmkMVX1JwJK3oDJQ+dvGs02/sqHsR
HG6PY/4P5NY1bHo2kqbDs8EUoaN+s5n9I0WKygH3ypIpYhqAMx2McpNWxhZjWbDq9lwJ
kOtPsEo9YyBt/72ckxMsCENY4E0DlZFIKtjAzdKY9EZ9CGcDM276l2+2tieazHi13MAG
JrD6h+tnrSCZaAVYK70aXEM4sa2jc/ru7N9YENEOE6+pat43dM74CbhqHYSfK+IBrPRp
vhIcIWQTuYHhFD00/bVnG+VhDktstcxUNBy8/jaNeP+mHom183vmgWBx93U5f4Npe62K
vVGPAiLyy+9VUOiZ1QUuBdtNXnGmNTV4O5AKWoyegTy1BlSDN/vwUhOZrT/UMH5X9sRG
3dYmZTMFBMB92D1dsHgukw/snylZ09izQDZmYR4tEz1bBdEoioeYwx6APooX9rInZrWH
gRBYwrZqLLRJsD9kRlTfaN5vI3dQWEBn2d/akE5KGt5fuml9zz27HtSozezpLxk4OuwG
+XuRATGsJ2hwezXVPF+ZR71VCqC2hw9ttsQFRtgbjH4cPyQQVre3hzpKY9jE4WsMnjfs
2G3JDjaI42Bttr0kCphMda4h75aHPHj4e4vWJwka+gCRnxOkaOygm8Z0WEqF55ML6obd
BBGZc+rRwGbLyYwkHA8CYIOqKba79TdK9U0BjlL/73ntJf/Ma88QynuGC8GpzXD/9Pu/
+h//cB57TvBSbB716AB+DyNbEu2VZLjCETh8HuULM/WmHPhrfwLZFDO8sSjkn62DIbfV
QcRbB9+3gb3jmyPx41CkH8uYT42S12F8IMuKOm/4FBUA/rkI7Hfe5/ORINPTP7jf+6T3
PrCO4N//81//9tv3x3/47W+/ffz5+8+///kvf/vrx9d//u0v/+kfryjIaWMi3CqFPrEN
7rVB7VPGYyIPqExK1N97O6k6Goi4Id+r9D6BuyVuptRHcLfFtz1ZaO8pX0AcodCJu4Ft
Xc8lYL/7wDjyZ8+W89nKFPapIpePmvn+PEMAGSFV6c4VhRBPJVvjzxsAU1pfXKf5EaDt
5cfTOcNIh6NtH3wDA9swLRRINcwkY60E9pchE6vZs/3RvFlWHfYqRE83fyeqDMDmVjq/
9GV4cn+YIOTwrARbfYNKKCx7D5B0jN/iG8BKIMwzBRAFsUW9nhN9umwVvvzwdxDdWA7U
LM5v4KQlkh8zRCuKKKBzwQKvLBnIiNvxuPiMQZ4t5J7kQF3K/XewMN0V9AUPR1EVCQl6
tTBv7gEYtZPOJrAMWYzUjyQeQRjcHnUZSW5yRP03AE/NEoD9LUxX0bPcC7mzsmodROkF
VYwzYNn/jLCivgPp2wgeAVHb0tr3bz7Nn9n8OgMY7+lySVBeOfLAwPj9DmwDduITiuTs
b8AGQTOoArgCKUR8Br8OZtiYd3jAPD+FTQYnOosyM/OYdKHaDgSRoUDSZ0qiQV4hff+T
Wsn+7So/JtaPZE6erxE6wirNn2kBSO9Abc57gfcY+3PcnDkpgycNJUDxHDvApmQZB7PC
ZQDpHhhbr6hTIxNJFB15pNjmhcUCQj7yAbsMmjvQsER+GK7RvqjJ8OsRMOhzKsVoj8jD
2JHPt/BGoVJnXtgLw6OR9AkbQVXVBwUFtKlOltmodhOglHpoBegZ1K39d8lCmMWASupy
0+FcHsYHEhy+LELKiM9jNzp8lCR3JmxjeTpYWNCdPuZ97gwA2jOkmuBzSut2sPMniTMa
aPRwZtpXXBKTiDI0LZhpvSY51jMSSeED7YWuAJIJYjNdoe49U6br9M2ZhzikD2SIT3I5
xTv/aMT8D3se9E3uEUanMowaKEa9qGzpwvVTqHwGBgswzhdo4oaPdQpB+YvL1r0OL+i9
28sCRzYdwAeEXdwVJAkNJPvv/9EQG0kE+8hS5zMkTRCHl1gVAjrYq/XIvN8Ss2j3ECEQ
liO8VnQCYqbMj90wMAd28RBA1UQOKj3LMkK6jvDCiqjxdRuZ5K5UrhYpqjLH/5Jo9mCZ
9m0UyhJnx/sXZ8qXhOnZyKg8AWc/YCO/AEg5goDIgDO+RHh8SursP+DZGjDS+5X3dOLj
A1PlCCg16tq5zRdwwGPvV8sfl18g8QGLSwpsjS1oenKOABE4ChOB93ZkqucDtVRMNTeA
W1WpD9mzRsLeAOuBEmdWmtKMDGzC5P2dYDMOVmZ8E3QkGp2+jQMqa/Ai2Vi0TjI8sviq
+Ui5Qo4QQlkz8ZRIio32Duq3ssimKo1j0r6jBMiAKK0cHJJhDk3VS+UiRZjnBcEARW6I
hLVCnSv/nkk5UUIPzOixDKczzQUThUjik4J/ngSDjEaAdBIdUNKKE9NAWZpYpeN+wyQ2
mlwEjHzgDgCIuVVKNr2KXBwwKnhVBcvjhnwtnZvkCWpf6pXbS3F/B+didtfXUTtm53RI
e6DLye+GKqa/pfBQF9WjbZKDt6HcC7WqB5atxkX4CLn9/Xg3Mq1EAIe/tE5ofvcNukw3
XKWHV+ZmENZSq8qz4JUHeUF3Q+xjdrKBrr940gr36sHmF5jXUEWhg1NWtcNrc4vyccyk
RYVgH+bS318yLsCbAeKUJiPA+5/Eypek7Oe9/s4KLKR7QbmaNTuiI0eC+8vUhoy0Ic4S
6h1ICXwwH/hLhAev2nlDtIUoBIWUgb4/Dg+qFpCJlWefyK3yxkTsHgII+UhNvLESUzH8
8ytNSU0Dt0gcM3w/yq46hdMSFoM9fByBbSQjvitPK/fsdymyzXcX8h455kBVVFSCdHGa
67Hk5P2NicwPIYFVJbCwvs34obE6OKjh8n0NdLoC9QPAn0ZPzd7vRSXdYAp1eRdtBKcK
10C/n8GpgrsiwxMFqPDwIndAOOGsY0Hyd2MdqNiC/FmdWcO/h5HxqCiJI1BZlxKJjm2G
MCPI68LL2OoZQXAN5k4VG6BYGax0JWDKNue4SuTefBXWFw9kr6stsedkkx3XmDPQjLmM
Oshi1luTuRVGaA7mB3FVoh29hxt+jk5HgDYro58EvwWClT6JOVkc6RBz+XlYE7xhukO4
av5sY7jU9/acwH6QAvMmnhJ9svFulilkeFNNVwOLeoEUtwhMtKaP0h5FbCxF+Pl09dRG
+iK7A/aKhob0WtS6Zlk/vuzMUqyzbDiPWfh1lo2jmnfZlEKgRFs28ZXhR0cpH7koRZLj
/h+Y5BTgJl3zDEDXxI9g1yjYsJ+ja1n1MdGpn6uPWzWJWjNS8EymkL5QSergY7kNPpC6
6Y+VfA7sXMZaMeAqA3pm50jxuC64pqK955xT13M4T6TKP+vjnql9c2e7AVsCedPQCdaH
OCILQMs33sS9Ee+kuZCRS1nFzKUOkGmP7FrJ2X0HU5Jz2AegO8ss13uJQhrub/1NKdco
ifiEJul+IcvNJxCCJJvSpoFMbgAZKKWMOysno63fCSXf8mtXctic4KXksIfFVXIy3PhX
yUGDgpeSkxEpC0rO/mcdJYfAVXIIXiVHr5qSw5YXQcnJqHMKSk5mVc5Rctgw4yo5Gfma
UcnJiCYFJWdLn+VKDv++So49kgqTS2pRycnFy5/uSHmikpOR2heUHIevkhPeoJKT4f4K
Sg7hqORkBI2CkoMXpOTwr6vk2ANqMRs9e1ByMqJjQcnJiMBcJWfvX3Elh39fJYfgVXIy
InlBycmInAclJyP15aXkZGZLXiUnI4U0KDkOXyXnviGqRnjjKjl3fxxuT1By9tmXqORg
/m8lJyMyeZWcjGSBq+RkBPCikpPhgQ1KTlboyZUcJ5mo5HDPrpKj3XVGwh4vV8nhSbyU
nIxY1VVyMpJDr5KTEbqKSk6GUzsoORmZwUHJcfgqOT5ylZzzGVNyMpKNg5JjOOGcoyox
65rPuaXm5nOuDEq7+XxBESxAN5czSqGC+bzh52U+56pIk5vPG27RfN5weZvPm7mmaD5n
dMQJ5nOuxzFs5nNGvWMwnzc8jvlM4JrP/kxMgdmRZj6rA88xn9H3JZjPB5QCRvCgV6/B
fM705taIfmtF85k9aIL5nFvOb/M5o3zsZT7zM8dezihau+YzfiCIJfSMCeazzsvMZwJn
hTpX/t1Su+YzZ/TTfM6oO3tLlt5mlCxoJhQkS6/rLVlQ6hYlS6d0NsnSTTkxydJNOTHJ
wlddsnSV4R7JgtzWKFngswuSpSMJ7kqWpuY7V7IgATdKlsbfkmRpNisTDXpkcqPV/pIs
KKB8S5aG/IUgWVqfL8licJAs9w1JFjROipIF8EuywMUfJYsc9kU9l6Jk0QOJjjZGlCzI
0I6SBT7yIFm6JkTJ0m26JlkABsmCOEWULGzGFCQLUp/fkqWV+ZIsrZSXZDE4SJbzhmgL
AYsgWc7+OAyt4koWJE5HydJT/SFZOiIVV7L0nKJkgW/3JVl6bS/JAk9nkCxGMi/J0hlF
OpKFu+uSBagaJQtO4i1ZkMEQJEubM0oW5C+8JAtS66NkQTZGlCwGB8liI0Gy+GdcsqDn
VpQswglnHb3XK1n8mJFNOsQ6CpVcuKx47jDr0HiIaXQHRFpF92Vj4KFtwg+z91PVqhIz
UjLTpi1MoUgJvLoMhEEzQL+k0RW8Bw8E8Mj9DBDOJKbz07GN1kkjf5pnGzYVXBBrid1M
m7uFEeH3ZO+sJIYkhjKV5ntA7HVkONOiXwwAYfaMWpLewDVsriRyVu5n+Gc7A92slGEz
KzriF1PQHDYBAnz1NwxNbcUOIgX8ZXXRE2hohA3oQ2iI7BC0fWLbMgUOezozhLoAxzVG
plgxpCwPKImNCZxI95wuhblDD1EJRYT4wlmGrEgCNXsSuFAKGcI/PTIZqbQvj8weaW+P
zB6Z0SOT6RecEa5vjwwaNwWPzAbn8cgQuB4ZgkEh4KvmkWGrouCR4WSvR8ZB98isvn54
ZOKIPDLwy0WPzKo3ykYguCZWbdE1sWr94ZFZeUSPDFcdPDK+t/cE1uhBHxBRl/T0F1Fv
sysFoi7QAC9Rl6eNF1EX5DZeoi5Isg1EzXZcL6IuyKcJRF2Q3OtETeASdUHmRiTqPVAC
Ue+5rkjUnPuLqAuyKi5Rl6ePQNTsLhaJms3ELlEXuMECUftcA1GvlV9EvWZ9EbXBgaj9
DRGtr/iAtbyIujyqOjGiZhelS9RskRSJ2md4ibqgrP0S9T6gHIi6AL0iURfkcwSi3vA8
RL0nU15EXbBP1wJBSsFEv6KKbDvOgUZAgVImXY84w/hgDaBnSvgACvyWnCfoPZMqEzoS
y+KTJVUUuhYIksLILPRqVnOVYqkFTpBs+5SbE7CD3w7C7zWNgN9gxewLUrqqiBfIlqSD
kDkRIFrQCif4fRRCvZrkoC2oQ2f0r6ofjb6Wq2dpdUFOCBVO9LLERKR/GYjiYgupCM6y
2ahLqkGTtFl2b7Iws5I9CNpmsaUSnW3iTSWzj8zZKyJYP3tloO8VvLCtnL2KII30Quzt
8p9mdnpaH+7QI2CbNbNAbFZhyWVBZnrtd71DaqiDq6jPgw8gWV3RJrqON8zgGNO+CVxu
TzCsn68iM2Ghn1CqlvxiG4B8mbABAn0DmMdaArd/jViHIrbvuuy/IHWaP1HVZ68weUt8
gQCV8nXAb1EETpWvGpOCkwACwMFnqPLWB+BEb+aqBE0gD0wkza5NJTerT+Abmd2qWHp1
vkD56gfMP7gk/Mhku4kKbknqxkLTLhOjk7PJRDTwkW99RQeSd8Z2T/pNQWILyUTmP4lX
KUFM5XOucnkPqs3zT3GGHKSXOENjnSDOap9RnKF89CXO2D/2ijPUIkdxhvKatzhDxVkU
Z2XNK84ABHGG7skvcVZZAnrEGdKmozjD3N/iDH6WIM5qm1GcoUL9dVCV2Z5HnHkfVhdn
NtcrzgqcdEGcFSScB3Hm8BVn5w0TV7ZiB5Hn/BJnyHQO4qzOFcVZU0fAK85shkGcwQEd
xBkSqoM4oxMwirPa8kuc1bauOIPL5yXOkMb+d+IMaW+pRHHGNtntyC+kp+UIuuPSB0pW
GowtoZUgzloxcZbUqar0oI/qVWcfTS3ADsdhb+5xOJSBzqFQod1X5FBxxL6xD8t6kvRs
PYi01o9Ia4K+JaPQr6qpHaxQFV/dlHdr4KJxyS141BcsaYu2kAJr7InOfQbsCGARmRl3
BG/Gq171CcPUpyPMlwT8uBLdQN+C7p0Vz/txhMp9gX+rLwkq9mmiAlHUWaybWtJp+RD8
1pogxviqURqy1Ga74DMhyy4lskbBKBFNH5tqFyi1Gnc+nw+IZdpIYJlwxJTqLBOtRpta
/ZKPO4YQ04xnGupeBEej6RwcxgUJRL/73ynmW12QDmOC7iDewCvfasPvfKs98Mq32vAr
32rDP/KtChIug8O4MLPwOoz31H/kW+2RV74VOmgdhzGB6zD2Z3QYs9WWO4w3EPOt9jRi
vtUBjR77TfAtSCC9DuMy8jvfqiAdLDiMy6ivfKu99T/yrQoaRr8cxvzM8RBvKOZb4Qeu
w3j//ivfSudlDmMCvkI7V/3dQr4VZ3QMREvaK2wfffJqC5KJbl5tQZHyK692j9RXXm2B
X+Xk1RK6ebVl1vXKq2Wbr5BXW5BZE/JqN5zeebUF9b4hr7bMPGJeLZuZvfJqy0BfuQ/P
qy1jWK402pUOsRPLq7VnzKstaJQe8mrZFe2VV7unkt55tQVukJBXi+Udi58AD5B+RnvG
vNkCX8rNqy3o8h3zagucMSGvtqB1eMirLXCuvfJq9+xHzKstcLfdvNoC30/Mq8XK31m0
fziy3nm1+2tyzKst6Oge8mo5i5hXuyf6xLxan7gQcm4Se+XVct0n8aDAKXfzavcutVde
rWOX59WWORirUPthADw7dU7kM+XVltlzzKst8Ky98moLEiFfebU8gZBXuxfSPjyvlgDp
jw5Ne6as2YLmDyGvlot65dVuZJgxr7agQD3k1ToRXjY/Z7l5texNhuaAi9rL78ccVDNB
JWB84gU4/tMFazdK84Gk2xBwEQKU4YUO31bnRIDaQj0gGfO0NnnrgvUxw8oHmq4ZQEpL
YhdD01plTlS49czAkQld4aR4bPeL+iJ2k4RiYRteFrQxWEv9+nVH0B9oiPDRSca2h0Gb
frfLgi9s9+dvJE27W7zSQMTF5hX5W1FVMAKMLbG/4HNOsf3Bjk06pD0qUxatiKXG12uY
Hc8Ig54Zjq9lSTME61OyOpWegY0s5dBXfVRSKhu0qoNkb37KFX0O0WA1mQ0E0BKNIMGx
Cf0iWoX38CrMaBSGZmldynJTg7i+zBqFZVUT/LABVNnEMecrDDnaKJXeeHTk+/B4IgFq
ilwywe8TVNKrbJDCzylBxzS/CneOskY1cYGmKVb2Bo7m/GuEFU5sMUeXj3SBirbOdyq1
BPZA8PuXB9/0qqEF+G+dF2Rx/cUa9j+c4gb4FQiieY137i69xPRoELxe4ooqKMtoo1lW
EXJkfl+lG5cN/ug7RwutCt1qyussp3FFbWF27zvb5MWBh595SM0XlpPtwkXVtHckW7lc
V0evlNdJZyMQjjTl5UeK3h18FTJOn2NX33ukSGCf90gF+pGmQadEONI4IiQBL2jpHmmi
MPGptIjp6ObyI0urIjnqFUuvsE5vLL3CfL2x9Moq9hBLr0UNbT2WvuF6YukEbiyd4I2l
61WLpbNLWYilszFfiKVv+AmxdDbmu7F0dkGLsXS2jgux9Jqnhbub/r6xdHukSHnNKvsO
8HjH0tmkLsTS2ZQuxNIdvrH08AZj6bVY2oXF0gnHWDp7BYZYOl6g6a2/bizdHjBYzsaE
N5bO5nchll5Rc3hj6Xv/sEjG0vn3jaUTvLH0iv4FIZbOZn8hll7zXO9Yes3ur1IsvWbL
vLFYusNfge35G+L32e55MPDsj8O5hVh6RTP0EEvH/N+xdG+AeD7fW4ilV1Toxlh6Rded
EEtXV8kTS3eSibF07tmNpWt3TdKph+SNpfMkXrH0isYXN5ZekWF4Y+l7uf0VS6/IJAyx
9H0iPcbSHb6xdB+5sfTzGYul7+9cMZZuOOGcgy0VfjiVKv1W0alU0ZznOpUqMjpzAHN6
OZUqW0Jcp9KG63EqEbhOJYLXiNWr5lHh9wSnEid2nUoOOlNFotjLqfQasW/sLTqVNpyO
U4nAcSoRuk4lNOALTqWKFKzrVKroBh6dSpXeuutUqk2efzqVCFynEsHrVNKrPuGWcnQq
Vbpp290Cgb4FSDR6OZVeI7QTKvJZglMJ3Q+PU4nAdSoRvE4lvWp8GF0Hr1OpNvVivHy6
rhSdSjqL61Sq6EL/cir5yHUq1apGkdepVGtN0al0MU1OJUfdi+CNbd8cv/cKB+hhqSC5
HPDbQDYBzBecNPRpDCT1Hhwf7uOpHf4krUAtY+nBMv8D7f+Ku+2OI64id2fdLey1Hq+R
BsyDCEVosAujJTl0lp06jA+oNPu+wQYPG1xSLB9Kzdrh95FiqSDB+QkwEK4B3gEQhPG7
/gwv08/earOryKEwQR+tN5nEltnp1MGvS8LnBVNkmqJT5LpAKvykMibRAcQbgdIRsf8l
0nMNSz0Mm1gLeCPRdSihGt/DCIQBxVRVQTDgkZKaiXT74LKldDOkso/ZLiHkryTiQdIk
1R27qsoVSUX6+0skNYs/qkz0qHC0MXO3JkOB4Z423d6xZ4bSse+rmfVk5cxFXeLgfxYb
YpDUYR6BmsqeN5IaLHZ5CWg9o/t71ye/ZE97w9ZhFQVokdqLFUEduLvzQlH6ipscGSuB
ldstu8yA9Wk4RIxWTCnr5qu9YN00CMfTdBIhht7+i/SpwXObufVSwnQM0tfYp8QeVXok
N2CdRkC0PVTYsxFiR0kJBXPP1oRWaiPaWEFXAKmVAHbTAwxcujUS4VwcwaCXBw1EkwBi
Bk1oPStc+lQyWAlbRMwEmKaQETUImOADb85Uz8lHzpz5aEf4aHQd3WPzjOtSjAnyUm1W
h2Sx8YjxeUo9zrIdrPTxWfSUHEcJM0kVGhXl9pa/SaUeuXTTVVp0QgYLa+OeEF3TCKMt
AXh1FeEQy2X4V5cfVEB7LAguUHKefsoc5t+YMmvg5dcD4b933LTCyxvjpuyreOOmFble
N25a4YaLcdOKXLEbN63I3AtxU/ZQfcVN90iOcdMNPyduSuDGTSt8zjFuWmfrIW5ap1w4
Hjfl3F9x0zq9VldCALco3rgpu6fGuGmFl/LGTdnxNcRNfa43blpHbTFuWkcZMW7q8I2b
njdMbbYVHxANAYIns8KpfeOmlbmKJ25aWZ8b4qY+wxs33SM1xE0rfLkpgKu+4qb7gGuM
m1Y4oD1uWpnZGVXcOW615f/njkQDasa/dAeopn7doQPUGbHyMORLxw5QTDB/dYAiAw8d
oLpaWngHKAdPBygfsA5QFEqhA1RXOmHoAMW839AB6kzROkD9WAT3G9Gbf6wDlO137AD1
v//p3/3Lt37qdm2dNQpiPv9t/dTZ8l2tn/T3af0k0Fo/4QKo2PqJqd2x9ROyq2PrJyg6
p/UTe+7c1k+tpdv6qdl909b6Ccr2u/UT+93c1k/tGbf1k4DT+ong7bcEi+Ld+gnfFVs/
oTbktH5qNcXWT30+sfXTsEb+fJVx09D6iXHVV+snIsj9YYK319Ngm/UA5lfrp6FOq+rm
hAjsq/UTtii0fmJbHm/91Pg71vpJwKnwEWitn5D6f1o/sfDhtn5iZz9v/YSM9NP6ScBp
/WSgWj+BsGLrJ1Dyq/UT9+DV+gmJJqh0BwWqIPmOJKiUOLKHin7ChWM56dZmvjF4RViA
vRDsjHRen0Q0QP8c5t5jWx7dlore+LIx0GkQnVJQU5H5htp8YJNqCXAupgmdkYcl/hvx
yELqYrUHMlPYFPvk0qPPPg4RmUNNdTFq7MglNDWuFetH3QFJq7N8hP0pEnKQHtYHqGMj
fkHfbCkPCd/IWh925OfiKosoqP/txfNKGXygszEHt4dXhHdaCnsDUXEwaHsQwLvLbuoa
5Fg8k4TaHOgMBy6PeQTOyGOzXdZfcSotA21w2EG5N2cyPtKYbQhayEX9x/u0zLQzMqqu
r8rIc9BuNl0GnbLagg0xnwODdJZm5iNsgQkCFFOBhse1dLvzbFkhORMJ2G5L9eyYBdeG
AH8NcOlW+X5G2Fw0I5MC0+7QwJDx4gAPbaKBhh4lLnQjuCJhyNrh+UCpIUIMXuu4d3We
GhIQWl1eBlQFGJ6N7M9SMySdjFIfOE95/+5IpaK7P07zK6G5pFUQJXUucw6LbmzYlSHf
NFg58WVmu0OeeuSGh0UXz8heVh5KcyAn4J2ChxNAdI2H1TzOeIdcJGCGYwkkhqG5yHhU
8eOMl128+mG8BjrjHd0uWxPjjWBSI5zKNn+H8Q5oqc54h0x4TVGdaPR3q2qJauBSWh86
w0324RlWdsbOqQkB5qJN9BETSjh9NOcXuhPsukvl+77cMysq40hhMJW/rw4ssGwpFjEf
GETZ/57jqIrcEWRjDPeGjqyipEdlq6TvJRBfXtRbDCCLGRdftfolCVA2uZApZCI2Q8Gb
LIbkUeRHTbRdKDM0ZgL+GQf09aMjSH4J8TjCmtBthrM+rKk90gbV7QBTQm8YtGu3gxPt
LxDkB9cDVH0g0M5aZRaANyJk/qj2RSczhu74MTBnk9q8K+UnKG1Tu4AjrmoAAB7J7imk
6A7lTxARvDpExQLsGykT7aK3/Yqj9/1RgeqV7ugdQeb7JlwnANaCX2JHKYoWm4RJHaQZ
CPoOGPEs3d9neJNRqlHsctKM1mNM7O/JzBx0PpvKjILVCiql+yfTanUQ8li0qgGY2WSY
qglLUxXc6M/Gpo+4M0zSoj/KMVLnalbFyt5jH4LNVq2kVFYrQfgbZLXSG6cQfJZkfazp
IrW/aQGW2k27QXIlbe+iCh9oGPPj9A1x8LFm0D4AdxC5L6N/jEYQLad1MuzeMwEtlRmF
q6ot7tYoBjFmKluNsWeHKY6rIoL2Bo4pnxUf8PQBsQH4N2G1jm1gW6sbWK0Q/PQj9WO1
9vycGYITLMs77gzfZKRLWlPdFMDVP111Kep30sUcVpYzL6slJ78doYDIijJvrHZW1JJl
Io9lFWlnZCarSGvJmgZOXmZ0eBC71swAL08F9BE0YydLZGP4DVZVzQKnilz0aCDJEn8X
PlPu1acetYL+skYrQHo2JjuO1u+gUWcurZlr39+PI6Rv9rRgMeLD+53QgAD0QL2VANmk
978w3sS7bdlx4zH21LjdaKJOfLXOcmxBvy4ntr29J4D+ICfh0Im6rvwmajQfCERdkWNx
iRq3mb2Iuqo60YkanVAiUeNWvDdR806vQNQI0x+iBhCIGiGXF1Ejgz0QdZ3tRdRVXaQD
UUO9DERdrSeMg1DqIlGj0Xsg6qpexoeoba6BqGE4R6IuanF1iNrgQNT+hhGtrdjBqqD3
JWrEkAJRQ9UNRI0CjBdR2wwDUZc1IlEjPhqIGvb3i6jROSISNW/hdaJGPv+LqGFRXaJe
SRXj6bGKtLakvgEleQpq3tV07+cB82MVaWdgMkXNVOTc5NBRFWeTNwcEPIZAErCYBV81
rZ9acm2XgC2E+XUmvyy4JXA+VoI2tEEXNELriMjwpybNOZzD3l0yp2buEYUZmiJw/VHf
Lb36WFuKLg82UOhZ/rVcvSgBuEiXyZxqNdD0nQYyxG/+rKl9YZk6LpJjf4GpGnz1IZi+
WdiIrvrbYR3n+KrzJsTRatir1awibQTQ9wqXh7Vy9iqCheY6qDsTbUU5nT8/efk8Adus
qYYA5GurmqePBYpnfeaKd1DX4YT1L97aRm8GD58WaZb9DSBw+yEO6uvnq1CeVhODq4Hb
d93p4BtgoG/AaNnqz/z9OFJkZeCypMj+h7pn0fygPQse53wBAN1x84DfogicKl81JgWz
GKRpYPdrXc8AbmEZwmDQBFqOiKRV2o1GxwqV0dmCN4p6evoXoPgrgM8PLgneQLa7LVY2
0JD9TdSkX6V5JlIb3DUf+dZXIFbYWnNDaDB+0iw3Bi4hzjYPGTnyMDpXubxnKBr7Fme4
2uglzqbKwl1cTd0udkBUQUZxNlOP4ow9V4M4G6co3cUZgxdBnCFt/YgzAEGcIVH4Jc7m
TFGcwQSJ4gxzf4sz9oC4J4NLzII4m7rP6R7UlG/OxdmQw++IM5trEGdDVvwRZ4gbRXFm
cBBn/oaJK1uxgxbIuOKMF4dfcTZHj+JszvUWZzbDIM5wvV8QZ8gDD+Jsym92xdks6yXO
0DXjiDPEdV7ibK7+9+JsPcmSh1ycLevEa+JqPUYGDi5LHvIBU0t9CSsHcbayibNHFe05
R32Urzr7wPfwkIzjYGJKHhoBdA6FfghKFTrvhxH7xiZj3aXnqkGkrXpEWhP0LRmF812b
K5NjTFZw4lq/lC84k7kKfUAXfFJIoSLtwfYhl6NkAXTEDyv7b8ERr1dtwht4KDLOkma1
5KERQNuC8ihud7fgNUIlvzyIEC4JKuR+P9Q1Fg+YAP3fxCqC31oTUsr5qiitPMrtdcJb
kmWXEtHItBolwr3Ns0iSWo07P88HxDJtJLDMVd2eaNYmdSlEQD7uGEJMM55pqHsQvDzt
5tU2LDfxIjv7+zFHEH1+F6zWusI8hahAS4+ysy9clFEBNymr9x/lhVrYh50UUJFGbyfh
bhVpTbHYggoB6opDtTy4+YLde+QWLU9vHuAYzPQpyHCm2JHEKA/bcMmtTsDYACrS7Bm9
V+UxnbqhMAzVDdVwFeCgioTrA1o6oNEjQWNle8K8LtRBJOfLDPUBOBBMo8JXIe+O6o50
9pJOZyfw0mJF2Nk0lKzuBaWScfMGhoKI+BNBcVaDEm8RyuhujwoHnheK9qy1x1mhn+u0
4z9eH87oGohpqm3BHlRFGpEk6wbI7wMmq0jzc2Nhw7yCvbBE7oOnlgWxz5eDzSrSzkCV
Ig+RhUYJ5ZH6N5hBVpgvboTC3CEWzFPrGOx3X5hT1AIMv1ty0sIIqiJMwQQ6sIMOMpJQ
kZaEY7ixgMX1fIb0f5XVM5KCmMtUIb6FNxRbKSgAVEUadDDuhnzwVB8Te0LUY/ET4AGy
Y7aeDXbTKfClwLxx8BlWkWYDcMa0Ke31YReLLnH80Gla4FxT7QKuzljqmSH7QEp4gbtt
EUXU6wVXBwkbfSBZ/RlCJHn+8UizijQL1ewRFRQi0IK6GtSjUMI4jEPTOnxAbZbOF2ji
hpBzmKZqYRquex2ag1OuXRLMiuFcEjTs4q509r6AbjOTWk7Y/ihkY8/QUAM4PGUvydtR
WMWnzYHHtKtfiSrSkO8D1oAToKqEUCFPJJ24HgHSH5VFPWuKYhVkrTz5wljUNK3PRiwW
BcGzSFG8zjyQaDoVadw3NGU+FWm9M/WiwDnSTDVOat/Qle2P5EG8gJai6YIlG6X5AJg8
FISh9gxs8Gl5F8X6p8LIdZCMeappQ10XzN7qwwfKkLmvsnY1VmjHnCiMJXf/djZmqMMq
0tj9Dc0FqiShRdn2Wpp1hzO4e6nDGUGVxhDhQ5rY9uzfUPWiwZwmU9LOGyby8RMUPwaq
JewR+aWmLHfIoMelMKfCTrH9wY51OqSZyAHCYGI+9O6h5iY6CGsc0a4YQhMJBS4JIpNd
FWk+UKhpO33ZLbeyQbGVbVhFGk4ZLAvX2ckvyWYCdai/nuIIRc0wHdHgPTwKMzAfZfHV
FHaGzUozi0vmekGAOgcQ5RTjmvMs3Z9LlANFQrHTzJzI4mHV2dXK4DnKckr2KvQ6NFlh
c4J5NMUCFUkVKSOAriniSpknmvOvkUcF8IXxiaML9Ey3gE0lv9hDV2GVpRzpVUMLpNQI
LZJ6OazPoCgWxFHp3R7Wk6JZCsyyPhHVgmnU7AheL3FBdoBFF6u6X2R1bUQ2OzsfqGE2
ot3sAFKsIs2cxgWZDdm972X9GFDblC5qPrC1pTzwsoo0H2mq3FbUWX0SoBiSQAmEI1VP
1aONN4X9/XOFFWl+ROjnMuc5UgP9SJGM9LyU/zhiSKLU3HOk2M07lRoxHem3rjm7BsfK
diK762voS5gsApdV9V3KBYd3dz0D2XQ2tSEazM2YLOUkYCg1p0BzKeZsr4JDstrcvdwy
jjds3V1NBcMF9PVYJ2VUdXd1MHsRiqPoUndXiCuIss5p0Q7k3+SiavqlR1kF6tA2ywzw
PO5yH1nJ2LJ9XDFMdwU6/HVcp+ENldpz78mmeZkrYS11EdML9F9aHjI58QJNb/1l7Lyc
B4NtrcANad8YmKy7q8NF+T5GzoN9XBEQ1N9fvw7XHqovQY/Twsmouytyq7neuazJ6aOW
J+PYAHJgFaiS1BHH0CztrhdYx2Ql3bu7HrZnbxi/Z75+u6Dvj8EkJumVdaqPxSjKYpls
m+HdXc8bVd1d/fNN3V0d7N7d1QeGuruiZwmxWNF713GNZOThGdSquGfMByF12O6apBvV
pM+ij4UnoYo0OOxgF46s/IvxqA9IUhfTA3p3Vx94LEC1ePseeoxI7A/eUusw9WAWovsI
TlWZ0fczipUUWGBw+KJGAUx52IWt4hzI9v3pVGL/gpdTaY/k4FRin4IcwflyKpWZRnQq
oWfFcSoRuE4lgsGI5avuUZkyWQ6TnM8TnEoOOlNFX9eXU+k1Yt+o3h7uVFKjDXMqeRMO
YybTDEU5lQruNbpOJfSICE6lMufzciqVufrLqbQYPTCn0rI4rzmV1k0yglNpeZyXE14r
OpXYz+E6lRz0LVhqZxe2II7IqbS2ERudSkv6lJxKS3Fedyoti/OaVshXjQ+v1INTqUyV
KVw+jYuOglNJZ3GdSuxc8XIq+ch1KpV5LrIxp1KBFzk4lS6myankqHsRHDeCHacSqobR
SFQVaQ1lxgZ+G4iOBytfcFR1eIdZpj4P48N9POw0oVDF4CXKlR4s8z+odgjF9t03qaJD
KmOLDj7Ha6QB8yCyrTX22JIcEDGa9cA4IPWAvW+oF8yaTQnnMJjRp+Lp5l6wIMH5iS53
fllLtabO79aykj7a4pDty67dga0Oi2cNtVVn06MDfl0SPi+YIrMUnSLXJVKtZhVpQ5dt
oYkFHRFg5zjVRddUY1UdAbw7qtCVzyYmMlUEBKA+yVRVQVVJs2hl03lwNqXOnrX7mD32
gV9BRdqzhiZZeZXhxouimNjQ318iKVQU6RHuImdPDEWCGKHLwollhilbPFa0WVVcRZrZ
PoImt8tixi/bdtC0nUunvOyK9AwdpdbwBigFPwLpysgE4zp78d1Ss7qiMtwORnoGqzz3
JJIiQQfO5rzACGeVLeMHZTZIlEvzALpm1iAEKbpQzFuyjCHH03QSIYbSAUWKYpC1DDVT
YRIutG39/SU7WX1YmnQp1IWxPZhoAXR4c0VYuYU7qBjFH1llRo9dCgB9cSaRWglgM++n
gbMohAT5zH4uDGMu/bJ5Sht7RNizYeTfDlA8D1vgU4WMuOwCR0atBzJYfxPbWaNnj0qz
Xi+a52td0kAgLzFSVJHWlvEIVsWCAYZlO5iHVaT5QFHCDPgjKtKQ4tgtwRe1R8ilm67S
oiKNF1OPe0JsAV+qdkJua97+Wf0Z2nHwW4YDpVsQXGBS8R/8lPnOn0WWZ3mHX9eULr82
tbPCyxvjphV+1xs3RbeXEDetcMPFuGlFrtiNm1Zk7oW4qTqlxLhp5SVYN25a0eDB46YE
btxUvWBC3LSiVvXGTSvqUEPclHN/xU0r7ve+cdOKLlQ3blrTXK+4aYWX8sZNK5pOhbip
z/XGTSvaBIS4aUVfvBA3dfjGTc8bUpt9xQec+RU3rXBq37hpZa7iiZtWNkkOcVOf4Y2b
VtTy3bhphS83BXA+r7jp3qEnxk3ZKMjjpuz2E+OmFe3F/v9WpJUEKfkvXJFWHoUNbkXa
HVFFGruRh4o0dtt+VaQVyKtQkVbYgPdUpB3QK9LOgCrS+PFQkcbe4q+KtIJe8qEi7U5R
FWk/F4H9hn/8H6tI8/0OFWn/5q8fX//8l7/99vW3v3789p/+/PEffvvbbx//55+//vn3
P//1469/++37H69Po+MfKc6oxABi7gHVDVX1NGGkYDQVe7TJ3uIslkLbWKkyjDmjxG1W
0yfPyKDv9Xt/qwg9sRFL5UhnC8WETi2PxUFQ8oa6eMYYbGKo1KOXXlts4LeByNyk2lmQ
6LsP649G0lIj9MFUzYQETThU0XsCpU0G4xeabt8+bzRdD8+u2GzJTkaTihoiE7dQlVcs
x1mgKuUAqayBxXRTiwa1o9iO7UIKGFhDrRGqwRjbYVqLw/j+kVTH52+gEgUubQa6bIHV
uttoSwT5BulcceSI9arGjUmAvIIAsyuD9s+3vYD2yNk+Yd8wT855wQUSuDIUth2jj5sY
WF1i/TAdtH6YAFXstawfJq9KQE3LgpDdEO+RB8QcAwOn9cO8AwoO4MMsmJnyU+HrVZ1m
/TB5d0FmhUzVRQtFt8ijhia3ADfrh3lH2O6IxF9Y4sWos+6Zlzd0b5DumeczxdYT6k0Y
oEy6Z74164epsHBXaVwVyhbdM49gONt/V90z39hJv+me+Ubf6cYFXVurZ4NFtXQbjgt2
64d5BtojGh26Z76po1Zhwj5KmIr1wzyY3oSaeya6Zx7lVYsBaF4rjxRQ6p9nIFn3S8TK
SAt/NGL9MAt7jWFEd3CpyX9VIR/37MDqh3kHipIPzhdo4kJIFIoadUzdM491MyxZtAvL
XhbYrR/mGRB2cVdwz/zWNnXbAkuX0qOz0z3zepZ4zzxcm8q40D3zEMlNWDp1z3yr1g8T
CQmsscUJ8P6JoXvmW7HUBlQVAqC40T3zelZ1izxc4E8OcLN+mHfE4ld2fQdrvpgpc0j0
9MPUvsGU9ugjb5947FLnJsZvzA73nacq9mjXm6NNuIFs/1qFoBrAvdLLUiJYu9WvjFVz
3sKemt2fVd70jTRBOPocHEvRxzOwiHrlUWAswV0HzMTdK6DBAZZzvl3Xsj+KPlJn4B3Y
D1M9uCUsHnqYqXXhZHd+3xHdkEvCZyGQtkdZLne7OM2hO5r9jaILzB+aTg4OeE90bDbQ
5b4FY0P57qjrnGL7gx1LNGoL+k+CMAY8y2g2CJE8kuRiU8GtngnH0Xa55AtCaq5AAwPO
9ktfY1nMW3e2Jd5y1PyUa9ct9PCco1kIlpnpIC/oFcJtimoQ0h9d7fR1r6w+KmefptKX
4DTgbeC8bQTuxyXgS9JyVn+mieNz6y5s5eay2waU+kCGpouomfXEJkZJzUb5m0+zZz4/
NYF/T5dL4lVEGCHX+f0OVHWwBqqgMn3BwYMGzfzZLr5sNKVng9eAL0N8B1EdJN4nOLEY
nIkfvJP8MY7cmOLK8rIsdobmGcDAuXQBBa4GrdwiXQKEIvI5hd/KprJnWgD8q0CZ9wLP
MWZ40LKfYlPQHPfoJO1CS1a1aDl5qneEPyZH0JIuz0C2fL6mtIxHKnjS3dDGp5s6uTwm
V7qupeKrphbye2rSPTKsjEuWdGlzT5Z0aeCwFMv7fhixb+wulJT1+7SroRHgNrIT+UM1
d6+BFars/44orzwK+ZlM+zjgsqRLH0iPqSL9UcM8ahpTdc5JmoZpmgRNWWabXioeNmFk
ltH+8SUtS7q0NS9LuhTILKHXFsQR3fHFrr/r6Pxo7IItqGrJV8X3ZJIS/P7lfEuvinjY
A2i2Cz6WdOkDz1yi/cKObToLIGLTtST41z+gC3Rs5FtfAQ/i40Vc/BbehFaWmH1NB0OI
aZUd2xx1L36nHvBbbWWma7RoXU5LZint/4C6NxYgk0mrdYJGrO7ClnTJpsRD3bNmV5Ys
K8AeJl0WOIB40cJjSZcFvsqHNX3VhIrujYUfgMmWxe6PHZZ0STnCrj9DuWuQnmxZMx7d
ozUNoMjS5a72zC6THky6hJxl3yElXRo4ZbxV3RvroNFjomY67fJzJl06mJMlXZ6BIkmM
iavXbBXuNl3IipZnRQKqqbgIDYeztMhuV5rjGmAxxqxenU8ExTr6ue6cpNJU25kJFN0b
m9NdYTarpdrxH7OHM/KkyzNN5Ap1aUs2qbLYc5gpdygb20oYU0YdtKjlGVDLBIpVVZ3p
Zi86kQpdcdQmEdktrGLkbW0526vQfhbr12hPk/xYS9l1DbWZVxn9SuslwSLf5wFzN2Zp
A2ik0kkrChZk/paYXbZZDXUu0aOpW2Gzqn4uPM0Dd0dAFFS5/ELzJH2nh+pIE1F2I/l5
w24kV9iGUps3kqP3gD6gikzUg5K8mt1I/jyUL/rLVLVyHqhRBxrkPu2CjFSYds1Wf5MX
zVW7kZw6YdeN5FU7N+1G8iox8yg7C91+O+/o04VdeWXdhWa9dXGRlyG6VcHBo6GcYjUE
yboGlyJAF210ZRaQ8Nj62d8w2pqPNASBZ38cTsydhInI+8YzW5cUdH1mPWsdyiy4b1RF
v/zzrcqINBDNKGb8/qHYFrJ3icW4uO3D7VcnGbHdajeS1yGLw24kr+PDtViiKjXLZjeS
l6nMAua58kZyXZxH+y2r9SKTNw1MTZkFZ+CpSsWV3pXRfIjX8RUVihtMhUr3xtoI/Tm6
N/Z85rEbydHSA9iz7EbyOoJgKeu6Xd3QyrCsX4YW6xyvocWa0WtoZTRTiYZWRhpoMLRy
Lc8xtAhcs8Ge0ZBi5eg1tHhJeTS0WLoaDK0Nz2hosRL5ZWhlZHS9DK2M5LNgaHkfoQCv
t6HFHj3B0PLtcUPL4Wto3TfEstjk5hhavIs9GlqsiQ2GFiukg6H1dzuWSjS0UGJ8DC0C
19CyZ8J+9IW9hlZma51gaPES+WtoZbjjgqHFfMCXocX2GtfQOvl+MrTQfCogmlVxBBWm
s4+T/m5zRRXmgFJhAB6VBf61qMLAl/BSYehwCyoMPFhRhUHM7a3CoL9RVGFaqy8VptX1
Q4VBD4yowqAJ8FFh1C/4qDD2TCpMq/WqMHCcBBWm9RxVGAdNhWn9Hh3cdEGFad6+wAcQ
JowqDBKWowqD0oS3CoPks7cK03UFnWkp3UwnB58eVBh4TKMKg/M6KkwTjmmFcx0VpkfP
LWd0VBhzC2X0vbye2w1Gz+0Gf3huMzLRoueWYefjuSV0PbcM5kbPLTMfgudWmQTXc6uO
QtFzqxzM67lVE6wW4PnDc6uryY/nlnXL7rm1mmb33OqZPLdsfhU8t6wFeXlumenw8twy
sSN4brG847klcD239oyeWXVROp5bZfoHz62aLl3PLVMTgueW1dYvz62SDq7nliUS13Or
DPXguVXqY/TT/uHID8+tAt7Xc7vhl+eWs4ieW2VQXs+tT9wQcvzw3HLdx3OrVMNLgki7
iZ5bxy733OZRr+eWwPXc2jN6brfK+vLcqhI8em6VZhg9t0oXuZ5b1KMczy2B67m1Z/LL
sodb8NwqtyV6bpUhej23rAEInlsnwsvn4Su9nlvjN2vUH7YIiheDLQJXWLBFVn/etggc
UdEWWS1dWwRAsEUWI4jHFuGrbovgPu9oiyzaadcWWWVEW2TlEm0R+LdetgjusI+2yGzp
2CLTZmXGhB6ZpTHbeNkiaAf7tkXmyC9bZI71skUMDrbIfUO2yFQ/zmOLAH7ZIlPXUBxb
ZDLiDAyb5gYzW0QPZGxMRLeuLbJwi1mwReARDLbIku+ItsjKLdoiywKfZovM0V62CBM3
gy0yda1EsEXQ9yraIrx3LtgiBgdb5LwhCkWT4mCLnP1xGGkL1xZZT3vZIvDmvm0R+GGD
LbJKjrYIKm9ftshq/WWLLPbwOBzZSOZli2DPgi3C3XVFD6gabRGcxNsWWc+MtghcqsEW
QWboyxaZM79skal+lMcWMTjYIjYSbJHzGbNF5uwvW0Q44axjjeiLpyN9bymzQKFbHfDb
wScpC1Tgs3Rt46NSS4jR8eEaG2uD5RwolhkxhgXfTZqTtroTe0HG3KoBTEcH1EBOoq+m
ZM61jFNO3kvgMPZHLv3zhpI8CnzWzFrIkrfICpOygB7OyE7zn0jFqpURy2fZ76PC81Tl
JqRknVM6LjeuqY3GWlZJiEZdB/y6WuV5QSkN/ALd/2z16qkrdYJlk+TcywohlbSaF9yn
uDkBwmYxhYhFkzBG9KzBwHsUHBJQdSO6QRvfcH4oQaRrdWpKbP/FKmTL5OKvIDneLrFn
SSspDgUruAlw6O8vOY5n8Uc9q0r3mRrsSSgwq+vNbZnhWT6VHdEsYpK7lKjG3m0F3Qxp
+Sre4zCPgPcS3DeKaouR6yNbWPdNA/8U6EjKMeN28Br5wnsIiMCkzAOfFAt1cFXiEX+D
CFjFKgUoGGRQt2LRrHu+4RCnapdYKCcSIYYq5xEURQ15Ta0a+w+RpGOQPCvSsvioi+Sg
rFTRAoDnELUsbbTvJOOaqkOCMtxZ0so2rSS1EkCPDAjElyeybbYmKQwsILmMvywHKS4D
gj2mZ1z6YttcA7RFxEweSRMy5iw646XrzxRVckfw/ewBwLVaPfzz2DzjuhR4G8yyRm/L
oYiT8YjK4aoGD7ZsB+tUFugZaMw0pNxN5sTj+808nswsNJFPyT2UpG8n9HDzVpNlaolI
qQiHuJO52rcMB6SIUKxWWT7c6qcID2z+I2siBA/DLmhV71EJE8sFDr9hviOuKjfzGfb0
acX7bVwwjU+3JTmgKzP0YQpTaajOEkHXwwyfZOX1Jsd07wcFKJPzVhIg3kFw2wCW/fSo
Qt2uZOT1lCzgNmHRdJ87bxKcbiJiFbzi5GiEbCUAtcXB9HyuoCCqxtvCR01cdS7pRyp+
H673del7vAKCZ6n73MFVHoujU+YJNsud+oW/QbXCV+wgbitcwS5hc4RiYh8b0FT/DTMS
GzCSZ4EaymiGRGldhp7UPZvuDf5OltgTiNsi+nT3B3fIOms05WbYtWj6dt6rOwNGweV8
3ZHTbqC3lt+KM1fdku3x1vQDpOOmKV/M2w0U9DcUOjg81In5jLAkNUl9wslXakpVGRZV
qearM5+P4LfANKyAWSE3ECxe2BohlFgYOZMr0BVspuCoGp059bhDtKwz8q0R1sBWuU8u
zHvULsxi0q/wga7Y55qS5LVT4GtZAOSE0c/14X4TFXBX8SfiLMu7L04jnS+vgNO8IK5J
XcJJFrLyxPw+AtetZM90jkVdj8+xgglHzITXk8+xe5iUXGx+prYE4FuuvgQqx0Mn2OWo
l4+BoCvH3Bsp7yp2rZ3dx7+OPcpKfMpgerR89w9Y5tGbNJCSpW6oWq4QXR5kM/JvUjQK
PvXEGHxVW6cDQu9sQQDUZqSFawp8DZZUbOt3QkGf0vy2sgvvsYlWdoGj5VrZpasl7wFr
e1nZBb3Gg5W94X6sbALXyiZ4rWy9alZ2QSVCsLJRux6t7IJ65Gtll/7MYGWznD1a2QX5
ZMHKLo2/RSubf18r2x7Jhkb1dbSyC9y4Lyu7sPX9tbJZ3h2sbIevlR3eoJVd0HkxWNmE
o5Vd0II9WNl4QVY2/7pWtj2gGV3aKMHKLuhqEazsgpKBa2UXJv7Jyi6WE2hWNsFrZRc0
SgpWNhsrBCu7IF3xZWUXZDMGK1vNAK6V7fC1su8bomq0gb9W9t0fh1Ehe6zsAk92sLIx
/7eVXVCRcq3sgtYp18pWg4VgZRdc/hSsbPZkuFa2k0y0srln18rW7jojAaoGK5sn8bKy
2XziWtkFwYhrZRd2KApWdkGub7CyC3J9g5Xt8LWyfeRa2fczsrILogPByjaccM7B6pkY
iCnj+tjLIMJ4IOaCDFQQ9MBLYQfiEuH5CsSwpjkEYgobC91ADOuoX4GY4vXb5tBnbXsI
xBS6mmMgpqBtaAjEFHNvMhBTjuuzquZazxiIAXACMcVKmCxMgaYDIRBzQJnMBA96ofXx
RXY2Ag2BGFaWh0BMYXHZDcSUobrfIDFR2fgKxPAzJ/JShi6lPGAeQSyh4D4EYnheHogh
4CvUudrfbDnq6DF0CehbssyVfkiWqUo1lxxwFgXJMr3xzR14XpJl9nklyzSF0SSLGssf
ycJXXbLM3l+SZfb0kiyz1ShZZn2iZEEryZdkwSVoUbIM/pYky7BZmWjQI5MbqHKNkgWp
s2/Jgh6TUbIMde45ksXgIFnuG5IsY7WXZAH8kizIMo6SZSgS3vVXkCx6INGBngBBsqAw
O0qWyU4/R7JMGvWSLNNz6iRZpnLqXLKMlV+SBT1No2QZo/yQLKP3l2RBSWaULAYHyXLe
MNraWxsky9kfgycuJLiSBRchRMkyVegYJMusJUoW+JeDZJk9vyULfJtRsqC3QJAsRjIv
yTJrjpJl1nwlC1A1ShacxFuyII85SBa0mQ2SBWnQL8mCPOkoWYY1iXDJYnCQLDYSJMv5
jEmWae5FlyyzhtBPmbGTkxlLKGlGDaEZSyoAzzKWdNMn6qwX/d9TJbmQHjB8Rv70snTZ
SmY94cHqbiuV9XPkYbl7VSzowIq0Xdh8L3cEZT1wqk/WlG24XvNpGVPvmtJSgdQQyi81
y+Otf487JQys1vb4DCD/GWyz0jFX0X9x7y5N6KpmjHQFjGLPxKhY9379DJV+t34ZWSUj
h5zL7ZQX062mmvHjpeoq9raqKuXIEDSPFcuCGQM3EGWDYlM2MJSSxX+t7JqZ5Kzudmcq
1Xt7NrTwod5TDrZsbkqDS7Nef433YXNKIAXcinzmDyyryC754XSq2e+hMKdTxe3l1+lU
4We4TidWwkanU4Wb5jqdKiK+welU4fJ4OZ0q5hmcThVi0Z1OBK7TqfLOk+B0qvAyXadT
RfZmcDpx7i+nE4uTr9OporFjQIbsvbV9ADd0XqdTpSv8Op18rtfpxELq4HSqySqBzOnk
8HU63TeE1rbiA671Mu1VCX6cThUXqVyn096g8XI6+Qyv06mCq16nU01eT2TgGi+nU4VX
MTidKrofutOpohNjdDrVPOrf5cBV3DrxyoGruEnw5sDVMmrIgdO99yEHriJ5MeTA1UKy
Ug4cga+T0WXPmOO2P1dDDtz+3ueVA1dxF2DIgdtwizlwG17vHLiKBNxXDlxFHWXIgdvw
ijlwvtSvX3dk1ZgD59vjOXAOf50cuPuGkLLoKpEDtvzKgaso9gw5cHsbnpgD93PHeGPL
zYGrWdXVzIEjQGSlaLVnwsT9NSEHruLKw5gDt+c1Qg5cLeof5Dlwe2PSOweuwqt1c+Aq
nGM3B67qmkRHtJr6z2KjilTKUGxU2XXyFhvVymicio0IfP3y4JM908TxuVtsVOnPDMVG
FV2VQ7ER7oD/8MgkAW5u0YX3/XgDazP17DXdUGxU4f6MxUaVNZW32Gh/w/rwYiMCQUTo
GauJajPEdxDdGyUiCOM+vlBsVKurfyo2qnXj/avYqOLek1BshC368GIjAlwyqwjsma1o
PKHYyBd4j5G9kt7FRhUFliZVVWxUkZcoU4UihpWc9YLLC7ltAJ6EYe21Cy/EtogPxGH3
pM6sG+wfKxpX7wq+ysujCDzKH1LlTG2uP9ncZ/aS88k74YtuKMH7b5AuPN6JTiku2dSL
Ga+tCOAWsnKe4PexZ/Sqs6BubiTrt21fy9Uz86WiUxI5EALZmAi/84B92esGTyvI7HY7
/LLkmpUFBBQDaJtVlr1qZUkVrb3q3Su2wuhnrwz0vRrQ4svZqwjyLubKPhuUcnbrNA0g
+aOrJdyZ/UeQJUmNTVrgJ6j9rBd3TTPz0MCWLUrnA8MikIje4NvYn1zdzwnY+tEyadgS
bP181RonVFhlIjltwGjNhI1WLNA3AAZI9Q3g+3GkwjKoMChTKFWr81FKt/VQwNXdH0eN
mI9VkawDfosicKp81fgOLBEmBxi4mUCKCjB6+DSLrYImRvGw0yKuIo1uFfe1Z11vryir
XSGP1M0AjvVWquAvopZWaJ9VZBNSnpnYpedR9KBCMB+5hWAVF7M84+anVjgzqU3Le0Xi
ZdRZdWDOVS7rwUXeefzQfpFJ9NJ+V40h182/Ysi1rucdcq1zxpBrneMVcq2z/wi58u75
qP3OdkOuBIL2i85uL+0XqXxB+0VGXtR+Mfe39otEqqD9rvQyhZCB9jooVt1e7RcXoETt
d7YfIdcKT0DUfmd5hVwdDtrveUOi1VZ8wPUOue79jyHXimLcoP3SUI7ar80waL/wcgXt
F7mBQfulpyFqvyu9Qq4VVzoc7Rd5Yi/tF3b3VUqU1tnYie14hRt4+s28buDqr8zrZtrK
wewGznwyrwndzOsGthUzrxuIKGReN8w8ZF433iUZM68bXLwh87rhzZB53W4y1Rl5csi8
rovZO8q8JkCEVWMpPlPmdYV3O2ReN+ZkxczrxmymmHndmCt2M6+xvA/PvCZA2qOfyJ4x
s7pBpR8BLM8r87rBeRIyrxvv3LyZ143ZXzHzusKBETKvK5K3bub1Xuh6ZV5j5e886z8c
me/M6wrfSci83nCOmdecRcy8rsg6C5nXPnEi5F7l88685rqPU6WhWPZmXjdgRMy8duzy
zOuGrnSeed0eW64yr+0ZM6/bo4JSz7xuUO1emdcNTdJemdc8gZB5veH64ZnXBEiVzLy2
Z8qrbkjdC5nXXNQr87oxC+hmXjcGhW/mtRPhIeT2rHwzr/0tXJkZCDmrW7QTMpr8vwk5
9/kmZKTMXEIGFAgZ6TMvQs66H/IQMtJLIiHn1n4QMu5JiISMLMBIyKjGfRMysv4uIbdE
7i5CJnAJWc9EyA1OiUjIOfcfhMxrSl6EnFt/EXLu+RJy7jkSsp6JUJE3FAgZ6ZAvQoY/
IhIyyrIjISMX7UXIDXk1gZAbb249hNzgwIqEjJW/yfaPRlZ5E3JjT75LyA2OlUDInEUk
5IaLUSIh28SFkDm1H4RMP8yhXHrlegDXm5ANuw4hZ22ACDlbDqURsp6JkPPoL0JGa7k3
ISPx703IOIFIyJm6nRFyflYkZD0zMmXmYSBkLOpNyLnlFyHTHxgI2YjwEnLWdYQ3Qrtt
8OeQsIp4PUJ7QboNCHpEdgM9Rmgb6lVjhLbR/XEjtBt+YoS2saA1RmgbyrFDhLbtA4gR
2gb/yitC21jTeiO0G+ZuEfUI3AitP2OEFsCJ0G6ghAjtnsYTIrQHVISWoCNRyStEaBsK
hmOEtpVeY4S2FfjIb4S2sUo+Rmgbbst4RWj5mROSbXS3BbCbV1BQyzFC21RPrAht83Lt
eo7Z/p7PjdByRj8jtK3pkqAboW1oXHUjtI3FmSWA9RWhbU0XSnqEdsPMLWSElsCN0BK8
EVq9ahHahvsgQoS2oSVbiNC2ahfHSFtv1TqkO9jmK0Lbqu6y9AhtYz2rIrTNSl0txGqP
FH9tSNAKEdqGO01eEdqGO2RChLYhzy1EaB2+EdrwBgNxDbfbhAgt4RihbeidFyK0eIEO
Hv11I7T2gCHYVmsOEdpWeZ3QidC2qsRVi9BukHwKEVr+fSO0BG+EtuFa4BChbbh1OURo
G5rpvSK0rdpVORahbQWpuTdC6/CN0N43RFtVd0ce0PfH4Y1dN0LbUAUdIrSY/ztC21Cg
fCO0G+whQttwa0iM0DZc9xkitI113B9HYBvJxAgt9+xGaLW75kYmqoYILU/iFaFtuCHo
Rmgbboq+EdrGa5FDhLbh6ugQoW3ovRgitA7fCK2P3Ajt/YwitPtHnhihNZxw1oHcrBuh
VfS04RoVXaB+R4ZdoG7R0dbk7OIdhAPcoVbdHnhgv7nujLDaktcpgg20/qjYBGpZ60/w
UBEM3Bugt/lpvPrneqg4WXNGcEECzUPVuip0r4fqNUKHVEP/RmZWD6ZutjaDcdamtQll
8JrgzfRt1r7+ZvruubKe0DN9uWreIqlYte/tPQG7OurlwGmjzpcDp41SggOnoZb0OnAa
rnqJDpzW2UXaHTite06ZHDgNrqqXA2ePpOjAaV2ZkfTYELgOnAbPWnTgNLR/vw6cDabo
wOHcXw6chrLs68BpyBu7DpyGFKrowGm4AuY6cPZqUnTg+FyvA6fBuRwcOK3nHh04Dl8H
zn1DjMJWfMD5zkxuuGjuOnDa8FQNOnAaKl6jA8dneB04DX7168Bp3ZNIDZzl5cBpvGfk
OnAar48yB05Djld04LQREvr+6df/A9kM2eNlbmRzdHJlYW0KZW5kb2JqCjkgMCBvYmoK
MjM1MDAKZW5kb2JqCjcgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL01lZGlhQm94IFswIDAg
NjEyIDc5Ml0KL1BhcmVudCAyIDAgUgovUmVzb3VyY2VzIDw8IC9Qcm9jU2V0IFsvUERG
IC9UZXh0XQovRm9udCA8PAovUjYgNiAwIFIKPj4KPj4KL0NvbnRlbnRzIDggMCBSCj4+
CmVuZG9iagoxMiAwIG9iago8PC9MZW5ndGggMTMgMCBSL0ZpbHRlciAvRmxhdGVEZWNv
ZGU+PgpzdHJlYW0KeJysvcuObTmSJTa/X+HDloB27c03pwI000DdKEDjhFdUZ0g3qqoz
o0voD+n/FddaZqTRMyEIlYlExnXj3uccPoxGs0V7PJ/vx4P/2b9fv/34rz/+0/r/f/14
2e7/fP328b/+w4//5T+3j1I+n/LxD//0Yz37+I/42Lua+js/Unk+Z3s//uG3//C//+HP
v/9P//B//fjf/uHjP/H7/s8f73rjrc/Hb/bX+/Hzx5ue669n/fXHH//84/lMH7/+eHN/
PnP/SK2lz1zxyTz65/uullo+R/t48+yfKS+6jM++OvKsniSQ6fOZH18/3pLez9Wzltpn
G+uF/CziSZ+lGlFb/dSbpHL7zBP9Ebm+L+HN1D/z+pkyV8/L+372LuILHc+fpYlcn3t7
+uRc4NW3tc8n4Xsq+rPo/DlA5/lZBj791rrJn0aWt34mkfZ+bGmfBT9e+udYI8bPNfSs
lo/TlUWs785z6m8MJ019E94ra5Ql60s6pi0PfYl+BpPB39i/SrLV9JkSyL0uPX/mxjWz
V/r8fMZaqH/6n1fL2z/n+tax3moNq1dSWXyWxhrDi59di1JAPp9jHHItrXXCGhZ7vVyE
xRb4eHmx0s9nbyIw1LfgO0iCmeZadSPftDrFz61RDtBtjRbfm9d4Gpdwjazj9ZQ+6+rY
mphPfPeazjUtTvbeP1vl+9awphHckTCeRT54d+bPXkSgX+sr1jLpWX4TmDD19e+bAr1+
tmkU1pAzJ2h/erFzSfjyNRNj0+jJ5F/hjQdrtGhOwJuwX7JoMcUaNr57tTxYFc7OGhVo
EO2zNhF4t61xdn9WKwe9lgf718m+fkhdsYY1AVWTvBZtzSGIyV8nwWGOT6PATKUu6YFB
dzDvoie3dM/P57OWK2ODohNr2736fC/cgP159YkxP/v6rTYXv05JgcVBTnNvL3mQwxv1
RQ/6y/Ftck+SNyzOnGC2NbsvBzvQlcXZEwuPEXyOrP2iN8YzIB39C8baQbMdMheIg/MD
Y4ktipTSwBGL98dnwsfXbs1jb50vbLC8lnpkTRv20tMgMzTB5X0g0RaRKBWwc3vWYswS
5GBfq5+59SoHuFaP3TWyvZ+280SvbuWhr29ZfDnAyNheddMUNQ+lnrVgWRfvpPCRNdKM
j6yBj/WLOXEqjSVcfoy1smsFJD/ymsvFGPlZu2I9/A37boJ80PzTyYdTJ3KdAauhYg5/
7m29Wl7ww6KXeAT5sEsi05xLZnVxsDVQOvLj6NScZJ5FrzHiOfbUkBxYp8oa5FySoWBP
LFZ+8EZbwjmQtWHs/IC1rNWo2HzrRWzfAa5K6EgWgSlNa+2nPcuLNdejucY+MXvrQCz4
niXAdQrltXMh8ebimKoFGJVCbY6hz0z2AsPTiq7NReLrx+Y3PSvkzTkS5mWTdULCktfV
sIQgWDevn1ndnPm1o7Kxp0um2esv99zqe4bYXYxbuVXmM7n58lhdIZ3BVBiLtayRY5Q8
f4ak/V+0zIfnH1sKDqPVQnmy6MwNMp+OZTz0YqeuUe+WBq3hfIP6Lpaci4GfV69Pnhtz
LWI+e3zWrj1rZOPwzh43/uKeWipLfhIGvQTRWmsSXD3+iD1bQqCAbVe3KpZeJ/yEaO9+
2Gn110i41GuImWvAc3lxUtNyol9LyIA5SVCmN56UelaNH5fsJT86vcbUhkv1x7ihg6fb
5JE01wAgufYm1TbcWzk/mKVkW5k79a1zb+L35Sq+az2XnDpkhppFchGJc/K+5OhAPzhh
oTtNngz5XcPHUfaumV6cvujKkyOtcyCTfqGIYDRL6lSswdobOC1NYqwpSRw9z5P8VCoM
HP2SRxUtRROLecGyVXwaO8IITuwLEWjPGhVQEPqgPpWxEnwXZNfirVFwwkTiqHLSWCg/
kK51k0sJvI6RvPjnkxuXgm1NdBGDSgHL7zqLR9dezOwW9Mq3Si+ESrY+krmZ0+D3LblG
JcvIzP1BOaGGpYlBQhZwaLH1yoO/QsKHaOuqv+s8miL7tL6C7PHvtTfWl3yOh/bGf/w7
GBtklYFTdHVifPzpl7+pb0sc5sS+/dsvf/r1n3795R//9i5y69R1LjznOCw4s5uOu4op
vVoaFKNceoVoFYuCXpu5Vm3mxa1OY9WWIJopvLE0HuzIMl4K6wQxAHppjVOa95I1Hf2A
5aSeL4GzTvUMLUG21NIzPgfmZLFI57e+YKgMa44n7ToGl0h2mhtPe2u/YSOBEpT6xxkr
tr62FCdDpOsGawGw+2xuxt3QMKC8fuHz1cyslcw4Z1+KtYZJznm1l+IqJBi3LOGbzEKs
sEUzDrjXrCisPHZFmTo4MUpsw5HCCZJhyRSqhdTFF53RiUNWk3CnZUgRKzz/1mS/OtOy
Lej6adNhoAuvkZZZ7KT0qaxrblI6U1nX+TvamUrjqyPB6zr5XICbyp27LBTqn1RVc5Nu
TwUTJOzR95BrO5TkCigaluqccdauj69OtKWLYWAZVsl6XNd6N/EVDN3VAPMEL0BvRKeW
ngOVP2EEi60ll0jCQMjie51/y0ztVDZh86xvXXQ2fhPft7ntqEpFOzfZimbhLdNjaOMY
uXj8CRbgGk0x1TDx5Kg6wMjQa5TWWy5LBePlWoE2vJBcYIQKAQIbB5pq3bRJ6prPGybp
bchOAtbIQdlYkzZwsFF/TxjwC1tqLV+n7rEkE7av7AnwrjoIWQLLD9JlkOHXCJ5PDqjJ
rhTZFo/INveGqpNp2bBcnraaO03bF0TT5nGO6jh+Xb1fpgAZqMM2G+qDhE9f3Ey7ulM/
yzBuuSibXtqKSys2rGWqeGEpjpi03pLU6fmK4IRS4yX5c1uEetV3Mr5n2kG6JNfqyJo+
h0OMMjRkMexSuEU9kQKUsj46lgCZxJgSd3CnmQc9rYn4koGT7Bm5lta9XsWELjUyj2Ur
c9c6vVQ82bSnJeGUXzS1V+sKJTd27IAUMsu/UB2A0dmnsIG6fm9Ugzk2PY2pdsvaL/wJ
KOYYHJglyG2jbR+t7p43tE/GejHNQ0IresM+GkvUNKz40lwafnAJyM7jpgKy8QmD+ZTP
fEm2LLJDffspdQ1vi4+25MOyPl2YRNoMd9hyLE5sdauq+tZZ9zErvGgdXgWd+XlYN7YU
nC9j8Lj8eXh5LIlAblw0P7K4ErqZ07B6svMyG15iPpzrZa4tehxenrI7y8MRkCTPZR7B
fNWwPH5PHYeXx5KBkl0as0jnZti0xZhb74cWO9dmpQl/fg4Kwu5K3QZuLyKp7L1owDAy
FeHfQgsOwdXBd51HD3v/ACAdPJZBQMMfrz9YKjA/tSTYKIHW99IasJb1/bQfBmWfurm/
V93Eb+biz7xDMGjnx/cuHz6Z8+isVDCWkC4uu0A+6/SoLRg2sUW4sLesLnT8yjoHBxZi
0zRekjppLdA4APUCBV86p2vfb6ehu+hh+/UFMoE3MuCb1YkXcObSWB7IpEAPAzB2C5b2
xZzRRi9AmRvR5QzB6rR1qrXwhiZrfecSbYFcfZTJ4S0PcMGuca5VXfPw8Gh6O3tfntWF
bp3q+Ks8hYfomwAckM46mjjVpifyb2g21Q2NvyCL4AEchYdaPJyrSN8y5ck6PLUDCkza
8fqOcdJ2zBrha/ouDoBI6gQoZmPil0jBNrA+jMctJP7tPTVu2kZSgTHxXTCVlNItmAqM
t0swXS0QTAWzfgmmAm4KgqlghwTBVMCvUTCVd6QomBbdt2AicQQTySOY9KrPMr4nCKbV
tRQEk5M+zdBWL8EUWySY1oz0KJgWXbZgInEEE8komJYq/t6CaXVwRsG0ZmJuAULCBJM9
kNhZnxpRMPn3HsG0FOASBZO66d9r3TTBZM+8i2sDBMF0vtr5hDBivlX1Akz5UtULtMKj
qhcgyEdVL3ltxKiqL6UoB1V9TW6JqnqBLRVV9WWL5KiqL/pxVb3kZWwcVX31rd6qeoGx
FFT1UnKPqnrhXVBU1Qs05KOqF1iGR1UvuKKKqnoBAB1U9dX9HlV16+1R1QssqaOqF+hT
QVV3+qjq+w2p4j7kTS7NOKrqBQx6VPUCHTSo6gWmX1TVrYNHVV8NNajqa32eoKqvr+uX
qr42S4mq+pqwslX1guu0qKov5klHVbcew9rR3UMiR9BYstvF9xsJmdc6ZaL4CZ/vBhs5
vdb2fTfHoQXqYxWwBJG/zIsPRxhI8EDp3JaN6MgLrIq/DqMg6w6VwHmhcYRtU2Hir94/
vLx5W4X8KRVQhjaz7lC9JRzWdTSdi5uWPbhpGJDDvwMt7aHavWgtUnsJXVKOk5DgpwQF
afcWS38tsLXeffu4fqtE/q6tOXhoDWv5R9WlYMIOArKSK6E6Egfv0zNbReAAcx6y3iZk
gQUIMYUrLfaqyyayNdUQ1rdQumoIfzySHw0UOUTBNXy7nVpzM3kBazcCi65Y7S9HIflb
lDiEGffsOwllpBwYsuCynhj0pCRY/Qc75/lpfxscAnnKR8R88LFMeN/J1u2Y94alFL28
Ge0UBBxDxn3zHr/vkjY2RPLvBQrXd3w+f1cQszRerP0dQEyggK2wb//4h99/+du7ZyyG
+7IgSOoDA38LkptcTFcfHD1HkCw6R0Gy6HQLkoq7kyBIFp23ICFxBAnJI0gq7hdvQTLB
REeQ4IotChIYHLcgsZYgSOba41GQzPpegmQChLsEyezvJUhmb0eQTF1guSABGQQJruqC
IMElYRAkM81bkIx1bkVBMnjKmyABEQQJn9kqjiXOgyCBZXYJEthTQZBMXKYfQWJDcEGi
IQRBgoYgSDh8FyQTR1gQJLONW5Dgt4Ig8dl3MrdbkMAoj4JkUJRKkAxJUhckfGSCYswW
BQlu3y5BMgFHBEHCMbgg0fhNkCyWbxtrtWubmpZKFP1malrb4PjNVFxmHb+ZCrsg+s3U
BDeT4zdT0zO33wyJr+03Q/L4zehV85tZRIt+M4t+br+ZCg33+M3Ud7Hu8ZupUFuj30x9
zatKfjPrPHq33wyJr+03o2fmFlOXrRT9ZiquxaLfTMVFX/CbqbgqDH4zTn9tv5nwBv1m
1jfM6DdD+vKbWS0j+s2A3n4zJL6234w9o1/MOoBS8Jupi9cuv5n6tjf4zaw5zNtvhsSX
+82QOn4zFYBB8JtZszKi30wF4HD5zdRn6V3Bb2bROfrNOP21UdLzBnf2WogU/GbCJHkD
nDuO30yFaA1+MxjB7TdTIeWO30wFDnH8ZhbHpevCc7F2i34zi/db9JvxrRP9Zjhtx29G
E2wCZRFP9JvhYkS/maVrvcFvhqt3/GbWeGf0m6lAbILfDPky+M04/bX9Zrxl+82cj8hv
Zn3ljH4zxhIuPlIJ2jowkZprdViqLsshYFKH5F0FSb9crzBawmV7xT3YddlesbfCZfui
33jZXtPs92V7TbB3/bK94mY8XLZXsP912V7hZxMu29fgxsZySZzLdnumy3YQ+7K94ufO
ZXtNtml02e6kXeqR3Ly1tM5z2V4hWy7ey8Cq92X7mugnXrZXrN912b7emNdle8VO3Zft
Ff4d57J9fX26LtsrDNBw2a71sst2Ej5EW1f97fgr2QN9+o4PVNwsXfhAxQ3gwQcqnF8P
PlBLbxc+UDEfBx+omMuAD1Rs9ogPVPjNBnyg4nOGD1TcjBx8YPUt3/hAhYtswAcWXSM+
sPpebnygri0T1J5a1k47+ECl2h0PJYiSgA9UbOWAD1hvDz5QcTV98IEKB6yADzh98IH9
hvGRDXmTdVzq05r+J+ADlbexBx+oa3wXPmAdPPhAxe8efKCSndIha73wgQplP+ADa8LS
xgcWMS58YFmNz5Y4/9/mBY6Q27xICe4I82MCIFk7ZJkX/+Nvti0SjnLI8EcL8FtoWSOH
V/gLj9I1oueRL/RrF19Gf61PrMnF8b/fwNUSvoDifpPVbsp3w5pxuNrh45CND5iWP1Cw
Ek7jA4nH/nnDu9jlCPhtEJjvdbZBQK8evX/jfK+VXvNAc+7/+NO//Nuv//jLnz9+/uHP
v3/AuPv4/Y+/LHPxv/z659//9Id//v3jj3/4x48//PPH32Fd1u6n4ktvsEV23E3kIkfl
lxKh0HVYf1fTDYyEccL3Cr36YMO9nNrG87FAYePba/8SVl4zzBdS534uS7Ym6EhDLhl4
94H258+gVeJAolP8IrubKf2Tjl3pwU9ROVhdWC8UCjn+vBGwlfTFPI5gweF4SWCU+a2l
ya9mnUMDv1anPGLgqg+1aujmGl+W4CRqz9ZHcbqVbq/i9Gzm6QdXQAi9+e5f+jKuOT9M
Et4so5Cs5SYz9ZmceW3L3+Ib4FGwDxTZnOXfxylqZa/oA2Vp2ssPfyfTR9yIknQOGIkr
XUzjOoYwNwWenvDgo0H3NK4lPPWnP8McQNjCX1VEoZKOF0VmeqljtzUz3FLT9p419Jtz
UHQ9yI2UcFFGPa7QhxPsqTsYCmF4UL+4U6AmysMw0APHBDtrLRaZsTsP513cZkwjsCiZ
KgFJLikBUL2KJeUtRiNKkaAYvabjtr2ionxBeWJrAetF0QNrbcWXrvUEBjCoxdirD4K3
ylT3q7mnTn4t7gbBg3x1HcbwY4an0CyHfId8rnbDMjA1NwVbW91IdEp8QXYpUOu7qaet
deFJkwAzQR7jLOcCbppnPT9hLQJ3ObcwNCscCECvzd42iQ8spYMf8Bde9RAC5j1kLrZh
vSFxThKuLWFhQncYeL/Q3W3PFa4c2pmrV1do8LVq1iKf5tLpP7u+T97vWFOO2MS/8dvh
SpzmbTpXqlMN06RzTJ2ccvJ/5ba8JCB6CBeNKYIM9lBN4jPAQ0mfm2mTLb/Gud7QaWqs
fU78/kWsyvpeOii/imPhb4Kj9Mz614k+3d3lkHAZipZElfi304CorapdAVHWOg9V2W6N
dsYagYKz+AyMjB5W6vKbzPVTMs7oRDgowR0fzrdE+usHdxtWr8GuJQeuE5rMXieR50Q8
rXCKcHq/3LggOOSXHdEzG8BDR6FvAzzLCPe4tFdxccqANaApILn4i+IYjAbVIzS8XEf4
91RySqGTzsBYq3QXgD1Gfx1Jdd6Qj80Qcyfc+hfSWU6Va4Ezp31ILPw8Y+yNoQdoyTLV
e1OgHbY4mK0HDm6bpEYjFj8vaCD4Sm5qG2lfx+yQ1MBMGPnTySVTnukzU+4GxaggHohi
PckdAm48lUeC/Pu77ymKu8KfrJ8maE22dtwoZB2X7OTgnCUAdurVELSVYGBip3YY6AOb
h170iwaXB9IiekJLFfMZBNknL6n38Y0QnWkaS6X4GHLx+3nmEh5Z+UzlgKqezlQaUx22
Gz2ynYTSTENuAmQdbDDgvEW/Y8debNFl4Bi8JPsZ2As+TskOPr4xGGiy6UlvYz8I2TLF
wjgI16TOJ52DcNpsJd30gOT68G5fr7ouMyZx6X0Qjt6jbmOkH4X012p2FvL92KLlRozK
xOr5z3HtvStpuoyHHjmT3NWXTveS3+BQ9VAe75ZH8SIPtCV0EPcuz2LH+oqgzkO4yZ71
sj/4lEC/FmNyWhK8L9anOxdqIhjVvxmEdE3qaHrmXVqfg6T81unDKhOOzt14RQfA+lEG
dv72QxIUMlleulRR3m8kwxs5S1ib8podkzSzm34VzHNacMOMN5aYQvzJAyYyiUTiSxML
QQ7yp8iXT5scehJg8mY6O5XIIjsNiCaCGB/slKZ2iaencam95adaHi6UlKND0xoMdPtM
/hVsEGSQCIZyNfHpzlCJ9Jg+oTtnkpJtDBmDc9Pwk3JRD4MynZTg3tpIQoCaDvpBGTQp
zpekyUbwmBQ8wWd2kM/1ypgfe1mTQcy7oXQ9h0FjA50fe01tCAToig/hj3uvsgE8kujA
puHjiOXw19xAXU44PjiJVejb+vYMfEyWTtIhnc7sO+kRrbvhraaUMNpvjQ3zN4iRT1P+
6Q1qT3ggr09lGeJGZrsX2g2V/lE85bqP4fWF72GjJOD1LlMTQsgoiQiJYBIyvw/MjMFh
CpPYeamnm3wogGwTYA9AlkoDH0MKBwXem7XrmkE6CR4+ieYD40cTLliamTREMrzfj2aC
M4kZlRYK8WZa/wfP+IedYsSWaxLsu03kOzWKRPzU2ZB+d4dNoadJpnnDkJr1voP6fqON
TQ0B0bfWV9P7KUby0CgUIic8hqz9MhzdaOPuVs8bxsA24k2ObwwOZoFABqSX7R8wODxx
MEEd54k01PbuHv4mrecxXYL8kbhQcM56AzksKs4bwBfJjEQq3G+hpv2KmO5mLI6ChpCa
H9OVd8ppQ7PUgxZpgVlOPgpupSRBaD/AZKYK4LR3NDRiJy8XGxQn38niyoY3ELrSmq1O
wpQepIVg5UL/M36ASnOiNT0l8V/SSaqz0ykrEmi3pDnYI4spTePR8Q8lNQ3p1v2R3sVn
AIzxsUd67GT449ok3YAgrB+QAKATUlfSWzUbS6I123hQPjPBCxnZJLj3GK5rzyjUEzCJ
3g+Zmm7fd8PLq31ueOzQ/IgfwVGwhOH2WLWzTeDhQnGUjy0d6T2GT7wM3AVo3CUPveHx
I7UxOvmvthRdCq1+DDH+6NrLtQv2GYqq3jTCozQOb6j6oH/BtO6BIXG5M3PQdjnuc4Dk
xeV6WWR+DMX0BnEXZwWrkBGEn3TPSYJrR6cmPcMdErla4hTikOsq/YmQX+YvwpVQOgB8
LiAbsmI6KdsKV+SRaMMyguCuZPiGPZMpn+A296RAp6LA5NNSsnZ5pu6bDMEPW/Tx0Fab
t8GLcG1kVzAQY/dM4WHe0k2vdw2iKD7FUb9F854w0E3XjqeFAPP6gkK5VDEyXOhi81SN
GgYztAmQP7fxo1dN8V1tlf+aaszO9q1KO2mqdAIYkUtQpa8Wbvf1jxATqNI4fSo0It95
NfWozoEM6lxNzYxNV+cAMOWgzmHUxA9NnbO5PStQ6whabJad0BZvN1NjpXO0SYcJHn3I
CgMJkw+59mQ1nUMNXTkrkMcGu71BRUgKsSJhHIrTs9lRWxhUp1dhgUMWtF50jsrwSvBz
lBYikY10NmUDJ8xd086x25YE6fGcrVPK7asLnLW1m3TDqr+Fg1KM61GjI0iCO2MekZ5+
IHsLwumFqvLjAEq4EwQCOv2lcUJFOW9UCsL2KEEN8CGAmKA11EJnGObaGU1nP46NRgCJ
E2rIkpy37QHCBtbfL9GmTaYqBNRpJUMwMC3BEZTw/9TfX7pzgPiTj+gSNHQkTIg2pEaj
29MEGIjGPe6wMZuDEatfR+OrvUg1eiVoa2PQJFUl/LbRXxvLPW9IRtaRDQ4guefH6ReR
2zx2cOa1xTFSo6dmb+2utA8mvlGlO/rna9fBZOQ6V/uI3z9455qSYroWzdQrfibaltHG
WpNbbQp/E5JYfXZdzQerUqPKXatZ6OnzdQzDlrNOyML0H21J29kO+Y6N0ajh6VKBM0Pj
VzcHfxXKE6bNaJ6b2iXWglXF/WE7n8GqMhfU+wp/WGsHwSiecNHR5b10a2HjeaIW1ueM
Wlif7ZsWBpDn0sIACx0tDFTQwoAhXVpYH/PSwrrdibgW1rFzLy2s93ppYV0eb4eu85sW
1nOJWlinwm1aWH9b1ML0TFpYT+3Swvq+jnMtrPf0TQtDUpmohXUamXYW9DGjFtbdAE1K
pxO0sN7SrYUhV0zUwpCfJ2phfVkJtxaGANOohfVUoxbWlxV4aWFr5N90rr/Skp5vWlhX
pPRWsvpi8qiFoReXFobI0aiFWceNIUv6poVh3EcLQxKioIUBZ720MOOurYUNSCHXwsb7
Ri2Mz0wLQ3arqIX1Ub5pYV33bEELwwpELazndrSwnlvUwvTMdCxkEopaWFfOr6CF9T4v
LawrV8DeorYJz0YeqRwt7FVGmb638OhUV57FYmCZTVblSeqGvkHmIMlSz5HWRUZ65LeZ
hol0uylOiGYlyDGUbm206hdijxYaAC5FksmLseS5YLPOf4HRt9clAlZvgEWmwQ5IAsTd
LjyYhFmdzIKjZ1UpopIk+8ueZSJHAqKQXoqKF5ihvoc0DRGkM9GoAkSc7NUUUW9YJnor
UiDxVdPOfde95lv85BQwxVRFSdvGtLHJs88BHqC7TyTfgP4M+SzynGm2mry8gao5dFGk
EWpd+TeW/+dmD/ToG9CZX10EHaAzv/JhMqDzJhnICkUnAJ0ZN5IB6MxQfC6gM/PG5ACd
i3420EniaMYkj2acsXUuoDNTBTyaMVPZBKAzP+O9gU5vOVZHBpsGoJPJbwLQmRGBGoHO
DKg2AJ2LzhvoJHGATpIH6GSmmg10Zjg0HKAzA6WNQGd+copA57Lb8gY6SRx+0jNbx2f9
+AE689PeCwfKsJAO0Jnh7hGATh+CAZ02hAN0suEAnRq+aUCcmwB0ru/uN9C5Wt4AdO7Z
d7KXC+jMBGUP0Lnm5HGgk39voNOeEMhkdqUDdGYG0wagc/1qj0CnxmBAp43fNgqzBaXb
lMqADS5TKgOdOaZUTn6R5uR7mVIZYafBlFp02qYUiWNKkTymlF41U2oRTzSlckLMxTGl
Mk7UY0plnoH9kEikEkypzKPvmFL55W/RlOLfx5SyRzKUMoOUR6BHvU2pDG/aYEplOMkH
U8rpY0qFN6qyVs0ZTSnS0ZTKUMmCKYUXZErxr2NK2QPaSplaWz0kgjaPKZUJYG9Tas1f
c1OKfx9TiuQxpTLQ4GBKZWC4wZTKcIW7TKkMbTOYUpl48TGlnD6m1HnDpHefwZQ682M0
4eptSmUwWzClMrdbNKUyVNJjSmX6jZ6vR3BCNKVyMp8OM6Uy86ptU8q3TDSlOGfHlNLs
uiDZ4LRMKa7EZUplyJ9jSmV86TGlMrDmaEpl3jYcUypDjgZTyuljSnnLMaX2Z8yUyli7
YEoZT7jkgPPZMaWQiyT34RpYzqUGDeyQ1MBIusa1iBI1sExELmhgGd6CQQNj1qaggWUg
w5cGloldHg0sZ2WNcw0sE9GNGthqSVEDy4YiZuWhcoSxKFGVnlEDA7E1sAx3+KOBrZ8d
QQPbpDQwks5eiEc+GlgGEB81sIyUj0EDy3DjDhpYhl/dpYGtlvfWwPiZrXKtb5xBA8MP
hGMpK7GPa2BaL9PASOwRal31dx9HA2OPjgZmUgBRq/EKLcPN+VyhZUCg5wotw3EqXqFl
5j3+8Cu0xSglXqFleNhfV2i5vCNeoTE7l1+hkThXaKtz5bpCWw0pXKGtvo54hca+X1do
ucw3XKFl+MyfK7Q1VfO6QstF2qNdoTHNV7hC876eK7SMDBLhCi0jYi1coTl9rtD2G8ZG
NuJNwi0jqk5l5HCFxqRh5wotw9MvXqF5D88VGnObnSs0Zip7A7nmNV6hrRl64hVaBmju
V2jMQhev0DJ8CW+J0+azJU6rPUqcTUrigNwSptV2SZwGoDtKHCS7jhIHSFyUOARtL4mD
5GBR4sArLUocQn2XxGH2sCBxmvyWJXHam6LEsWeSOIs4EgdgadiPTSaFSxwnTeI0GiNa
6pZnlDjMdRYlDmDsKHEafJ6DxGmzf5M4beZvEgefOSIGaGSQOO7xZ1RLl8ThernEAbFH
qHXV3/MJEgc92hIHW/hlsjCxZ1XqrcZQxaSQrdw7k6puUjlO+EtqmLYjC/d1HoTtTHEd
CgJws2E827yG9jIEEcmEAtjSx76AyUD8DJpBx420Cxhm5HpyuIC5WuhtneH21+2WHys7
dINvXTH0UEAOyZ8/tpbHV00CDWVhchL+bCUIKOCOVHyVcygzQzS361SmtWI3PTT0SAZ7
tsNKUUNV8rVc5OADHZgJ4eSJghs3ZKsbki7bvCVY67YsM7LFhqcrw12ZH4GWSXnoojif
06J75UUzWHv14TnWLYiwpCBtSZERiq8CjeTnlswm1GZLBCx9jL2kRvqS0sNyxiWNLWKS
vji2vmdJOwEa70rpQRAOOCp8O1qRses6WhEmHY5W5O8KR+tEzsh4tDK11jla59OuoxXR
zvfROuZzHa1wDdxHK4hwtM7R7qN1jhKP1jme62hF3++jdbYcj9ZZRjxa6doXj9b51ni0
zue5jlbrazhaLdf6PlqB6sWj1ehwtPobJi9txE7OVO6jFTH+4WidfcajFVnGr6PVehiO
1jFTPFqBp4WjFa5/19GK9NDxaEUU/D5aEZt+Ha1IU32OVjmIFoBJV1wEs1qFuAimLwtx
EYWhNTEuotDx78RFFIMi6A5aHIrRZUExNMlEqF41311+T4iLQOasExdhlO02prvacRGR
ojBgfrQQF1EE0elGuxhEZ3ERxSA6s+P1quIeCrG/ckgIhhAXUd4dMwKhat3wuIgCb68r
LoI51UJcxKJnjIsoDJuOcRGFONGJiyivwTLy0nbSNpE+0EJcBDJYhbgI5gCLcREFaEaI
iyjAKkJcxJ4rxUXsuZILMhPTXXER5VUIqCs5XNMQF+H8trmyvHLhvgRdyVvplKArMLqO
oCtMW9kPCSfaIOgKXLGPoCvYzkHQFaJGUdAVmtBH0BVqJSboSBxBx6xMUdAxLdYRdEwL
FQQd+34JugInniPoCnGHs2TwK4+CrvA2bAu6AtQgCDrv6xF0BdH0QdAVGP1B0Dl9BN1+
Q4LMR7zJmi9BV4CMHEFXkOb0CDrmDYuCznt4BF0BSnUEXaGHSyDrewm6gnTSQdAxEZcL
uoKA4SjoCiLoo6BDdiT6HzFOJW/yp5Ma3iZLV9gBbthAQnVxlb4wC7YWpyutV5oG6dtV
boGB1PZyIih6lkM+eRsJbEBlALnfE/At2YpQIB5ylE3jA4rYOW/Qdahk5VXk5kFauOyZ
uze/+08AFsIYsvk5G4pVEL5tfvdpimerXYqgAA7eQMQyIe/EFRb5tc2O84I0HX5BasLS
kOcLP5mlTHclwMsKjkgAmpFgMGNHwLOQY9C73GrVnuWMtW2q+yMCRxHfA1UURp8sbR0T
zsmRjGpQKdX1FfzKSz7QdR/EyWCCLRBwldLfX9LlRvZHJSmVXXuE6OsXyBNmWGXGMZXM
G9ifG29n7j2ONjPJArPX0YdU4VxOcwmY1/u88TLhbgHYwzCTVyIKuT10VqBlDk0HUfiX
8TTM/0Y8cdPV76Ff7lBmqOO2h+hH3gzCVSLGp/EQKBOPdIflJpB3JQFr3yLk0KnZqlnu
ERo1pl7QupZBpy+v2O1RoQG6iKYgaW7aei6DmaBvqc8Kl8O9Drl0KKwQfrdI11jM89JJ
OaltUiFACQlYJhPg4aPj0S83vTun0qnhWebQlXjDCE0RORNLomDyBGCR+4weeLxs49/4
wkFWsUcAi5qYmP2M45K4hIs3Wtb5J3lpMqJRBiUdhjZsI4viLvbVUEFSEhqAy7B4MVBz
rIHwhbBHMvrhFxXMRIh7sH5WiPqDPPJI4NXJ+GE9S/wrqXSViIdOKDxRyWnPp7ucpND/
yqwyRh6BXThlV3RTQUDnFd1U4OJ4RTddLUVZ8ZCbJEY3FUTIhuimgkJtIbqpAPG7optK
fVuMblr0CfMlccxHkie6Sa+aA6Wn79vqLIJIT3STk67Q1v7c0U1XC50815yMGN206PZx
ulJ2BCuTH5Z2RTetLfnc0U0FMbEhuml1uOwYJBJfO7rJnil2iR98Ir3d+k/LDNFNqzM9
fLMjCoxusme7kzNGN51v/uOephEBIBpYBW6dx7lrkT04dxWgXJdzV2nKKr+du5i3cjt3
kTrOXQUZ96Nz12ro0blr0Tk6dxWkyL+cu5T18jh3lVZadO4qDZeh0bmrAAA8zl2lUoOQ
cxeJr+3cZc/o3FXgvRmcuwpCgS/nLiTVvJ27Vnff6NyF4X1se62ZXNQdmD2j81YhwhrI
8lzOXQVursG5q6AwRHDuQqLF27lr9b5F567SnhycuwrcZKNzF0Z+u3L91ZZxO3etb32j
c1eBA2tw7mIvonMXs1oG5y7vuBiyped27uK4t+vCWoERnLsKymVE5y7nLnfuKo1uDcly
jZprnZy79EzOXQVIa3DuKgBXL+euwtjl6NzFFQjOXUj3+uHOXSS+tnOXPTOrEE6ewbmL
g7qcuwrcVINzV0FliODc5ZvwbGTAeJdz11LKy97Cvb4B6D8kgX6SDuwXYGoB6C/waYtA
f4FnWgD6F10i0F/gnncB/aWbZ6zLC7gMBqC/oA7JBfQXAJsB6F90OzZwt5wXAvr9GWFX
EBvoL13mr8HgpacSgP5NmsYN0pmoC4nZJA6rAPSXbgUxDegvjM0+QH/p872B/sK46Qj0
8zMb2S+AjZ9AylxzqrYI9Gu9DOgnsUdYXwf6ufw/D3vMEMXq5z2KHd5gVVfGsw1Fwc03
glVjycMbrBqqNbjBqvHWc7oPeVq58Bs6RRys4qsOVuF7Ilgl/+Cv3f0UwKrB8AAHqwIl
sGqUfoFVg4aUgVWjpAhWjZIiWDWkLVNJRBB5AKsQQ36BVSjKGsAqdWODVQBHb7BqWLCE
Q1FDFaICXb+BVSiFEcEqeAAGsMrIAFbtF2QK0wfxgFUIVb/AKrhlRrBqqNLABqt8rgys
8rkyjXKoHmoAq0bKF1g13nSBVcZvR2ihOuEBq7R56pO/RaUwm+1xpVpkjEqpT7qjUpaG
ekWlILXth7tSkfjarlQkjyuVXjVXqkVcUSkVOa6CK9WiY1RKQdnI40pVZrujUsrMV1RK
me+OSuHfX9uVyh7JUaowsn1E+ltUSkExwuBK5XlkN1cb/bVdqcIb5PFFX1EppKMrVQE0
Hlyp8AINIP31tV2p7AF9pQrzCdRDtisqZU1YjEopc+6oFP79tV2pSB5XqvUbV1TKGv8V
lVJQLPRypSr0tj2uVGU+V1SK019HOO03JPFnilEpZ36crjEqZVlNV1RKYSXK6Eq1WmJU
yiJjVAozKkdXqsXjV1RKfVKMSvEtE12pOGfHlUqza65UZNXgSsWVuFyplLJ5u1KtpYtR
KWXWOyqFGZODK1XBVVlwpXL6a7tSectxpdqfMVcqZnwOrlTGEyY66lNiVIpyrlTcmr4y
XDL9KyvuTcmCLEVVkUggRTLbPHtDs0hG4aqLZhAII+9JfP3wk4Tk0R/0qtmq/J5yrjrZ
sd79OHPSzrMKAdviVefVYt84u2nVvJRddJa+UbOIrx8mTEgdi535d18TY0zpW5XuzchU
VclwN5RXU1SYV2fRk8Awczq+5rkLRHiI5BQwU4te9Q7jEKNO5ENK49MiXDlmkXsKZlXp
w/N+aKG5Xnn3Mj/8chkpcDEFPPRJUGI8SmxsNwr5UZrhvgFkpqod9ZCZBai3nK44vYpd
DyCbM9fi3adwpXN0CQejt5yzsT5Kfm0WMdJxPp2FgogpOYeQ05R1z1n3MDiTRgd9vqaR
XJ9Hrtagzx+S+jxJ19+Z4zXo85UyI+jzFVs46PNMjRv0+ZpUDOno88yjHfT5Cs/KoM8j
GfatzzMjdtDna2JySKkJJI4+78+q8hJbxpiXPXtq0OeRvzvo85u0/QjSxSe27NHnmS83
6vMVrqtBn6/Jcii6SpKUz/7o8xXh6Zc+z89sBR75cYM+jx84+nxl1bWjz2u9TJ8nsUdY
puvzXP6fhzsUEBcdd2pJT3DcqSjucxx3KjznUiClK3z92A1K5uWOO7Uw04CpSWVELw+S
R5HXq3ZTway3wXGHaVqP446Tvu9PaLO/H1vouFMBKQbHnUUfLw8Sx0gneRx39Krt6zJz
cNyphWk1z7ZHfezguFPhKBkcdzi7X9txh+Rx3KmFKuFx3GGy2uC4U/Ocx3Gn4vLhctyp
uFOKjjt3AyR+tmirQ9fouFOBnl+OOxWwcXDcWfQJSyERljTP7UjAZLw8Xqp/7o2OO+uX
UnDccdKXtMjeCUsaW4xJUo6OO5zNw10pHvSALL9FW1Qk4LtNBOAjwUQAehNMBKApl4nQ
3FnXTIRWxjERmmA35/1m0KaZCHzVTQQAj9FEQHhvNBEabMNz1gDcOiZCBXIWTYRa+xtN
hFr5WzrVa/EEnkw2rEcyAGqtJZoItbb3NhEqgqyDiVBRxjSYCE4fEyG8QROhopBqMBFI
RxOhIvI7mAh4QSYC/zomgj2gDVDrqMFEqIivDyZCBTR4TIQ1f8lNBP59TASSx0RYv5Gi
iVBRsyaYCGvG8m0irCls0URY9BtNBKePiXDe0CHCSrVHh9/z4/SYwUSoQEmDiYD+3yZC
RenYYyJUwKDBRGgl3SYCMPFoIgA1DyaCbZloInDOjomg2TUTgawaTASuxGUiVKR2PCZC
RTGmYyJU5NCMJkJFXeJgIlRcxwQTweljInjLMRH2Z8xEqMgVEEwE4wmXHKisvE0EmyX4
q14BjZXhoDug8SY5TqAaIaBx0VfmtkV/y9xWx3tlbqvjOZnbSHztgEaS4RxBFdwroLEi
WjkENNber8xttddvmdu8JRwdcEINAY2LvjK3VYRIx4DGikDzENC4pu1kbiMhDUU/N2Lm
tgps9Jyy8B4+AY2VKSdDQOMSeFfmttrGydxGIuhcfObr+MTMbbXnO7HVmoOYua3CazkE
NPoQLKDRhnACGtlwAho1fN8ZDMI/AY0V0O0V0FjhqHoCGvfsO1nvzG0VMfchoHGNbWdu
49+UsQhotCe8la6Iqe+BLHfmtvWrV+Y2jcECGm38vlFQEPnbEduY3C8esQ0XjOeIXWQJ
R2wDBBGP2PZYzmI7YtujqF4esc3jNHXEkjxHrF61I7Y9nmNNR+yiczxiGwpXnSO2AZQL
R+xEMGk8YqcFrfkRy2SQdsROd2TUGalHdoCiBFI8YoEA3Ucs8Ip4xAIkiUes0eGIPW/o
iAWKFI/YWft9xM7ariN21m5H7HR3fx2xeqAzdLYej1h40cYjdsLO3kfsmr/iRyz/Pkcs
yXDEwiE2HrHwlo1HLFC5+4hFhtV4xAJUi0es0eGI3W9oVwPoDEfsnh+nccadIxYO0+GI
Rf/vI3a11HDELlZ6wxG7OK1cR+ziyxqP2MYcjPuI9S0Tj1jO2TliNbsmSMiq8YjFStxH
LBzUwxE7+4hHLDy+ryN2tvc6YueSNPGINTocsdYSjlj/jB+xAG3DEWs8YZJjDbn8BQrX
Hsn8g8I1GCAHhWvIdZkiOS4UrgGZCChceyS6KEVJHBSO5LH69apBUPyegMKxYweFc9Ls
lkbn22i3XC36RgiRgMK1lye7ULj2uqyGMCF1ULgGsOOgcA3/HBSuGdi2UbiGag0BhWtv
KxuFI3FQOJIHhdOru8N1RhSuQbQcFM5JnwJ4vl0o3NVCFK4xA/hB4Rb9bhSOxEHhSB4U
Tq+anEb9qoPCtVf1FLacbhBxAYXTWhwUrqEAwoXCectB4dqrCksHhWuPEtE5Cnc4TSic
s+5hcDh1/P+qV/lXiog0+I5cRUT+5V//9V/+9Pt/++dff//vH7//y9+hVEhBQT0UdOjy
5HNaQBnyyH2qwAayPnUlx05CShFLx/pAeIZasEmfY4IwI0uz215vsCIeMAZYPQzyvioV
Oon1KqsXVHvm/bGsi1d3OclwHxsqeaHE996ADDIYQWaNCFReQ2ow5eXOcuNoOvn1rKkU
uYMkTtKjHO8anYXKNMlj1E7igYJQQyS+z/BIooQ0r5YXYdCJec2GSngw7VlVdZQsvKWm
qo7wmQ0Ad6rvx7cBcsytFFVLcZ0L9SEeq8QyGA9e364SGeYYemgF0By6W4743QK4lxkF
Vby31Fez+KhgF8c26n62NgddR+xpggMFi12UrnRWj/dN1ZxSZ4FaUj+Nqg9Vf36VUsvf
LSwONlhxdNHZCj4gm9pQvYEi8d+8Simjom2eltkML0DjQHJQ32R9fX2NLgoxQ0Yz5H6u
nLxGYIKErRZ7jWfGkQBQlEdRZLJYn92gWUmo8MXKwJNxtgmee/MMgMkn2x4APsxyF52B
YT/B3Vm1z6oCvxAtXF/NNhcKWcHb5gRtESvaW5QqAPuLpfIwgfSJRHeqckyKxKwoNt0b
snT1WuhHuoaLlJDA/43gbmJgs57BgS7Z595DokCY5EHeq5Fe5Rus2Rf1rSpN00fg9zr+
kt+BEdz8Xme++B2gQuT3qujSwO9wJov8zrBf53cLCXZ+b3JbdH7nq87vKEMd+V1wjfO7
KOd3OCze/H63gN8bMjIEfm/Q9Jzfm/Ri5/emE5bzRGTy8DuQy8DvLBAe+L0/8+L3nsfh
955H5Hc+M37ub438jgm6+L2ZZ4jze7M80s7vNgDndxuA8zu44+Z3eMpFfsdsR343Trj4
HV8a+J0TaPwMV8nA7xvb2g2zXvzeKYmN37tuI5zf+cz4mZ8LpACkw+9YjcjvWlTjd82J
8zvtceN3m9SRxnVKo7ZGPKV77eeU7jLo/JTmM190RHicU3rg4/GUhltPPKUH/CH9lB5y
vfVTms+8f+uVcEqru/GUBhJ2ndKjPtcpPfpzTmkQ4ZTmMzuG4VoVTmmkcoun9FjyIZ7S
AMXiKQ2vtPuUhntbPKU7jEY/pbtsSj+l9cwG8LzxlLYBnlWczwhSSyVMmaetSGpJVsC7
BIamy6SpxAWHTl5A6LRMes1VFOJhnQ2TWtMIThyrbZP8KWHxvvZqUwkbfk/nRE5V8HhM
alnvTWqJYmYBftO8KEJ971S9OP4OSl/NaryNDTTlCosqk5juqWgvlKVC6Su+Cjd/fKzT
V3KT47XL492QbW7gwWLdoFxpLFrwmNccrwHRT2Sc5RuDdarmtKymohOMaHnN7RaVI+fc
MoPFa8JA6Y6M/JJw0gf0gvh+faMsDdsGcM2R15w3jLJl48v6EsWSNjPc2+fKZaPNlctG
ego1l404GejNNCQbUcsGa8oRv1nFLN5ne81hIRP80rbXnBJcz65d+TDzNX8Pd371kMiC
b2RiKbYpdBd8e2jL41iakrIgqTZ2S1EifoYc4GKQd6dNGLRWt+gESU9RHkckeuEbSXkc
WVgNfU+exxHDZw2/pDyOULEQk/gwffZjKQcUHsIb4LafKUHro/Lpa54w6uR5HEVm2vVw
Padvs5E6b0masCTMfiwgluGQa4A3DOVxxA7jV015yrGEFizHx/M44oyj8+XjeRzhMc5K
HpN5HBtvMhNs0CeSOo6Malr8lpS2huvVHofvyxmh1lV/T8vjSPZAj7ZrgDmty/eeTHJa
CFP+DC24g8hKQazEW9DmHsOyTZlgkvQ8xMBMvNfMK74S4Ykk05KyGHrVsiVF0324LCZB
Mf7QDE/yDNi/KdWGaQ/gU0LJpzMAcVHGSE0wHR35eUowmSx78qRD6vKC76uhKS87vpAu
y5asO6kw4h4s/t6DfZrddFfCpJFUFFSixsDBDuEKGKwExKv4OdybVXv2UwtPTDcdpoQD
bhqHbO7h6g2WZxWXgLosUFEKZ/B3J4HeQSJv8qOAxePuBmKgCnRiizKcJLoZJ6TpmTWw
h0pAO0sducRyHfuwVPZtVBsWFgjVjGBkt9ThRFYS8h6mSHbDAr1hKPAB+v2johc4KS0d
wTQVQ0H3SW6iPgt81UKB+D1MyK2Tkh2TPWh9n4YFkgROIOTP348t+kbExTIPe+Z+Q/kN
iQUcPiC+dEJWUT+3vsCKIMzr/7IoCgqG0GoxskzDAr3B4FLwERgnU9fAjVASYdosOCar
KoGvEV/dHW6WpN6H5CVzbcwifQoQo5qvKYgtXVUSHktin7OKL2CTIGX5YwR1BlbNJvlT
Y0L8Dl+1E5cVTushmzvYeUOx3PLrrIf6nbPpV3bCI72Bf4CHrrecc5cFMrLtZPlTo+56
K9L9nEPIaQjvzZt1D38jVVpU6fG1KFChsMqq9IKpZA8IM4XxapHZD1hnXiyBkOeRTGXE
G4UxyIH2q5HdYu6xVCExoRBgpkKSIFeolFiRDAOnZnu6uaKYDr9XOdmwfdDTwipJYrIU
ROnvxxbjimGS1X9uHAuVhC0UgtmK37yiajckYFGKmN9CS1VIDyaNX1/4n5fHcdHNKwYB
caNn8E62Dz4l0DsfzW7pLHuEqeSLNIn9m1Xgmr+6n3mXDGX81unDKtDd9hnMo6POulW0
2lJU0Zw0Fa2Sr0wlq6pwFejnVtFq7ZeKRi+UoKLB0eVW0eC2ElU0mIJRRQND3SoaGTmo
aJXCy1S0apLOVDR7JhUNvLpVNGr8R0VbMjyqaE6a7K6UrDrtIEGCilZbvlU0eJZEFa3O
91LRmu7ZgooGGOlW0fCZo5NV6A6B7DOoaHQlCioa18tVtOo4xFlm/T1rUNHQo5s9emUB
aOcQuEXM4ppF+WsN6f10TTk3K0OQhKi0smn2JStJ/n5DlbSZ6n9+bBEEWsmFfE2QnY79
3voawxIlyoS3peYFb2jepebVbl5lLDCaDCKIc7/xMAgtIYseZ07jAuZS5ta+jHQFDD1z
0qDJ0KKSPYRMkpiQCmRSVgo/ecgWMgDX+KjjVgIf+I5pVVrgSmO6qLS11qpFPWPdicZ0
JSM0w3zRUnBdsBpNPlUiif3G2vj4YJcjOsbIwiG4ZxdeaSK5qfpmo24HiLpv4rH8ACIL
a2snJA9kGR/kf+C7uqtDB5QBpA3FLEGp4/oMlRhqyptx6OSX97vllXndLFdQU9BmAmaG
6W07iLM/YjB/o8PHAbMGOSUiV2NOkVUFvJuhvZgQ/mShUrZ+ckrT3Edqz0SIfprcmVYU
YnxsLkCUahVXwUnB9teR0KidkeIOnOkI6DEvAe2kCWiQWyAjxi4KaKR4uwT0GLeARphf
FNBjfBfQo98CGmF5UUCP+l1Aj3ILaBYqcAE9yiWg7ZkENEIlt4Ae5RLQo10C2kkT0KMd
AT36JaARtngJaOJQQUADD4sCeubvAhqeIreAxmeORJ7vJaDnEwU0ogqjgOZ6uYAe8who
W1f+PVMU0OjRFtDSQvPzpgjfJgR5Bfg2zfJu+JbEgW/1zGejPwG+zXA6ifBtRqHPAN8i
H/6Gb0kc+FbPvH81B/jWuhvg2/w8/YJvM+IqA3y7vqFs+JbEgW/1TPhsfiyrhJNvjfBt
JiR34NsEUC/At4mJDCN8u6akRvgWU7ThWxIHvrVnHMD6phrgWx/g3uSsY/A33t7Dkpi6
vf/D1//9d7iyN6Znfm052BmLM8O2ZC/SYjAxds6bRO5ws+mtYThUVFQxgCfB+1iudW16
ZWwnScD2VcUA1vLSXU5GKEs2a5QVAxiY/iVDCYn5u+KhjK+YgaofsrhPjTe8qgUHRYQV
A/hbtIP5N63iqRT4fKQ086wHQJ3RaMQ/ycHutLD49v44fDPe8uEwtNNfGicrBvgbSgzP
FPBUDRKNedJ2g1+U8/6Vvxl0YOaY16cf/UW5QaPfHjxMG4kMU089JNICaf5EV1amNjUs
J1quSOugv/EirJciEqvUqXxkZOXA2QVfdlVIUEIp85lfM+ZiE9orKwZgKU2/ZMWAIWzJ
7rqc/tq3CecNyR4498wt2M/8OM1rfweIMt3UyKFZs6ccIV8/zhvKLLU/31RcyMmlWtjN
vzVMZuRMuDwlF89JnTCzVIJvGe3vp6hiQKNMhqCtPrsQNKwYYJWQcBBwNRXPwi1UVTHA
CmMJE8zMJtYOiY1WDmaYk+tAL2uYsFYENTclVnGako1uqN6CVR1MmLA/g1VlxQCAGPQp
GaoY0IIhuYb8Hgc7ZGN5kHJckbK/HemMeBppWaxsUFw3E4mM5rk4VsrM9UVK+2TOIJQT
kKmpxPX7OsVJKhZYgKbcwU6Obvej3jDN+eSld1tGPrRp1ztMLa/Ldvt2pn/XdTtlUyfX
I9sWYRndNTFhOne90xrquY1ixnQqNQI/fHq469uZLtu9rZ83TGQxxfu+B83IBPeG2/Cc
ld+I6hZq9mRLzmIWxV/MmOHpvq0zp7oz9R4Ju9wrrz0z7s/KZbNJ1eQ5uwP55/IGfTMi
zN4kPBa9Ylqy6quMhOrwMaKNxFvxjIBAXqJPlispJR6VTDHnjFZUaiMDQdFVJ1o4102h
DUWOg4tWJqZDN0mM3dCV3AkeLpPp8oH76VPZwgpNMcgWVmi4kV61m871PdM0PsJO3rWv
3X2SBlNlO+jssvMiVX3FBL61JFYuYLShY5mZoYMG52aLMgT0UIdI6qYqHFKrx//aXcRq
MeVVYqaa03nDFSHIwknDwQ+GgaYj3327DMi1up8as6JkCAdaQjY1RrtnQo9vTH2hnOJO
7758Lgpl3J6pmxSrHHgvNmieXJFu8u/POHv4w2IyqHCGO2jQGdswyUJnPYvsyUIrjg20
NCk6ZrBnFBVNEjKVP/BsRKBqrHJZx4VTZhKrYQSM9WR3uyQ7Zs/Ag+9khfd2diyhje8t
c2ilZlZf3qFZps4vt1inKVroyRLeYLIrLkXtRwSiMLBcbQDl5cNMwBJxiAbyZQUNotNs
maoXMe3WNhOHyKiJTKQ2k7nKrgpUMhNUn73xx73I5W9Wi+Er0qgW//7HP/z+8fsff/n4
xz/8/oePX//88Yevr//2pz/8/svn364sc6F6b26Z5671Mct8k7LMSbolnruy2AT6vSzz
3JWQ0C3zRbdomTP3/mWZ555StMyZfz9Y5rnvZLRmmTP9frDM17Sdm34SxzL3Z1MVK5DK
xyxzpsY/lnnuSlpjlvkmZZmT9CMDmF4PpNSdc6R0pcx0yzyjVGmwzDMKlV6WeUb42WWZ
8zPbFF/f2INljh84lnmGU1SwzLVeJlBI7BHaNnxt+Q/vokcHOkViIJRnsBtG1ZkaRRVx
oHEjcT3YP5BtWOC7NwyFksHAZMUKbngznMbM4SKF5PHF0asugceQJHLJCRjHrrfRcSNd
0CIb0JOjpI0tRGYzMA9d4GllZ3o+dldmetzCgw4yk12vycrgq6a+oC5B2b5/GWmgwu3a
mpBXhhcAWKTtt/p6EM81a3bxdmJSY5JBPsF3q0fxhPoYOLpcPA3V5DbphHIZCnx36QRv
NsFrpnRcDaw/MbpuWzYtEbvp+Vjgu7egeAiRkcJqQovmNn9UtuBp15I+e/fg2OerQEf1
uSJo15aIZYfHXlIjfUnh1fbEG9OrxZgkG7RuSzpo4XtXctTIEGGWthsH9+PSlssNGhRU
bjygQUEKkAMalGcH1XpDyxE0WPS7QQMSBzQgeUADvWqgQYFnUAANCgKBAmhQHruyFY+V
J+cAGhR4MF2gASChCBpMGckEDab1yqx+PTJIALFtETSAL9YNGsyRLtBgjnmBBkYH0GC/
YaABkiVF0AD0BRpMQ3gdNJhjGGgwx4iggR4IFZhWzVVkgdNaAA0KCnYe0GDNX3XQgH8f
0IBkAA2m1Sp10ABlQiJoMFv7BhrMOi/QAHF9ETQwOoAG+w0dIhMpN49Vv+dHdGFE5gYN
CtDCABqg/zdosFpaAA0KouwOaFDgcxZBg4KUugE0KMi0c0AD3zIRNOCcHdBAs2sWGVk1
gAZciQs0KMgvd0CDgrRwBzRYZL5BA9QpiaABPCAjaGB0AA2sJYAG/hkHDeZsETQwnjDJ
wZIjBzR4UBWibQfB8uboILhJqVAkXWUqTPKYI307CBbmjjkqVEEcVVChCtL4XCpUYT7l
o0KVZ14Ogov+5iBYUB42qFBrdMdBkMRRofyZkvwyCZOpUAV1do8KVd4nOghuUlKZpLMX
sxC3Q+bbQbAgLjGoUIUxzUeFKgicvFSo8vZvDoL8zNaZCtLLPpEMDoIF6WiCCqX1MhWK
xB5h3g6CXP6tQrFH1+1zyXlr2CU/UcPepLEHyM0O+bk0bFbmuNgjzUvDLsCwI3uk+U3D
LmlcGnYBYhjZA5G4N3sg63tkj1SPhk0isIc9E3sg/fBmj1Sjhl1Sjxr2Jo09QshcAXoe
yPzcGnZBHFhkj5wvDbugcufNHnAHu9kj56Bhl5yiho0fCOyB4gyRPbhezh752Rq2r6v+
zkHDZo++adglz6hhM2//0bBZKSIFMt0adoFaFjRslDPYGjaJo46RPBq2XjXlaX3NpWEX
lkrcGraTP52c3zTsq6Wq+si4NOwiyMm7MqKGXQyd8iNZQJb0mdKihl3gvBU07DUhl4Zd
ynNp2MVSMZmGXSwVk2nYBdmXooZd8rg07ML8S65hl1y/adgll1vDvhtYYqdcGvaiLw2b
FVIuDXv91qVho+TJ1rBJhCXNLWrYetU07EIk+mjYrGJyNGwn95K+3zTsq0VMkuelYXM2
T1fi9WCBCNk+ANKGSlPlA2oHALSY5JsyFr5eSF5urhUiqVY11w7Q0OQH87LjBSAYDn8k
NlJ2/mylkvBJppuHuwjDcwt3LH1bE68/RRhaVNm5bKWSGJmnfPRJGwurQk/uKa18WN8d
Y1DWaar6RxGvSjmwyT6sVJI3NAPwUZGDtQW0keXd432lLkyUvsAtiE5RSODAYg+qiAL4
G6thtIk7HDD+hslLG/Emu1eqtwZqqaZtYQKUhIauPJiAPHepJKCN3sPffrgDMUsiJJ4o
rLVSrfiPk21aqSRvGNN93pjXmeA5ndKqpb4PUY4qROCal/UYJp9SDvFCHKmigaqYL1H9
RvKUG11VpOmFg6/oinc7dLWUQ7tl7SP6GCSV6BpySqOHNomvjTCSDPJltMdSDsFRlbmr
i1yNcGHArNhZ8LULlPFmSznkEsVagkgZr1y0D62iXJuGV1aUKEhCQ7fhon086MtgEmVk
P5v1c2bzqCB8QUamI33Hy0wVm1RJssPTvSknGyxAZqXO5nmQjQhncT9uiKVXVTZ1cuab
M8f72nNmNx7J3MN8Te2b5X9vQ/jjkZLDbRJVGxjRJsHcyGZicYSCJFWCxF1FQOQaXcyk
BvjsO/k0SzlkDUDx6GPyFCWRb3RsRMYy/s0djZIj9oT+FetT3bF2zWyyawtveG1rIZGR
j6GqTLuN3zfKIMhzgRtLxvQb3FgtKYAbTOx9wI1F5gvcWOzQIrhRmW3FwI1qyWxM7aiW
zMbADb1q4AYTe0dwAyFgEdyYsiWcoSbKEB2ZigivCG6UmXoEN8p8ioMb/PuAG/ZI0EVB
4FcAN8rchel2S6oR3CjT6r4ZuOH0ATfOGwI3CqqABnCDdAQ3VsMTwQ28IHCDfx1wwx4I
vZjljeAGcy4FcAOp0QO4MclTAjemBX8YuDEVSG/gRoFbWAA3mJU7gBtM2n2BG6slRXCD
GecDuOH0ATfOG9rV830DuHHmx2lUXTvgBjI6RXADGXtucAPplwK4QbgmfP0cF7jBnPMB
3KjMdrXBDd8yF7gxlSfAwY2pmHwJErBqBDewEje4gRxCAdxAOqAAbszSLnCDqdcDuLFW
pEVww+kDbnjLATf2ZwzcYKL8CG7MmEiAqc8vcGMx4OPW67L7erBeNynrjqRbqxXp7IL1
Wh8rG+bW62pI0XqtAFOD9VqRt+iyXpcYbNF6rYCugvW6lLB+W68sbRCs10Wnbb2SONar
P5vKJ53Ttl4rMKtjvSLLebBeNymFmORmrzqD9VqRTzpar5VozLFeKyPejvVakfH5sl6Z
LfuyXvmZba7WV9nBnHzs54waKVqvWi+zXknsEfbu1iuXf1uv7FGIflQ3YerfJwuyGYWT
BcmMwskCt6DrZEGKrniyJJ3OOlmSKSd2siRTTuxk4at+siAzVzhZlEn7nCwVdTzPyVKR
OO2cLBU5ueLJUoEUhZOlvrn6ycK/z8lij3RuMMd7OFkqUlZdJ0tF/qlwslQgVOFkcfqc
LOcNnSwVafHCyUI6nizKw35OFrygk4V/nZPFHvDoWFp4CidLRbWmcLIwafo5WZCI3E8W
/n1OFpLnZKnIkxVOlopKxOFkqcjDdZ0sFdhoOFmY0D6cLE6fk+W8ob2FIM9zspz5cRpa
xT5ZKkI8w8nCHOvXyVLheHlOlkW2cLJU+LJdJ0uysHM/WZDFLpwstmXiycI5OyeLZtdO
FrJqOFm4EtfJUuGueE6Wigpr52SpCGmNJ0tF1sFwstRXOZz9ZHH6nCzeck6W/Rk7WSqQ
13CyGE+46AAGeFygFOBXASdcAX6VWbFigN/Vwo1UAaBcAX4V0ZUhwG/RLQb4LXreAX41
tx4D/JYezagp+riROBALyeM5pVctDqWiGm0I8KvZKw1o1EYaxFKBVV0BflcLA/yYyzwE
+C26f5yuOIDAAD+SMcCPqc+vAD/mDw8BfqvDdYfhkfjaAX72TOF7/GAI8POv/vpxWuYT
AvwWOcI3CxmxAD975l2Sz9H3Th9eIRa3QVJhuBWir+Sti8Af8HVDFaRHELl6AElYLH6c
4p9pMD6ScClSaRxStRRMeWADazcKnEE+6ldmO76+I5n2+5rbZ0G8G9Phy/EMi/Mi0/pk
5slDj2HRWrulMWkGBGpmknwLF4DEK6ZyyJvNniE4TtUFeOAMFWZB9q8Tc/UwUf/rewbO
LWhR1j6iFm/l8D48CQoJilJJJz0rVBqq6jQ7WSCft2BUsQKGmgJyfED3x5zxqOxUqHfV
IDwqeKv33QKYVFSgVHlFy++sghe7nQVqUCw2txAvM/9qy7S6iea/ub6GMSYJOePJUha/
cej+afiCNeCmg+O2L2gW0MaH/bW6ifjFaePecEVFHrV6Dh9kDMsBvXDu4qw0pju3cDvW
ZChCwhHb1O0Zoy6Rnj9Z1OrQur7505PFdM0elEpxufzruAIEBZEdn0xWhWH2LuJr+9PZ
M6VaWR+UtbHpYWnSdgt0ZXfNnejqqwSPZ4vWXTeR80YvxfJNX0RK51tfRALpoC8iYXbQ
F5Hh+dIXu1X4cH2x8+QyfbGbM7Lpi93OLNMXu1yXpS+iGGPUF3upl77YLUum6YMdP3f0
RQTiXfpi6/XSFxt/S/pis16ZwqdHpg0iRjPqiwiGvPVFloAN+iJCGKO+aHTQF/cbpi8i
ODLqi6AvfRFVaaO+2Cztm/4K+qIeSCFE6GDQF/vzXvpih/1y9MXOOFHpi908201fBBn0
xdbbpS8iljPqiwiUvfVFhmwGfRHbNOqLRgd9cb+hHYoo1aAv7vlxeuaoLyKvXdQXEf17
64s99agvdgN5nSzt1heRUT3qi4RRj75oW+bSFzu1qa0vdoWJSl8Eq0Z9sQsfDvoictsF
fRGelEFfbLPc+iJy60V9EeG5UV80OuiL1hL0Rf+M64uMdQ36onjCRUfv7S9iM5aIzHds
Rh1jhNiMCiz/xGYsfhlXbAYLEITYjDoeSwMAg3iYEaNIA3vG2Iv1uRZiMyqCRGNsRh1I
9nRiMyqyxIXYjEr/xBibUVnCMsZmVNw7hNiMihKWITbDh/r147TMFmMzfHo8NsNp271M
SW1vmMjCT5zYjDWscsVmrJUbMTaD1RlCbMb3GUMh0RCbUVEl1WMzSFCpNhalDiDuH55+
yEjdaJ/dMeoMsRlrolKMzagM8o2xGWtiUojNqKzcuWMz1iREyGu+4y8YraHQ0MVoSJsf
GK0BLT+M1p7nuRkN2dIjo03mTjBGm3I68WnTMzES3L0Co81ZLkZjUvXAaI3+UYfRGmD7
i9EaXMIuRlstPTIak/4HRvOhHkZbLSMymk+PM5rTh9H2G2Ik/kRgNHhYXYwGR7rIaMiX
Fxnt+4zlcjHa5NFijDYtq6QxGp8ZI6GKQGA05MeLjLZm8w2M1uBJGRitoRjqxWjt8Ryu
ZLT2CMgwRmtPfQ6jMf31ub5UGFNDTOSVOqwhMPFKHdZemAsndRiShH94Gi8SXzKC+PdP
/1sh+0rd8I2E8tYIIVVhnol5z/uHxwGToDB/lIa8mUOX/WajSUrOR/qskDqsMTt5TB3W
4MN1UoexJyd1WGNe+5A6rLGq3U4d1gBAeuowEnuw77MH+7QUUofdJKcQ2GtIHdYU9i3d
p1nYtyWjIPnzh0cL6VXnjzlC6rCGROcxdVh7DYF0BkLtiZA6rAH4ulKHrekaV+qwu2Ew
Af28U4c1BKKe1GGHPZSWylnqMF5Kp8iXoSoNBXOuPJsN1VlCns2WdF8d6HLn2WyoZRjy
bC66HhGRSvVd+Bh5PI/0qkWf8XtCns2GoM2dZ9Oon07NefJsRopefY0Zzk6ezUWnD89g
RiIINZCUilSi9aoSrTT4nZ08m+140u2GFvJsWjc8z+ZinHzn2WzuOGZZNFuWlAx0vfNs
rrXMMc/mokfIs+mkwRX6wAh5NltWXzb5PleezYb8XCHP5hpxj3k2fa4s5ZfPleF2i3zu
PJstWYEsu13hmoY8m85vhylzCtWpzTRcLP/tKqEBIjmmYcNd0zENW6n3VUKDf0MwDRth
EzMNm0MqMg1JHtNQr5pp2BBgGUzDxpjWYxo2RsVu07CVN14lNEbqBtOw5XZdJbTsLhJV
fx/T0B7J8Fsb5LpKWPS3q4QG/DGYhg3RtME0dPqYhucNmYYt9+sqgXQ0DVfDdZWAF2Qa
8q9jGtoD2n5rP8arhIbo2mAatvLGq4RF7qsE/n1MQ5LHNGy5XVcJjS5uxzRsrEkQTcOW
y3WVsCTDdZXg9DENzxsS6gCXj2l45sfpEa8SGuDbYBqi/7dpuM6GeJXQ4Jh4TMMGN6Bo
GjYAYsE0bECujmnoWyaahpyzYxpqdk0dIqsG05ArcZmGjXHl2zRsiG8/pmFjWHowDdd8
XFcJjcj6MQ2dPqahtxzTcH/GTMMGJ8xgGhpPuOgobd6X1K1KV9ffYhi7pN6kLqlJ+qV0
44VCjnS/LqkbQd9zSd2Im51L6sZaAPGSupU54iV1Q/xouKRuiLS+Lqkb6xecS+pFlyNG
QXztS2p/xkvqxvx6dkndSq/hknp1I4VL6k2aGlJOhpzGjh1mZ+axcEndcJ6HS+pWy4iX
1Gvq531J3RhwHS+p+Zl9K914/gYy2+YTlUq8pNZ62SU1CR+hrav+rulcUrNH5/bApACg
quh52oBGHM/Thpxkx/O0Ya9Gz9NG178P9zxtSLEfPE8bzLzL83S1pOh52gDvuucpieN5
ujo3Ls/T1ujA5Z6nDXnFgucp+355njZghsfztAEOO56nDesePU8b9urxPG3YmMHz1Ptq
CgykBmyr4HnacBMRPE+dDoqtv+FsNJ/gedrgWRr9+xohve152pAX7XietuaBjeZ56j08
nqetCrIyz9IGZf4NZCqX5+la4BI9T9fvv9vztCFlWsQIGpDNY7rBaWnNQZcf1m+hJfMu
gVcd4AFUEWQQbmZKfae/fuzdtN8oFIDnG5xGAqBdk4ItVT7A+xuW7FJmBfsN0Xbhwl74
G95L/4Z7HGG0SEr374tgh56JrBs4BHH/+w+//Yf/8bcHqsPFbR3276Mkur+FlqScr7NT
C34BhwxmxSKC7PTXj4wc5mvPeEt+eH/1IoX6Uw5ZaRvgfWtQwW1+fE3a+0zleaTX4tz0
mm7m5k/hDe8i6qRF2hMD//HHmq3Vx/dhSOTfNN+hDNZ//uW//Prn3//06y9//vjzL79/
/Ou//Pz1679//Ms/f/w/SCXwb7/86dd/+vWXf/z49c9/87pkDHWqGI1GsFroO/0iT8Ls
yhHGkj6VF2T5UWnuF0pN0jw/vO9786CJv2Sgr115FMuIEL+OOjyv8i+xRADLJFWTIchw
hheyylTPllQHiNMO+TJF4NWcrSZQUtq7VlXoaTLxHe/KWSBIdbzGpIP6C62pKiHh6ipS
rm2iWXEVkanzxu4nSPogXC10vXthPTKn3aOCD9kyJLLcQ2Zi5/w0pqMm+RPz+rLwDcgM
vzGUssD3IH7Rl8F+6cv4av+wSKQXSvouvR4aWJjlzQifRho8/zGkJIAfHspwZJqbGWUe
UVMmM1CdZN6lwPynoNLWdkixB09oVPNI9nXYx4//dOZ8qBOQ/CLgOsVlI4Vjsio/IYpc
MbldoXpCAu9B62v+DEW2UUjpESqHaOX0sqTZp70+GTPAwmZVnFYwuCZAdK7T5/Wh+3bF
zW838ZifSmflF7KU51F+ULBCtZUy8wsCJXtxVY94fSeRhLtxPq2hMFsCP8ySUqzUkeny
iPpOyY6BjMKwiduT65AZ+40aPy+zoObnLSJ4fomE/Sv1AgPKKhCUtJHAfzAb5pQQHdZ3
qRe+k1BfCurFrKp4ZfW/nazV1AtvyAKl4e5aVfBLuQaZRt37ivcHXaxfwAxIWYHqIKyP
NpTuAPAqa5aJxoD60Ja1N+D/mPaIN6mCx9wJaujKXvFgIBgxL6wzZTEmqLl6AY7ePQSD
dv7OC+AH6gVi4lnDTEmqnCzN1AtvaMoVOnUftX5fmSP07X24eiGWgq241Qs45L6986If
HcDqGvnTSQ3vkEmZP5FFF6Wo+qdJQUiJ7vV/JsI9UOEoFQtJgTN9SipY1fZy4nIT9p+R
yJUii8UbLNM93K/RV9ykIkUWEkSimpLRPHOHKoX5GzpTkaSYZ2pldsOX6qxW1/jdfmIJ
n1fVqlpWRs7GeXiRu/fVfuiEelnZC/mMkLEB+wPoKXIdIFq7bxIfmEllwfyFyfBKfgEy
ZrwPs+TxJ5nVN7+KUXthEyDjGYv5siQViPJqDFnsVodKevEZq5HJFc0IJNvge6A6kpNm
JMFkVPaLFDlM6ljpE/Z21QXD66oO8bLsNDqZeegsvsAWYKlm/s3xDRa64SOMPrP4FYtg
U9qQBfIrKy/DKbhgvuZDlHWf0PA5wGgfRa29sDAavhJComyaRxWTMZ03KkOyXtziv1Op
U8GmyJc89KPIUj00HRRatbD4E4w0CjWn5yO3G7awV7NLMOBshFb+jk3kT+MhUC4eK3Xg
F9fxHfIXheF9i+DlnDRbhcB+Rr0cFBLqPAcfbAv+/SW1hNWwKrOsssTaIl4pd9y0hrpj
U/NQavBrwaHwqhTyC7cM5CBANVVUNcNWy4FMJrOMrLw0Xgv8cgm6uE8KjAKJMm9Tpj/j
0DNNUiM0ReTMqpprZEbczrEeHl5kmCP/xnuJsaf2CMZcExOzn3FcNBhwQdlVJK5LXu6i
cZRBPAxt2Juc1a58rAGuNFmZaaHArdVTQhNW0+Zqwmaz85rF91Cso58V4tLhHmOK4Mqy
PoE9K92+pTsBxUUvssTg4BVBfuTIsfuPCM49vCOwkSfJb1QgFRvrrBnswHM0sU7aNC88
iMrnWwtZn7XV5MuKFihafVYTr83eYJjpphEYJrxyt7xCy1AODLMz3qyuQ3QOl5MPFbXx
Sm+bPABJboVw6HKMIuRlabdhUtYGPeTLKhJBkY9Ehr0fWxrl9MCtI7ar/1yB+updkd8b
yq7XIZIq4pAl8DLGj76suwUWQFNacH79Qy364YYYAlQQpVSGP3v7/iB8WTetr8br3oKb
O7zwcKEG1T//ZjErf9Wf7S6pGvj3Th9WgbOCo1HZipKzjpt8WVHA7KWzgJ3IINfpJ19W
ZI+BQgqtQr6sUKm66sk1nfFJFK4lN5kMAtgNlgm60TmXZdIG1TlizS9Szsh7wTUCs5q4
OCzDVlSod9P5NV/W3fIQBsfIcOIMINzgQRTSG8OUUSamJMmdhrmdLF5MwYxloxlkIp86
8vrpoj2zWoZmQzsuIzfNy+J6PJespJ0dSpOZeewZrDh87tEhYGQu8mXdDUkJKGEPsRre
qxyLjwrFryF2+bJSy0ClTnDIgGKDOwHsvElcjccVy0Fm+bLuhjHkuZpRRyyNv9oyk3xZ
86sA6NVCGDCj9llhycmmBMRGoxd2cHhDNm1YX2AdF0PCApu2q4tq4KEw49adEcSol420
lJO7QdzFWWHNPSoWrapEoq1dYd4se5Zxo/1OIdQZUXVc19rky5oRWVqtkiN9FDL8MErW
CjxmiBUy2ZDZApVr2obvhLHsGa4LuXTCZzedk1npuwWHa5HRM7mj6Opwtqg24dnIhCXK
Fvoortenb2FUuuP2FKKwSVVlIUlRw0KAxXCNTRfdOswkf1QqKfiAzIKEjPCTefubyv6p
WhY+UYoKAyZ525i8SEh732mePCoM+DTX4bV6CYmUcOsAm4GFATnNTRXIH5ONraswoJ7J
S5UuMhQ9U/Uhdesgkpg8mYHV/IyUxk3SmCgRt2uHLN30UW9o1DR4tPCrepVBIO00PcMS
bVE/BXgARTbpbLM6HfgMd+/kN/bHkvpP+wGpv6IqBfAiBY1ivTL8dVgYUF4PGqGta7Pl
/+nswR7tWwc771mNUF4WdronAmJmGHJuJ5XmQE/zsvCWV3kGdLqvn6VDjJ3uSQ4xLvyS
fGI448j7AZJoETzfXyVo9dM6cf/64W6Une0JFkm1o/2ilBwHSifNi6m6aC8yOwK7gEfB
mw3XkwP+mw3UUyj0m60iAT5WHxmaTk5na2tor80NbzzVjQRXMbTCUebZKAJH35V+Dynj
sPlfCx3f9HjMy+K0jE+p86o6wzT5WadY26RtG37AX6jq4ZAfiJO9mpeFN6DmZ9tiaA1R
xRvQY3CB5opnaGpnrnS+JWTDasZvvDlNMPXaOBv1VTSHY8/Ob1toJYSFbS8L/17EY16a
6nrtm6Z6tagk2tq/t6a6Wi5NlVUkg6bKKoiXpprgiRQ01UUfTZXE0VRJHk2VpGuq65sv
TZUlGY+m6qRzM6ogXprq1cJTKCF7fdBUF300VRJHUyUZNdUE16hLU129vTTV1eGjqZI4
mqo9kx7KDwZN1b/6aKpr9aKmut5/wzfXqKnq2e5SuTTV883OK8gOdjTValkYHAkzYDPl
2QOwmTJy5/VDtnwBmwlp1w+wmfLSGwOwyTKPF7CZ4AoVgE2WFnRgk8QBNhMy8UdgM5Vn
BmAz4QYhAJvs+wVsJkDKB9hERccAbCaGEQZgc43mCcDm6n2NwKb39QCbCTnaArCJqpkR
2HT6AJv7DTsIbcSbXFs3ApsJnhIH2FwjLgHYTLi2iMCm9/AAm6ieGYDNBDeyN5ClX8Bm
gqdGADYTkHMHNhOS6kdgU0Ud22380K/oGD/M03WMH97nXsYPXRaj8UMnvG38kDrGj2KT
gvHj1QLd+JEL6DF+6HdxGT8JmcyC8bPoFI0fL8F4jB86kBzjB/Ult/FD4hg/JM34Ydxl
MH4S0vlfxg/v6y/jh54hwfjB8LbxQ+IYP/aMxo0c17bxs8bQLuMnwYEkGD+suhiMn2Q3
eMf4SQixC8YPykMG4ychSi8aP6y6eZk6f7Wl3MYPMxYF42fRIxo/7EU0fhKiI4Px4x03
hmztNn447qOXwl3nGD9r+p/L+HHucuOHlRTd+CFxjB97RuNHZayO8UMvhMv4Wf3It/Hj
dS/d+EG6pm38kDjGjz0zLYMRgCnQo9zGj7vZu/FDv8Rg/PgmPBsZFypu/Oy3+o7I5c7t
OyLXyPptI/cdkWsbuSsi1zZqt4hcJ3dE7m4Y10buFpHrG7nviFzfyN0icn2bNovI3fSO
yN0tisj1jdxYE8s2ctPdqm/kpvXkRm6KyN0buXlE7t7I3SNy90buisjdG7kTyraN3N8R
N7KeaaP2p8eN3DwidzcoIndv5KaI3L2Rm0fk7o3cFJG7N3JTRK7v2+YRubvB42/3tv1r
LfPbRm6KyN37tCkiN9D93shNEbnnC1o5G7l5RO7eyI0Rub5R25hxIzePyPUG4669kTvF
sm3kbiLbNrKeaSN3ReTujdw9Indv5OYRuXsjN4vI9Y3cWj0buSmgxDeyntk2bRaRu+kd
kest3SJyfSN3ReSGLVrvjdxDRO5W8qASXkreaDMqeUNlNjaZ663kjbdFJW/IJX0reX3m
b0oeks5HJQ+53reS10eNSt4Y+VbyhiqYuJKHdH5RyUPfbyUPOfiCkjdKjUreSONW8pBT
Pyh5ffZLybO+BiWvyxt+K3mofhmVPKODkudvODOOGpW8kd5byUO4YVDyhvJMuZKH0giX
kmc9DEoe7h2CkjeU2m+T77yVvKEkuVvJQ82HreSN+t5KHuDIc3vN+oxKkqW/5fviwJiT
BoxN/seAMKBZERhDjv4LGAMKHYExYJMRGJvwVb2AsZnKBYzBaorAGPxPbmAMOc0iMDbp
nGP29lTVdQfG7JmAMdhgGxibzxuBsTXcCIw5acAYSF9qpLMLwBjcWy5gjEhAAMaQkz8C
Y+DJGxiDrX0DY5PeLo59IUvZE8kUgDFA5hEYm5R9BozNOEJb12bLf4AxojMHGCN0wDvj
ISbp5sTUCc4H2qDfTVeL1dstQ4VtweT0NeMundVKeU5dj5b9DGdRY9E/khmRa7zzwzbG
CjTvWzNgrCenfhqF76MrU0YGHZT1vFswVy+UJ2xugTb55R2u6uWQOF4IJA2myEjvfiDS
ZakV1XE0EnrvYYQM6Ol9N0aBaow4lVhhkQQFVFHVO2JElG6sa0jQxshmrkK7oZQNWeEk
gauBUHfexdsAHLKyATi0tEjGz/7cwpcACz00m+rpYLbFuK+OAHGCXSarNAu+FKwBfh0i
xejojgpcO1ks+mE3QHMjqDR1d867pswi9yS4M14r2DjUv2Sfew9ZpuJud8NajfTqCKw2
DTrwXp8TY/ic6DF+ILdhxUclEkkj0Toln6ywnDhTSGA7RbCXdLTQM1t0fI49F4l86KUF
psgyn6jJodpo5j6RFw6JL80q9nvu2+UnI8dSPjyi7mpJeEO/Wh6rbusNqUve4C6/4xuw
y5T9lwRHoBsfPZsqs5fpb7LJx7ja6DRVpwvihxUnh8o4WDrBjPg+OUlACEGdRA77REOL
Qc2YIuoREBYkbB+gI4nHvgaQ4JT4fnwb4FnFPMIqmrtYVrGE32ILpdTPH+7MmZkhO+sc
YYm+57HjwelkARa7BQYFXiAQg3qJOAaSaviZuOhMI0XyHBwkHcFkWcp68H12tm9M1EkX
NohgYQ2D/X5sIcqaGUzXhIn2VzUN3UKxAodUHYc9+ykShYsK3FKshQEvuSg9fRqSPxz1
SydaRub63J4FKLGQgssXOkZG6Bp1DG/o+mqRfxESJF3QdQb8EaDrDEM/QNcsA3dB1xlx
MgG6zpUorQms+pQAXZM80DXJPakIDArQNUsvHujaSV8muFZe0PXVooWvEonn53I4Fmre
9i1rK+b3gq5zfesNXWfiYQe6XlMxN8BM4kDX9uzt+4MBuvavPtA160Ie6Hp1Jp1vrvKi
N+haz3aXABzMj++dPryC0pEBupb5Acu4mlUjQUSPNBX9hrBp8rvbZDEgcDe83RzY5FFV
qUkoEICE3SQ5SZ1xqAJgmYcsj+Vw8IalQVNxWZoXCrkCPZh2s4VNj1w0dsoOge3wd1QO
B9xCY32bX5Dqmm3RvK85tIZ6LuIy3O9KPzxr00NXtnamiywvL7X9hk4F/AQ1YyMR4Rs1
B8T0FMNvXhZCfLZtWv/KjA1uuYyADNZypLaFAgFVhN1rYlR8ZmccQq7yIRH1brqeNZQu
XzVOWQaK8NLP81Wv+qscDlxl3PMCONCW4UnQhltXBAbbjGc7HPYuWycjxcy7/QAy8qMr
CwMUqPLXGpJABtaKQkG9rEsmKERYUaNPREl4gw6UGUlsZPFKmIF+dIrKwMhdfig/z9GH
JFqvCUWpy70qFY4uWzMyEEmxopnrNLnWKiH6G43emRlGLM0AjQsJe5Q2nRNh5E8n38dJ
ONa+d4uqTdNBL8migmrbdXuwGQhZlg6qBs2wN2JIPwVNTXaKCTl+7giK1TKFQ9KIAYzR
Oz0F/ZqcVQ9TOiLa6C9hV2A9fwMJHzi2ShkOz0loKQAAZKSpQkKGny6+6WUdyyq/QyPc
79BIRhzQIZPlHpfeWfluZjk0JIoyL+TyWhXORxXdC30lWUcTTLHpZPGYoYV31/hBDf+V
ny6SUbBG4OuevLhhx3ftN6ByAULCgSciT8fRSDZCg3AuJZ6BRX9pszAAPgP5Kdr1djjD
I1ClgWlETxWU5NFrXDDgyS2uYpVA7a+zBUdr39TrIhT2qNfG9Fu9nvQMN/UaRFCv+cxE
Bz531OsCr5qoXhdsr6Bel0cHAtVrEke9Jrn7B9WqftzdDep1eZR24LfTgCjbo16vbxhb
vSZx1Gt7Nq1+Ww7qdXlYZmCr1wUJzoN6XRjNE9TrqVSWQb1Gvb6oXk8CxaZeT/emkIwB
6fo07a+tXvsA9yoWzaiDAjTAC/ycX82CUoWxntlTJfmsWliKpIfKe0OyACHBXqio9iEP
ZSO+fribCsmjSpN0AcDv4WEqnYsd6911NCd/Otnpt3J0tKvFvlGCijoa6nG81NThdZJF
fMlFpoo6mirriTGorbPa04vYzHTISa3064c3IFMwpwj38uvbBAsoSqsIFqD9iwIH6a0e
WwYe06vWYeY7TmEKZlHUoo1ZpE9BagzXDVMQW6imllRYrc5DAhfN6AJ6FJGgrsIsIiR/
/nDBT9I3T3LD08inWP1ta0Aq52LobXptLd4Pd/FR/bcSIAxvOShGgTjLxS+qUM4Mgr0Z
dzuHiNOeT2eJN/J3uqQUKhEl3o7+9sMlm7f8NL2wowIQHZT8AFx0MfbXPBht4jS38IZJ
HSQBfQPTV95amGaAmm24/XY0nT4whdljq2sGqMtS5G/1FyThMiOpF6iX/twGUQQU7WEW
6ZumFzj508n87Emw90OLJhvG5NCssMCXQv7ciQpVzHxW5GRWmCD3gzG6/Lzp785dpZqP
nYeu8Dez1CWVlkAGFyVdMnezQr+XD/NFYx2s1rYkMtKg4dLDCz4G89DZo0Tsz5kUUj4n
uWaZ6vvt2FJUiAv63P/b2tXk6JLjxn2fok7wkPpXrnwEY45gPNgYA/U8DcP3hxURpER9
Pavu2RWVmV8plZREkUHG1/l3XYGU3f9h9X78VFhx3n63s7ESGZKUegJqiSoXe5CziH1C
i6GEi/jb5HP3ZFQbQgZtaF2Rts0BoPQf8NMXWzSaWN9eRgn1P8AH9SS5TrdczLI9LU3m
D1jlIbJIFtew8UYGLPNXLlVgNtL3+TRNSWVn1nWP99i8JPv6/jYmboc2ebyYvcq5zRTR
2rM5szUtUVS4DRnTYApbB74cxF6Mws8bUJ2VCaqVFH6dr6RXo3B8CxQPxNNuVQ5bxRGP
iXW2CPfeReGnjpvoKgDL8Slx0Y4t+qojyTDwbXJwj7CuDNtOFPik+L1PLRR9UWb0e24R
cc24ZjO9yNDb+C84WjLcgqzZotGlr4leMIrH10SWsqGGyW2fRToQtnpp71fUvEZU60Uq
IDnHROFnrqfVokRo9+rdDQ+fyTrRb9n8t1tuvgR5i9LwFGAqJDOD44OHdArxkz7JP+kQ
75mi91RG2VH7E+HULIWQLkr0T4pQ/XPtw7HFlKQkOeLtk3YmSHlXcojsVRRAzu5VUYCp
zvGqRJeHk1aLfH4En0J8yGXvYrfSkLuhTQspMbtiyYwCiPtyGjLBdH8226pY24Lintgo
VlrMMCLnV7WSvQKXVJw06lFBhHn7McmR6zRC1JekXQxQDmb01cH/JZNsqII5rGMsGIM9
1kIECi8eRY/8/jDnhbeMYdnk9vhUbUvfrUw+6ejnjski6hXHTx6MJ+OblC3Ao+V+TJHp
MNbXeAP3b/1lLp2yL3SaijicPW2Lk7l0hi3ggKUfBoUml1Mh+uj98epvviA9NxShYDhs
sDOPgmwl6X1hODAJj7ZKHTINf278QR3KP2K6L3tZSdfggRqXf55lz++wgxn8AG87oo3P
lpFeLsRMJZPao0VtZlH2ledH3hAa3lFI9OfPz0KOsS22R+eO3YCw4lTuMLUYlsqXo3d8
yihArwxmjtkvnUKbja57u6iq9EBNJl3xS3i6QhXdHTbzKkAAGegs23UaeZ6hwHeD4O76
B1CKwSJV5dHO5zINIhYm9BZ8VQQue3imMJxch04eBcVkU3Gd8JVjzuf2k9VXdf30d34D
JmCLwgRQdAwASckCJoB0bxETUBHhD5iAishJwARU3HdhAur7zIgJqPOtERNQLWJxMAHk
0wuYgCXXL8cEUDiYAL9GTACEjQmo2L5OxBzkaQETsEVbld/n+CFewZy3WJ4LE1CtBoZj
AsiTFjABYoSLmIBqL3IwAXxmgwDIKfcE0axlk0qNmAB+L8cEUNhvaN+12+c/JhQxByOo
R8sPt3zTEHIvRQs4Nqj8OdI/GI+RG6kh+aPYWWnOLf/cJ+lzh9zsZDui/3IWceCMpOpM
jPlX0jq9uOO4URvMUMW1zI3aYMrS0SEnRoNh6ikZfYvmRgXv2L7BX8RoqPabpulAB16W
aGcDkqA9249a7wYehcmcRrdpZ9SFzGrc8IGrg4zIZvXVFJQRyPl2f0U1vqWqTVyH9waq
eX5mhdUb6g1lc43VzcgkHIsxCqGIdBSzsnVCi6/ZPFAs2coFyB1BUig7NypC0dLMHmz1
sXy1R/lQvnTT7qE0pdrLElmctkGjzacB0x/Bbw2o/gN+a6jVesBv69CeLvBby7ThHfxG
nqMAfiP52QV+a0jECOC3JacNfqNwwG8NdOUR/LYaRgC/LbFE8Bv7foHfVvd7AL81sMgf
8FvLs17gt4Zw+gG/kcktgN+8rwf81nLuEfy2hnhG8JvLB/y279Dq5W+8xTEu8FsjRGCD
3xoABAf8RoKlCH7zHh7wW4Pj6YDf1iv1AH5b/69d4LcGCEIAv63/nzf4bQnjAr+ReSqW
bhETUqt32l8rRl1p2KVWdmqby+1O+2tIRQlpf01wDTlPmqAcHouneM6ETagPm8n4nZD2
14rRhXr3y0n7azjD77S/KNFJ1yq8+iftb8nly/2pFE60keJJ+6NokaYGQvuT9tcADIhp
f6thhLQ/64b7YZZY77S/hoqpIe2vwV0U0v4a/EVX2h8ph0LaX/OqwrZmm3jS/s4NmiTI
OThpfw2cVzHtb73BjGl/641nTPuzsXIH5B4reR+XmO60v4baaCHtj980pP25vh2tZD7K
R9pfY9Q8YidA/3NjJ64WEaUBFnJhJ0iGFLAT5A0K2AlSEl3YiQa0RcBOgFno6HKdbzgM
UzzYCYrulG4oshqwE+RoOtgJF12bm2p4nsPw1aJ9DRVgA3ZiyX0fhikc7ATFiJ1ogHJc
2AnSYwXsxOowMabcfykc7IRdEzKCDwbshP/0wU40Vn39cuwEqJfOL0M42AldO518I3bi
/PLf9zDND1usi5BAfz9MADvWemyRr8NbMsod4F+A2QsG9Zazk+/sFpHREToM/gZw3zG1
Q96SRgeQRktuS/SJ+HgMRyKDUtKU2vJwkIW3AN3BEYNvtfVhoNWHPi6X2SlRNNkNPlBw
SvUc5OKkQ7sFRQGLQZpAh/RYdqvKLTSUgM1aqpDmuBqm7aaqTt/gZ1KpyJfCNvrA+ub+
3n8iTgtwE7a9RYWWKO4Z0wbdpmcGtKrSO/btm9fWoIhXHGlvAFHUDoAyd7VqupBmSnhZ
9aMbjpT8UoZW6aZO2/RvSC75w9IELMC9NPX+Aeu6WrQ09f4B62rwcMalCd80Lk0oanUv
TSg0G5emPg+si0JYmiCGpanPA+si4VZcmojhOUuTiT7Qo3zAuq4WLU3ILIlL0whoXwph
aRrphnU15LvcSxNhLWFpIo+XLyDG8eVLk67ZwoMH49JkPx2WJtZSOkvTSAfWRSEsTbzm
XcJzcWnav+y6Mmr5Q0Zyg7vxstfJDnTsdaR3BHsdcJvLXp9PTFZp9IIFex2+o9teh/8u
2uvwZ217HUKw18HqdNnrIH4K9jp5oYK9jr7f9vpsMVmlIdcm2Osz3ckqDdWggr0OT0+0
162vwV4HZCPa60CgRHvd5GCv+x1mj9sbuzjTnazS4HcN9jrgGsFehy/ssteth8Fehyc2
2Ovjjckq5Iq67HWgn6K9PstJVlmduZNVGlw5OyPZegxMXTaX9sty3k8tls+2lOZDZBl3
wCHo/ZqMrHcgzN8UZUL6TOvYkqswBfLYL9mSC+qQcMC0FE+AowNyqIKN5prqCOjPA6Zt
UDY4ry2i0V4ZiD93SMNbwq79qlhFkIc0zeWpqkKn4RWlAyo9ZcpthzQoaPHXv3s9EVR0
TlMRXOksgqbp6DQj9W/Qabj0lHhJ1WrzNQBKMeF4snTNv6NcJVts5dZMuPanOTHIOVUF
A9M3tVdgbDJXf4W/n+X/ZfjesyQpusuWY0OXslIqGxzlVXatHGwNXiauGnSi+ehvse/6
lNZQFBmFv3iQxQrPIptJf5tbpEgymM16ajAV1sXOxPWfv+0Gn1qDbgX7hKq3bO9vE2Xp
/A2zAu1L8goRvk07e9PZpq+WIbaoUu9terXMuE07OVWQ271N99RK3KaXfE7DFM42TfFs
0xR9m+4swHK26Q4E39mmXbRtugNMc23TVwu3aZIxhW16yeXrdGXug16bEuM23ZOK5P8K
LW3GbRrkWXszpXC2abumTbgbiuXIuyL/bkHa4N6mV2dq+GVZ27ZN69rukqIGn50+qpJT
C9u0Mk9JaXSSw5dYQ3I4CZCu5HAyFMXk8A5Xy04Op3SSw3t52pUc3pEKE5LDO/I5QnI4
+Y6u5PCOQhshObwj1SQkh/fsVWlPS31DcnjPJX15cjiFkxxO0ZLDOzxSITm8w8V2JYeT
fOlKDu+sG3KSw/F6X+7uoXCSw+0ak7/XcyUkh5MOKyaHd8CSQnJ4hzMsJIcv+bmTwzu8
lSE5vGeVQLFc8PWi/UoOx5vfqeD/tKXdyeGrZcbk8CW/MTmcvYjJ4auhx+Rw77gpJJDK
MTmc7713hg6f30kOX8OfruRw1y5PDl+nVYaoidumcJLD7RphVkuHZ0wOFy9YTA5f/ah3
cji/QEgO76rno+TwbvV8LFfOrsmp1IGwC8nhfKkrOZy0ZSE5nLxkITncJ+GZyEUotz/H
RABn1vgXMz8wS+hifjgtYn4otVzMD6W2T+aHOm/mh/ZczA8ubuYHbzDmhzov5odCNFlk
figguQ/MD6eLYn74fAmOd+t/lfnBxjswP/z77//33//4n//4/vqvf/zv118feyQFNpbL
Z039X6ElJyX9vfSDpsxxaqQjpMBRp0tH11ijZ41QBgSEyT6s+4t5pqIacESgWm3J9M4U
sMegLDXc67CztzwZo8UT1gKmNuZj5SzWiMm+TNE2CCpDPoJk10DQhTqbcFMiLIaffEhZ
8VgQvDTV+2R5mvq1Xxvfseavz4Hh94SD/2OwvOWFG7uAqOwhi4WyY+DDfck1UXSeKaAl
IHdBVWJMFbx5GUNJWkeqDa4IBaRRM/m1l+XgEx3dyo5CQV3rPsYqq2w6eC6wPoEKDv+o
6GAHkChKYKJaU9cDTdVT/Y2RdMbhf98gTA/p7ZbOTbqAJWja10PmQ1P12GUIeu4NmI2k
Saqng3w7Uk4gsOwzrAhfhm6RrwLXkHCJ8tTgRxwcRmYakDaC50oONFWpyi2wv0NnZbXP
L3VmI4bRcX0FQ4XPBUQiE9UL2EUGmBYers1BVknyI7+WkLRbsrIkEKjAODeUsmOZoiJh
3UsOBru2docuyIduhf80keNBWXeg1VLfHoVyUG3epG+XnHNDaVnjswWDjUkHpxKovFDl
uqHmHbigUJy+sebd+rQql9+4OmigAKBkKmIXt0JXfouLa1yLZijlbunwTVlMqSM/ASW0
UKq665CEsk+p+LWkEuK5W6Joc0INOVq8YdCBUTCBUHK/aYIVTp/zAog25b5fAA93Y4gQ
4gJIV3JclEcbii0WGG3OrqL6sqYJ1Bd8POhY44paMPHKtAGsWtuwPjGJ1sSZhQHyBlCz
FeoBI+rrdZl2SicdBYxg4QFY1whktefSFuFSlkHiDd2W2MoYl/rE9Tb5mLjCwynp0fDK
gt81aYvF3/TgrkVJFDkuDlo4FJegJZgViUqUld/CpbUM1ebHGl3UWValf5ljTYxO6q9V
/iyoX/cYM0DLWgN5x9B0B0x5GEGEcpbw+UQR0ZSXnBm+BX+DvuU0gfcSo+PXiNER0QP1
iL9SbUeSKNe6r1Yu2pyAuLX8JceKi+N5DaPjDZnk7qXZ6oMq/TRGqugWQEAgjA5W40JK
gmoYnabEVFX21+pKDge6Y7aYtbCalLiecuUlRQi+F9ehJMHf0L6r/q7yIks7RogL7Wkz
H0vKpt3FIvc7hACO1OejxYrcq47i91lW4YXk5C5W5F52cZCHIf52yyA7c6kqjrzk+bXn
4ZDN4UvMYAGSNdaqOs9bMT2wi4xBJgl+COr5uinZelW26EsdUyu7fsyK3IcWK3L/aKb7
v5v8KtaV+TRfhVjk/jGnEio1oF78EI/Nr9iiio7gfm3sPWZKVyn6Idc0WFDr9Gtj7Ae5
wW3ZSXN2C3Y43GBF7p9+fnnKSc7/uq95l17yY352+qwkU/G7oysoOk4yzV9bnpaEjcWS
BfqRPYC8exEFaA0rIhfhNZs5eA7+XBNB/mQ3W0PjHEfGOBXypQE4xTzzmgFYmR5j16x/
TYUEr+5qdc9VLVlJebvBsjuhddhRX0uP179tNnv5lrrWWNJMFeyDmC1TwmXRfXDqtqxy
7y9ViNj7BKev7QeZYbI0BQwtpE2qHCLVS4DRNZWmhS0VHdE1vQAA8Sl9fbzg+YwvswTd
ACKejSW+k0ahqJYSnM9QccgUhzpjYnJw7G54VeaiqBbVI+unqra2rB/sTwBMPLbgNasY
nsueuPwd5oI3q1+tgpY2cV38dnE8Bmnb94cW+8VGiAwnLnxHD7fKyqQ8CniJxiJgj1kP
xap4wxcwdPiEOJh1tcWZlZS3G17VKMFZpbEUN1S/MzBAwfZ61tL2xYVHLN3qHYazg5uG
vxLwJO0MgUQfAvg6yzUEsUVlj5MqZnHEkc+WCmeSlfkW5RsouPuU+K13at1u1eRhXeq5
5xKLmstH5Q3z0dzPTMrTt0hazBsr3r/7AZXCtpZjsaH0utUnwa+wFD0Y6uuXHxCCpjEp
z1V36/d6/6PftvFm87T92ttshg8t8dRClrQ8if05olGO74YxbKtVDCazfkFmPgMFDiHz
GSjiBRrzGXSr2atLIOGUb6wZbkKzRFgsE/6eesY4V8JGt5iNcnx/kpfRO5qvlcXQuXJR
m5P1Sonpdqk36d/k4AbZKMdPi2rS7sezionyx2fe8k+9J+tQ+x2V+QyZuMysrQAFw/KT
7VUr8xlYaxwGI/QDPtn8cHbpVk0s5jPYhcxZhnLjXJdMzKIc3zKOw1/urEERdPw+8hn4
N1+Q+QwU8ZUm8xlYCp0G45s0XC8px1HWRdNkPm66JdVTJNIYxl5OKr3fp3wUsuddtuNV
SuEO7mkZgRZuARL3+LjMAsgFRMcsIJ4JMS1NufWs7658hn1HY9BxP29eXxe75VHvhknK
8YLMOGoxacvcK+BTRvNKrgWO2S9t4M1HFxsYi2DXocI0RiKDLyGDHIcUIIVyYVGkJRPd
mrMQsi4moxzfDQ8px/UPWP5dpwX4gBDRMpk7ZlLh/NcoxwvrIPfzDL4qwsdZJEoF2awI
TkonfOWAJ3eHjZFsCV0sT1c5qNAyhVBmC/YUoodpwGmBRVgE0+vIznyxW0irXuhLqayY
joNSVnF0RRlgZKCPpcTziG71lb1kqw5kaz86O7ad66LvFfgHWlz3/aFFu08RmQG3S+zd
RQWFlBoB4aeM2GnXviUCjAaPmhIL4ZVh3fCqfFO6iLLVHX/lncH6b2N7voCRdp7T6lLi
6afV3PIUKM0PrLHFPoW1FGBeM+szV7mQXIb7zIxga2lU7gJfKxYGjA1rfHWBMlB2SBAh
8+ahT9RcWNysAT04JYM87bi+WyZ/a8mAqZGvHHFhugvLltkpLALnBtniGQivnoPc/CC5
W8qUCjbC1DLmBDQdGta6sX7L8TlVX/1ReQf42vJU6XD5tUlTrwUYfwP5KSWq+Y9ik38F
W2GfRzRjqz35GDZwvdV5lJVs9mkrq4murLhrmObPW5ThgqMASwo1wtTWG79fpx9Ka1YX
83u62+c5/ZLY3GFqvqWiTlM40WTgHMOJZn3Kuk80FM6JRtdsecVz50TDcsvxRJPJdn5O
NHkgxGQnGgrnRGPXrD/GC3V1N5xoWMk5nmhyHyOeaFAge59oKJwTja7pyML61udEs353
xhMNy0GHE03uluphJ5oMB+Z1ollDMuOJBkO0TzQUzonGrtkL5BlONP6CZ9UArO6caBQh
Z1Zr1YlG5vyw4pzmsF2y6t8c2QsG7JbGXHJ5I1DQuD/bG0GBA2e1vPvjqzS2et7adPTg
74ywSsPF07feS3K1RyWptrU+SFL68YqUB/9HdYrH1z5YjSnbsIuUB+L3b9ti46048Flt
YGzFW9yuOWtIycaGVR/UDRqxrBScjJSnoPw/3n6K3oHFBB8WN+6yW10uRsoTWrRe+eFg
1iJPaSEpj4nm+uMDfoP0HgAw9tDEbKQ8uyHl7TgmHPHJVsJQpDw+VnYS8bGyYwiKKxOd
z38P22J07SvmbOQ35RubpWn6dpQSCDlfW/5s2C8DjDUZ9vvP33//68E+M10LmLCErlSM
TrVTq/zJhCCJyNrFx4ms1aCMZHM4E9EjImsEAJvnWGqp2LX5lbuKCBArWDQRWVemZDYn
soYowmCNPXxtgFTQVsLK8AxlGDOaVMoPr/v6TlcVYkTz0CGLqlCelGXaSzMIKIqHKCb5
2bnVUvbmqy9LMErLfjaqKgUOAFbn4d4yQLJoquurUuAmm5uX+eZ2h6399sZbnE5krYaC
M24x05gDYDUfQeAgEKujK2uvu4dc6+R+YdIJD81DRVWGjmYmTiOytgYCF7ItjayVaHtX
ZcJpOkTWrRtabZvJtrqq9EwMoZFTPoTQmOcdQmiqzRVDaMLonRAakBk7hEbhhNAonhCa
brUQmmr+nRAai8TtEJpJFkJjyeYrhPbRwlrPacYQGuof7xAahRNCo2hreUkqAuhfFaC5
E0JjpbYQQitp1hhCK5k74PRaz3t3VK3nrc8lvU8IoZUkQoWt3nqfE0IryOEMITR/AVsJ
/QVsJVxivkNozDkLITSOdgihuSbEEBp/9ITQNIAKkbG83gmhcVRiCG0dnZ4YQkNJ7B1C
o3BCaLqmEJmeS0es4wqh8WuEEJr6ZCE0GxNXeJxU84e+o/7zre/mnDlyufU9l099z/XW
91yDvud66Xuul77zVtd3kn4Ffd9OEWq4JNd3JDre+n63QN+tavLW9zyCvudx6TtE1/c8
L33H7hX0vTy3vvPYGPS9jKDvZVz6rmvS59IufS/5Q9/5PkHfAUeJ+m4v4PpuL+D6jkTf
W99zu/Udox313TTh0nf8aNB3DqDpM1KLg75jVC59L+XW91KDvpd66TuvmT7zuaPvhFJG
fcfXiPrOPrm+a0xc38shvv6zlkuBOSTL5d/+dXZL7SQ6x8hiy3zlX8eksZKUIEVKfiMG
2cBhVc5eDCM/xadcuo6SD91E3BgZgl7/OakGMjjnEmE3qv79qEKxDtSsmaVLQ3kReE5O
hOq1o61IE6t8sapy/vFumFEhM1SUm7FcnBacp+g0MEwB67vbHKsWgXyarFS6SFOm1Z4e
s4YkZhYM5QywhiE37OMWLa0uIKi6S+jG2zSkfpnVrjgL6Oqa4m7lLBnuZ2A/czbgwPTw
AIQmIytrUORrsWvNXrjYfPcRSf7L3jIEuYFfJqveNzpWdWizyLJ9OF4z430JyhGwwybP
oHK6QZ9oqPbmcQghAzkfdXjVVMQHokKYaq6ZP9xKQvEl3jLtJL5b6msFu1+VeifuqjL0
R+Hnbw4esGu97QcFmWv7p7v5TqzFATr+OIEK8MXrby4br+rND3NT+3Pp67PPZzEALMKt
vb/99v/85syrZW5kc3RyZWFtCmVuZG9iagoxMyAwIG9iagozMzkxMgplbmRvYmoKMTEg
MCBvYmoKPDwKL1R5cGUgL1BhZ2UKL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1BhcmVu
dCAyIDAgUgovUmVzb3VyY2VzIDw8IC9Qcm9jU2V0IFsvUERGIC9UZXh0XQovRm9udCA8
PAovUjYgNiAwIFIKPj4KPj4KL0NvbnRlbnRzIDEyIDAgUgo+PgplbmRvYmoKNiAwIG9i
ago8PC9UeXBlL0ZvbnQvTmFtZS9SNi9TdWJ0eXBlL1R5cGUxL0Jhc2VGb250L1RpbWVz
LVJvbWFuL0VuY29kaW5nIDEwIDAgUj4+CmVuZG9iagoxMCAwIG9iago8PC9UeXBlL0Vu
Y29kaW5nL0RpZmZlcmVuY2VzWwoxNDkvYnVsbGV0XT4+CmVuZG9iagoyIDAgb2JqCjw8
IC9UeXBlIC9QYWdlcyAvS2lkcyBbCjMgMCBSCjcgMCBSCjExIDAgUgpdIC9Db3VudCAz
Cj4+CmVuZG9iagoxIDAgb2JqCjw8IC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAyIDAgUgo+
PgplbmRvYmoKMTQgMCBvYmoKPDwgL0NyZWF0aW9uRGF0ZSAoRDoyMDAyMTIwOTA4NDQ0
NykKL1Byb2R1Y2VyIChHTlUgR2hvc3RzY3JpcHQgNS41MCkKPj4KZW5kb2JqCnhyZWYK
MCAxNQowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwNjkzMjAgMDAwMDAgbiAKMDAwMDA2
OTI0OCAwMDAwMCBuIAowMDAwMDExMDU2IDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAg
biAKMDAwMDAxMTAzNSAwMDAwMCBuIAowMDAwMDY5MDk5IDAwMDAwIG4gCjAwMDAwMzQ3
OTUgMDAwMDAgbiAKMDAwMDAxMTIwNCAwMDAwMCBuIAowMDAwMDM0Nzc0IDAwMDAwIG4g
CjAwMDAwNjkxODggMDAwMDAgbiAKMDAwMDA2ODk0OSAwMDAwMCBuIAowMDAwMDM0OTQz
IDAwMDAwIG4gCjAwMDAwNjg5MjcgMDAwMDAgbiAKMDAwMDA2OTM2OSAwMDAwMCBuIAp0
cmFpbGVyCjw8IC9TaXplIDE1IC9Sb290IDEgMCBSIC9JbmZvIDE0IDAgUgo+PgpzdGFy
dHhyZWYKNjk0NTcKJSVFT0YK
--============_-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//////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
/////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAWAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAA
AAAAAAAAAAAAACAuao3Uj8IBDQAAAMACAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAg
AEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAA
AwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAA7BwA
AAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAA4AAACAFQAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMA
dQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB////
////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQC
AAAAAAAADwDoA+sIAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAA
AAAAAQAAAAAAAAEPAPIDrgEAAC8AyA8MAAAAMADSDwQAAAABAAAADwDVB+QAAAAAALcP
RAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAATDO6AHTaEgBc2hIAZKcM
MAgAAAAAAAAAdNoSACAmDDAAzAQSEAC3D0QAAABBAHIAaQBhAGwAAABOAGUAdwAgAFIA
bwBtAGEAbgAAAEwzugB02hIAXNoSAGSnDDAIAAAAAAAAAHTaEgAgJgwwAMwEIiAAtw9E
AAAAQQByAGkAYQBsACAATgBhAHIAcgBvAHcAAABhAG4AAABMM7oAdNoSAFzaEgBkpwww
CAAAAAAAAAB02hIAICYMMADMBCIAAKQPCgAAAIAAYAAAAP////8AAKUPDAAAAAAAAAgu
AAAABwAAAAAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAA
AABkAAAAAAAAAAAAQAIAAAAABwAAAP//7wAAAAAA////////GAAAAAABAAAABQAAIAEg
AQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEEAEAAA8A
APAIAQAAAAAG8LAAAAAEUAAAFQAAAAkAAAACAAAAAQAAAA4AAAAAAAAABQAAAAAAAAAE
AAAAAAAAAAsAAAAAAAAABAAAAAAAAABWAAAAAAAAAB4AAAAAAAAAHwAAAAAAAAAbAAAA
AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAFAAAAAAAA
AAUAAAAAAAAABAAAAAAAAAAdAAAAAAAAAAQAAAAEAAAABAAAAGMAC/AkAAAAgQEEAAAI
gwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIEAAa8QQAAAD/AAAAQAAe8RAAAAAC
AAAI/wAAAAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAAAAIAAAAAAAAAAAAAAAAAAIAAAAAA
DwDQB3sBAAAfABQEHAAAAAAAFQQUAAAAuh117ADKmjsyTs3JAMqaOwACAAEPAPoDZwAA
AAAA/gMDAAAAAAEAAAD9AzQAAABQAAAAZAAAAFAAAABkAAAAZKcMMAgAAAAAAAAAaNoS
AAAAAAAAAAAAPv7//6z///8BAAAAcAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEAL
AAAfAAcEPAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAAGc/DDAk3hIAAAAAADg0ugAA
AAAAAAAAAAAAAAAAAAAAAAESAB8AEwQ8AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAA
Zz8MMCTeEgAAAAAAODS6AAAAAAAAAAAAAAAAAAAAAAAAARIAHwD/AxQAAAACAAAEDAAA
AAAAAAAAAAAAAgAAAB8ACAQ8AAAAAAD9AzQAAABCAAAAZAAAAEIAAABkAAAAlNoSAOdA
DDAk3hIAAQAAAAAAAAAAAAAAAAAAAAAAAAAAABIAPwDZDwwAAAAAANoPBAAAAAAAJQAP
APAPIgQAAAAA8wMUAAAAFAAAAAAAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgP
CgAAAEVQUCAvIFNPQVAQAJ8PBAAAAAEAAAAAAKAPBgMAAEQAcgBhAGYAdAAgAGQAZQBm
AGkAbgBlAHMAIABhACAAUwBPAEEAUAAgAHQAcgBhAG4AcwBwAG8AcgB0ACAAZgBvAHIA
IABFAFAAUAANAFMATwBBAFAAIABlAG4AdgBlAGwAbwBwAGUAIAB3AGkAdABoACAAGCB2
AGkAcgB0AHUAYQBsACAAcwBlAHMAcwBpAG8AbgAZICAAYwBoAGEAcgBhAGMAdABlAHIA
aQB6AGUAZAAgAGkAbgAgAFMATwBBAFAAIABoAGUAYQBkAGUAcgANAE8AcABlAG4AIABp
AHMAcwB1AGUAcwA6AA0ARQByAHIAbwByACAAYwBvAGQAZQBzACAAEyAgAGMAdQByAHIA
ZQBuAHQAbAB5ACAAbwB2AGUAcgBsAG8AYQBkAGkAbgBnACAAZQB4AGkAcwB0AGkAbgBn
ACAARQBQAFAAIABlAHIAcgBvAHIAcwAsACAAcwBoAG8AdQBsAGQAIABkAGUAZgBpAG4A
ZQAgAG4AZQB3ACAAYwBvAGQAZQBzAA0AUwBPAEEAUAAgAGEAcwAgAGEAIAAYIHQAcgBh
AG4AcwBwAG8AcgB0ABkgDQBEAG8AIAB3AGUAIABuAGUAZQBkACAAdABvACAAYwBvAG4A
cwB0AHIAYQBpAG4AIABhAGMAdAB1AGEAbAAgAHQAcgBhAG4AcwBwAG8AcgB0ACAAcABy
AG8AdABvAGMAbwBsAHMAIAB1AHMAZQBkACAAYgB5ACAAUwBPAEEAUAA/AA0AQwBoAGEA
cgB0AGUAcgAgAGEAbgBkACAAVwBHACAAaQB0AGUAbQAgAHMAdABhAHQAdQBzAA0ASABv
AHcAIABkAG8AZQBzACAAdABoAGkAcwAgAGQAcgBhAGYAdAAgAGYAaQB0ACAAdwBpAHQA
aAAgAGUAeABpAHMAdABpAG4AZwAgAGQAZQBsAGkAdgBlAHIAYQBiAGwAZQBzACAAbwBm
ACAAdABoAGUAIABwAHIAbwB2AHIAZQBnACAAYwBoAGEAcgB0AGUAcgA/AAAAoQ+kAAAA
JwAAAAAAABAAAFoAQgAAAAEAABAAAFoADQAAAAAAABAAAFoAZwAAAAEAABAAAFoAQQAA
AAIAABAAAFoAGwAAAAEAABAAAFoASwAAAAIAABAAAFoAJwAAAAAAAgAVAEIAAAAAAAIA
FAANAAAAAAQCAAEEFQBnAAAAAAgCAAEIFABBAAAAAAgCAAEIFAAbAAAAAAwCAAEMFABL
AAAAABACAAEQFAAAAKoPGgAAAHMBAAAAAAAACAAAAAEAAAADAAkAAAAAAAAAAADqAwAA
AAAPAPgDnggAAAIA7wMYAAAAAQAAAAECBwkIAAAAAAAAAAAAAAAAAAAAYADwByAAAAAA
AP8A////AAAAAAD//wAA/5kAAAD//wD/AAAAlpaWAGAA8AcgAAAA////AAAAAACAgIAA
AAAAAADMmQAzM8wAzMz/ALKysgBgAPAHIAAAAP///wAAAAAAMzMzAAAAAADd3d0AgICA
AE1NTQDq6uoAYADwByAAAAD//8wAAAAAAGZmMwCAgAAAM5kzAIAAAAAAM8wA/8xmAGAA
8AcgAAAA////AAAAAACAgIAAAAAAAP/MZgAAAP8AzADMAMDAwABgAPAHIAAAAP///wAA
AAAAgICAAAAAAADAwMAAAGb/AP8AAAAAmQAAYADwByAAAAD///8AAAAAAICAgAAAAAAA
M5n/AJn/zADMAMwAsrKyAAAAow8+AAAAAQD//T8AAAAiIAAAZAAAAAAAAQBkAAAAAAAA
AAAAQAIAAAAABwAAAP//7wABAAEA////////JgAAAAAFAAAQAKMPfgAAAAUA//0/AAEA
IiAAAGQAAAAAAAAAZAAUAAAA2AAAAEACAAAAAAcAAAD//+8AAQABAP///////xkAAAAA
AQAAgAUAABMg1AEgAQAAAgAWAIAFAAAiINACQAIAAAAAgAUAABMg8ANgAwEAAwAAAAIA
FACABQAAuwAQBYAEAAAAACAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAB4AAAAA
AAAAQAIAAAAABwAAAP//7wAAAAAA////////DAAAAAABAAAABQAAIAEgAQAAAAAABQAA
QAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAABQAKMPUgAAAAUAAAABCQAAAAAB
AAAAAAAAAAEAAQkAAAAAAQAgAQAAAAACAAEJAAAAAAEAQAIAAAAAAwABCQAAAAABAGAD
AAAAAAQAAQkAAAAAAQCABAAAAABgAKMPDAAAAAEAAAAAAAAAAAAAAHAAow8+AAAABQAA
AAAAAAAAAAIAFQABAAAAAAAAAAIAFAACAAAAAAAAAAIAFAADAAAAAAAAAAIAEgAEAAAA
AAAAAAIAEgCAAKMPPgAAAAUAAAAAAAAAAAACABMAAQAAAAAAAAACABIAAgAAAAAAAAAC
ABIAAwAAAAAAAAACABAABAAAAAAAAAACABAADwAMBNYEAAAPAALwzgQAABAACPAIAAAA
BgAAAA0EAAAPAAPwZgQAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK
8AgAAAAABAAABQAAAA8ABPDSAAAAEgAK8AgAAAACBAAAAAoAAJMAC/A2AAAAfwABAAUA
gAAgaboAhwABAAAAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ
8AgAAACAAbAB0BRQBA8AEfAQAAAAAADDCwgAAAAAAAAAAQC6AA8ADfBUAAAAAACfDwQA
AAAAAAAAAACoDyAAAABDbGljayB0byBlZGl0IE1hc3RlciB0aXRsZSBzdHlsZQAAog8G
AAAAIQAAAAAAAACqDwoAAAAhAAAAAQAAAAAADwAE8BYBAAASAArwCAAAAAMEAAAACgAA
gwAL8DAAAAB/AAEABQCAAKhrugCBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQAB
AgIAAAgAABDwCAAAAOAEsAHQFAAPDwAR8BAAAAAAAMMLCAAAAAEAAAACALoADwAN8J4A
AAAAAJ8PBAAAAAEAAAAAAKgPUgAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRleHQgc3R5
bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3VydGggbGV2ZWwNRmlmdGggbGV2
ZWwAAKIPHgAAACEAAAAAAA0AAAABAAwAAAACAA0AAAADAAwAAAAEAAAAqg8KAAAAUwAA
AAEAAAAAAA8ABPC2AAAAEgAK8AgAAAAEBAAAAAoAAIMAC/AwAAAAfwABAAUAgAA0cLoA
gQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABgD7ABYAaA
EA8AEfAQAAAAAADDCwgAAAACAAAABwG6AA8ADfA+AAAAAACfDwQAAAAEAAAAAACgDwIA
AAAqAAAAoQ8UAAAAAgAAAAAAAAAAAAIAAAAAAAIADgAAAPgPBAAAAAAAAAAPAATwuAAA
ABIACvAIAAAABQQAAAAKAACDAAvwMAAAAH8AAQAFAIAACHK6AIEBBAAACIMBAAAACL8B
AQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAYA+wB9AOgBAPABHwEAAAAAAAwwsI
AAAAAwAAAAkCugAPAA3wQAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFgAAAAIA
AAAAAAAIAAABAAIAAAAAAAIADgAAAPoPBAAAAAAAAAAPAATwuAAAABIACvAIAAAABgQA
AAAKAACDAAvwMAAAAH8AAQAFAIAAhHq6AIEBBAAACIMBAAAACL8BAQARAMABAQAACP8B
AQAJAAECAgAACAAAEPAIAAAAYA8gENAUgBAPABHwEAAAAAAAwwsIAAAABAAAAAgCugAP
AA3wQAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFgAAAAIAAAAAAAAIAAACAAIA
AAAAAAIADgAAANgPBAAAAAAAAAAPAATwSAAAABIACvAIAAAAAQQAAAAMAACDAAvwMAAA
AIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA
8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAgALoPHAAAAEQAZQBm
AGEAdQBsAHQAIABEAGUAcwBpAGcAbgAPAO4D5AEAAAIA7wMYAAAAAQAAAA0OAAAAAAAA
AAAAgAAAAAAHAAAADwAMBJQBAAAPAALwjAEAAEAACPAIAAAAAwAAAANQAAAPAAPwJAEA
AA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAUAAABQAAAA8A
BPByAAAAEgAK8AgAAAACUAAAIAIAAFMAC/AeAAAAfwAAAAQAgACsQo4CvwEAAAEA/wEA
AAEAAQMCBAAAAAAQ8AgAAACAAbAB0BRQBA8AEfAQAAAAAADDCwgAAAAAAAAADQCOAg8A
DfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAANQAAAgAgAAUwAL8B4AAAB/
AAAABACAAAxHjgK/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAOAEsAHQFAAPDwAR8BAA
AAAAAMMLCAAAAAEAAAAOAI4CDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAI
AAAAAVAAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8B
AAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/
ALKysgAAAHIXFAAAAAEAIAAAAAAA8wgAABQAEACZEQAAAAD1DxwAAAAAAQAArxEAAwAA
AACFEwAAAQAAABQAAAABAAAADwDoA+sIAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAF
AAAACgAAAAAAAAAAAAAAAQAAAAAAAAEPAPIBAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAH
AAAACAAAAP7///8KAAAA/v//////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
//////////////////////////////////////7/AAAFAAIAAAAAAAAAAAAAAAAAAAAA
AAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAAOQBAAAQAAAAAQAAAIgAAAADAAAAkAAAAA8A
AACoAAAABAAAANAAAAAGAAAA2AAAAAcAAADgAAAACAAAAOgAAAAJAAAA8AAAAAoAAAD4
AAAAFwAAAAABAAALAAAACAEAABAAAAAQAQAAEwAAABgBAAAWAAAAIAEAAA0AAAAoAQAA
DAAAAIEBAAACAAAA5AQAAB4AAAAPAAAAT24tc2NyZWVuIFNob3cAUB4AAAAdAAAATGV2
ZWwgMyBDb21tdW5pY2F0aW9ucywgSW5jLgBzAGUDAAAA7BwAAAMAAAAJAAAAAwAAAAEA
AAADAAAAAAAAAAMAAAAAAAAAAwAAAAAAAAADAAAAMhEJAAsAAAAAAAAACwAAAAAAAAAL
AAAAAAAAAAsAAAAAAAAAHhAAAAUAAAAQAAAAVGltZXMgTmV3IFJvbWFuAAYAAABBcmlh
bAANAAAAQXJpYWwgTmFycm93AA8AAABEZWZhdWx0IERlc2lnbgALAAAARVBQIC8gU09B
UAAMEAAABgAAAB4AAAALAAAARm9udHMgVXNlZAADAAAAAwAAAB4AAAAQAAAARGVzaWdu
IFRlbXBsYXRlAAMAAAABAAAAHgAAAA0AAABTbGlk/v8AAAUAAgAAAAAAAAAAAAAAAAAA
AAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAUBUAAAsAAAABAAAAYAAAAAIAAABoAAAA
BAAAAIwAAAAIAAAApAAAAAkAAAC8AAAAEgAAAMgAAAAKAAAA6AAAAAwAAAD0AAAADQAA
AAABAAAPAAAADAEAABEAAAAUAQAAAgAAAOQEAAAeAAAAGgAAAFVzaW5nIFNlcnZpY2VD
b2RlcyBpbiBTSVAAaQAeAAAADQAAAGpvbiBwZXRlcnNvbgBDb2QeAAAADQAAAEpvbiBQ
ZXRlcnNvbgBDb2QeAAAAAwAAADI0ACAeAAAAFQAAAE1pY3Jvc29mdCBQb3dlclBvaW50
ACBTSUAAAABAAOODbAAAAEAAAACgWYu6L7DAAUAAAACgE2SN1I/CAQMAAAA/AAAARwAA
ADQUAAD/////AwAAAAgAiRBnDAAAAQAJAAADEgoAAAYAWAAAAAAAEQAAACYGDwAYAP//
//8AABAAAAAAAAAAAADAAwAA0AIAAAkAAAAmBg8ACAD/////AgAAABcAAAAmBg8AIwD/
////BAAbAFROUFAUACwBugAyAAAA//9PABQAAABNAGkAAAAKAAAAJgYPAAoAVE5QUAAA
AgD0AwkAAAAmBg8ACAD/////AwAAAA8AAAAmBg8AFABUTlBQBAAMAAEAAAABAAAAAAAA
AAUAAAALAgAAAAAFAAAADALQAsADBQAAAAQBDQAAAAcAAAD8AgAA////AAAABAAAAC0B
AAAIAAAA+gIFAAEAAAAAAAAABAAAAC0BAQAEAAAALQEAAAkAAAAdBiEA8ADQAsADAAAA
AAQAAAAtAQAABwAAAPwCAAD///8AAAAEAAAALQECAAQAAADwAQAACAAAAPoCAAAAAAAA
AAAAAAQAAAAtAQAAEAAAACYGDwAWAP////8AAEcAAACPAgAAEQEAAMECAAAIAAAAJgYP
AAYA/////wEAHAAAAPsCAAAAAAAAAAAAAAAAAAAAAAAAAM0SAGh/9XdAAAAAIgUKOr5i
9XfHYvV3AQAAAAAAMAAEAAAALQEDAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAAIBAgAA
ABAAAAAmBg8AFgD/////AABHAQAAjwIAAHkCAADBAgAACAAAACYGDwAGAP////8BAAUA
AAAJAgAAAAIFAAAAFAIAAAAABQAAAAIBAgAAAAcAAAD8AgEAAAAAAAAABAAAAC0BBAAE
AAAALQEBAAcAAAAbBLkAeQNAAEgABAAAAC0BAgAEAAAALQEAAAUAAAAJAgAAAAIFAAAA
FAIAAAAAHAAAAPsCzf8AAAAAAAC8AgAAAAAAQAAiQXJpYWwA9XdAAAAA+gUKSL5i9XfH
YvV3AQAAAAAAMAAEAAAALQEFAAQAAADwAQMABQAAAAkCMzPMAgUAAAAUAgAAAAAFAAAA
LgEYAAAABQAAAAIBAQAAABYAAAAyCo4AUQEKAAAARVBQIC8gU09BUCIAIgAiAA4ADgAO
ACIAKAAjACIABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAAAgECAAAABAAAAC0BBAAEAAAA
LQEBAAcAAAAbBIECeQPQAEgABAAAAC0BAgAEAAAALQEAAAUAAAAJAjMzzAIFAAAAFAIA
AAAAHAAAAPsC5P8AAAAAAACQAQAAAAAAQAAiQXJpYWwA9XdAAAAAIgUKPr5i9XfHYvV3
AQAAAAAAMAAEAAAALQEDAAQAAADwAQUABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEY
AAAABQAAAAIBAQAAAAkAAAAyCu0AUgABAAAAlQAKAAUAAAAuAQEAAAAFAAAAAgECAAAA
HAAAAPsC5P8AAAAAAAC8AgAAAAAAQAAiQXJpYWwA9XdAAAAA+gUKSr5i9XfHYvV3AQAA
AAAAMAAEAAAALQEFAAQAAADwAQMABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAA
BQAAAAIBAQAAAEAAAAAyCu0AdgAmAAAARHJhZnQgZGVmaW5lcyBhIFNPQVAgdHJhbnNw
b3J0IGZvciBFUFAUAAsAEAAJAAkACAARABAACQAIABEAEAAPAAgAEAAIABMAFQATABIA
CQAJAAsAEAARAA8AEQARAAsACQAIAAkAEQALAAgAEwATABIABQAAAC4BAQAAAAUAAAAC
AQIAAAAcAAAA+wLl/wAAAAAAAJABAAAAAABAACJBcmlhbAD1d0AAAAAiBQpCvmL1d8di
9XcBAAAAAAAwAAQAAAAtAQMABAAAAPABBQAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAu
ARgAAAAFAAAAAgEBAAAACQAAADIKEAGCAAEAAACWAA8ABQAAAC4BAQAAAAUAAAACAQIA
AAAcAAAA+wLl/wAAAAAAALwCAAAAAABAACJBcmlhbAD1d0AAAAD6BQpMvmL1d8di9XcB
AAAAAAAwAAQAAAAtAQUABAAAAPABAwAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgA
AAAFAAAAAgEBAAAAWAAAADIKEAGgADYAAABTT0FQIGVudmVsb3BlIHdpdGggkXZpcnR1
YWwgc2Vzc2lvbpIgY2hhcmFjdGVyaXplZCBpbiASABUAEwASAAgADgARAA8ADgAHABEA
EQAOAAgAFAAIAAgAEAAIAAgADgAHAAsACAARAA8ABwAIAA8ADgAPAA8ABwAQABEABwAI
AA4AEQAOAAsADwAPAAkADgAKAAgADQAPABAABwAIABAABwAFAAAALgEBAAAABQAAAAIB
AgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAYAAAAMgot
AaAACwAAAFNPQVAgaGVhZGVyABIAFQATABIABwARAA8ADgARAA4ACwAFAAAALgEBAAAA
BQAAAAIBAgAAABwAAAD7AuT/AAAAAAAAkAEAAAAAAEAAIkFyaWFsAPV3QAAAACIFCki+
YvV3x2L1dwEAAAAAADAABAAAAC0BAwAEAAAA8AEFAAUAAAAJAgAAAAIFAAAAFAIAAAAA
BQAAAC4BGAAAAAUAAAACAQEAAAAJAAAAMgpSAVIAAQAAAJUACgAFAAAALgEBAAAABQAA
AAIBAgAAABwAAAD7AuT/AAAAAAAAvAIAAAAAAEAAIkFyaWFsAPV3QAAAAPoFCk6+YvV3
x2L1dwEAAAAAADAABAAAAC0BBQAEAAAA8AEDAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAA
AC4BGAAAAAUAAAACAQEAAAAZAAAAMgpSAXYADAAAAE9wZW4gaXNzdWVzOhUAEQAQABEA
CAAIAA8ADwARABAADwAKAAUAAAAuAQEAAAAFAAAAAgECAAAAHAAAAPsC5f8AAAAAAACQ
AQAAAAAAQAAiQXJpYWwA9XdAAAAAIgUKTb5i9XfHYvV3AQAAAAAAMAAEAAAALQEDAAQA
AADwAQUABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAAkAAAAy
CnUBggABAAAAlgAPAAUAAAAuAQEAAAAFAAAAAgECAAAAHAAAAPsC5f8AAAAAAAC8AgAA
AAAAQAAiQXJpYWwA9XdAAAAA+gUKUL5i9XfHYvV3AQAAAAAAMAAEAAAALQEFAAQAAADw
AQMABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAABkAAAAyCnUB
oAAMAAAARXJyb3IgY29kZXMgEgAKAAsAEAAKAAgADwAQABEADwAOAAgABQAAAC4BAQAA
AAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAA
CQAAADIKdQE+AQEAAACWAA4ABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAA
ABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAASAAAADIKdQFUASsAAABjdXJyZW50bHkg
b3ZlcmxvYWRpbmcgZXhpc3RpbmcgRVBQIGVycm9ycywgAA4AEQAKAAsADgARAAgACAAO
AAgAEQAOAA8ACgAHABEADwAQAAcAEQAQAAgADwAOAAgADwAIAAcAEQAQAAgAEgARABIA
CAAOAAoACwAQAAsADgAHAAcABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAA
ABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAKgAAADIKkgGgABcAAABzaG91bGQgZGVm
aW5lIG5ldyBjb2RlcwAPABAAEQAQAAcAEQAHABEADwAIAAcAEQAPAAcAEQAOABUACAAO
ABAAEQAPAA8ABQAAAC4BAQAAAAUAAAACAQIAAAAcAAAA+wLl/wAAAAAAAJABAAAAAABA
ACJBcmlhbAD1d0AAAAAiBQpVvmL1d8di9XcBAAAAAAAwAAQAAAAtAQMABAAAAPABBQAF
AAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAACQAAADIKtQGCAAEA
AACWAA8ABQAAAC4BAQAAAAUAAAACAQIAAAAcAAAA+wLl/wAAAAAAALwCAAAAAABAACJB
cmlhbAD1d0AAAAD6BQpSvmL1d8di9XcBAAAAAAAwAAQAAAAtAQUABAAAAPABAwAFAAAA
CQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAJwAAADIKtQGgABUAAABT
T0FQIGFzIGEgkXRyYW5zcG9ydJITEgAVABMAEgAIAA8ADgAIAA4ABwAIAAkACgAPABEA
DgAQABEACgAJAAgABQAAAC4BAQAAAAUAAAACAQIAAAAcAAAA+wLl/wAAAAAAAJABAAAA
AABAACJBcmlhbAD1d0AAAAAiBQpZvmL1d8di9XcBAAAAAAAwAAQAAAAtAQMABAAAAPAB
BQAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAACQAAADIK2QGy
AAEAAACVAAkABQAAAC4BAQAAAAUAAAACAQIAAAAcAAAA+wLl/wAAAAAAALwCAAAAAABA
ACJBcmlhbAD1d0AAAAD6BQpUvmL1d8di9XcBAAAAAAAwAAQAAAAtAQUABAAAAPABAwAF
AAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAVAAAADIK2QHKADMA
AABEbyB3ZSBuZWVkIHRvIGNvbnN0cmFpbiBhY3R1YWwgdHJhbnNwb3J0IHByb3RvY29s
cyBEFAAQAAgAFAAPAAcAEQAPAA4AEAAIAAkAEAAIAA4AEAARAA8ACAALAA8ABwAQAAgA
DwAPAAgAEQAOAAgABwAJAAsADgARAA4AEAARAAsACAAHABEACgARAAgAEQAOABEABwAP
AAcABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgA
AAAFAAAAAgEBAAAAGwAAADIK9QHKAA0AAAB1c2VkIGJ5IFNPQVA/ABEADwAOABEABwAR
AA4ACAASABUAEwARABEABQAAAC4BAQAAAAUAAAACAQIAAAAcAAAA+wLl/wAAAAAAAJAB
AAAAAABAACJBcmlhbAD1d0AAAAAiBQpfvmL1d8di9XcBAAAAAAAwAAQAAAAtAQMABAAA
APABBQAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAACQAAADIK
GQKCAAEAAACWAA8ABQAAAC4BAQAAAAUAAAACAQIAAAAcAAAA+wLl/wAAAAAAALwCAAAA
AABAACJBcmlhbAD1d0AAAAD6BQpWvmL1d8di9XcBAAAAAAAwAAQAAAAtAQUABAAAAPAB
AwAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAALgAAADIKGQKg
ABoAAABDaGFydGVyIGFuZCBXRyBpdGVtIHN0YXR1cxQAEAAPAAsACAAPAAoACAAOABEA
EAAIABkAFAAHAAgACQAOABkABwAPAAkADgAJABEADwAFAAAALgEBAAAABQAAAAIBAgAA
ABwAAAD7AuX/AAAAAAAAkAEAAAAAAEAAIkFyaWFsAPV3QAAAACIFCmS+YvV3x2L1dwEA
AAAAADAABAAAAC0BAwAEAAAA8AEFAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAA
AAUAAAACAQEAAAAJAAAAMgo8ArIAAQAAAJUACQAFAAAALgEBAAAABQAAAAIBAgAAABwA
AAD7AuX/AAAAAAAAvAIAAAAAAEAAIkFyaWFsAPV3QAAAAPoFCli+YvV3x2L1dwEAAAAA
ADAABAAAAC0BBQAEAAAA8AEDAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUA
AAACAQEAAABYAAAAMgo8AsoANgAAAEhvdyBkb2VzIHRoaXMgZHJhZnQgZml0IHdpdGgg
ZXhpc3RpbmcgZGVsaXZlcmFibGVzIG9mIBQAEAAVAAcAEAARAA8ADgAIAAgAEQAIAA4A
BwARAAoADwAJAAgACAAJAAcACQAHABUACAAIABAACAAPAA4ACAAPAAgACAAQABAACAAQ
AA8ABwAIAA8ADgALAA4AEQAHAA8ADwAHABEACAAHAAUAAAAuAQEAAAAFAAAAAgECAAAA
BQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAA0AAAAyClkCygAE
AAAAdGhlIAkAEQAOAAgABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQC
AAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAEwAAADIKWQL6AAgAAABwcm92cmVnIBAACgAR
AA4ACwAPABAACAAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAA
BQAAAC4BGAAAAAUAAAACAQEAAAATAAAAMgpZAmUBCAAAAGNoYXJ0ZXI/DgARAA4ACwAJ
AA4ACwARAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAIBAgAAAAQAAAAtAQEABAAAAC0B
BAAcAAAA+wIQAAcAAAAAALwCAAAAAAECAiJTeXN0ZW0AAAAACgAAAAQAAAAAAAMAAAAB
AAAAAAAwAAQAAAAtAQMABAAAAPABBQAPAAAAJgYPABQAVE5QUAQADAAAAAAAAAAAAAAA
AAAJAAAAJgYPAAgA/////wEAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AGUgVGl0bGVzAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAPYPJAAAABQAAABfwJHjyBwAAAwA9AMDAIgBSm9uIFBldGVy
c29uCAAAAEoAbwBuACAAUABlAHQAZQByAHMAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAQwB1AHIAcgBlAG4AdAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAABoAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAJAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////
/////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/////
//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAADrgEAAC8AyA8MAAAAMADSDwQAAAABAAAADwDVB+QAAAAAALcPRAAAAFQAaQBt
AGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAATDO6AHTaEgBc2hIAZKcMMAgAAAAAAAAA
dNoSACAmDDAAzAQSEAC3D0QAAABBAHIAaQBhAGwAAABOAGUAdwAgAFIAbwBtAGEAbgAA
AEwzugB02hIAXNoSAGSnDDAIAAAAAAAAAHTaEgAgJgwwAMwEIiAAtw9EAAAAQQByAGkA
YQBsACAATgBhAHIAcgBvAHcAAABhAG4AAABMM7oAdNoSAFzaEgBkpwwwCAAAAAAAAAB0
2hIAICYMMADMBCIAAKQPCgAAAIAAYAAAAP////8AAKUPDAAAAAAAAAguAAAABwAAAAAA
qQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAA
AAAAQAIAAAAABwAAAP//7wAAAAAA////////GAAAAAABAAAABQAAIAEgAQAAAAAABQAA
QAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEEAEAAA8AAPAIAQAAAAAG
8LAAAAAEUAAAFQAAAAkAAAACAAAAAQAAAA4AAAAAAAAABQAAAAAAAAAEAAAAAAAAAAsA
AAAAAAAABAAAAAAAAABWAAAAAAAAAB4AAAAAAAAAHwAAAAAAAAAbAAAAAAAAAAQAAAAA
AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAFAAAAAAAAAAUAAAAAAAAA
BAAAAAAAAAAdAAAAAAAAAAQAAAAEAAAABAAAAGMAC/AkAAAAgQEEAAAIgwEAAAAIvwEQ
ABAAwAEBAAAI/wEIAAgAAQICAAAIEAAa8QQAAAD/AAAAQAAe8RAAAAACAAAI/wAAAAIA
AAj3AAAQHwDwDxwAAAAAAPMDFAAAAAIAAAAAAAAAAAAAAAAAAIAAAAAADwDQB3sBAAAf
ABQEHAAAAAAAFQQUAAAAuh117ADKmjsyTs3JAMqaOwACAAEPAPoDZwAAAAAA/gMDAAAA
AAEAAAD9AzQAAABQAAAAZAAAAFAAAABkAAAAZKcMMAgAAAAAAAAAaNoSAAAAAAAAAAAA
Pv7//6z///8BAAAAcAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAAfAAcEPAAA
AAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAAGc/DDAk3hIAAAAAADg0ugAAAAAAAAAAAAAA
AAAAAAAAAAESAB8AEwQ8AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAAZz8MMCTeEgAA
AAAAODS6AAAAAAAAAAAAAAAAAAAAAAAAARIAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAA
AgAAAB8ACAQ8AAAAAAD9AzQAAABCAAAAZAAAAEIAAABkAAAAlNoSAOdADDAk3hIAAQAA
AAAAAAAAAAAAAAAAAAAAAAAAABIAPwDZDwwAAAAAANoPBAAAAAAAJQAPAPAPIgQAAAAA
8wMUAAAAFAAAAAAAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPCgAAAEVQUCAv
IFNPQVAQAJ8PBAAAAAEAAAAAAKAPBgMAAEQAcgBhAGYAdAAgAGQAZQBmAGkAbgBlAHMA
IABhACAAUwBPAEEAUAAgAHQAcgBhAG4AcwBwAG8AcgB0ACAAZgBvAHIAIABFAFAAUAAN
AFMATwBBAFAAIABlAG4AdgBlAGwAbwBwAGUAIAB3AGkAdABoACAAGCB2AGkAcgB0AHUA
YQBsACAAcwBlAHMAcwBpAG8AbgAZICAAYwBoAGEAcgBhAGMAdABlAHIAaQB6AGUAZAAg
AGkAbgAgAFMATwBBAFAAIABoAGUAYQBkAGUAcgANAE8AcABlAG4AIABpAHMAcwB1AGUA
cwA6AA0ARQByAHIAbwByACAAYwBvAGQAZQBzACAAEyAgAGMAdQByAHIAZQBuAHQAbAB5
ACAAbwB2AGUAcgBsAG8AYQBkAGkAbgBnACAAZQB4AGkAcwB0AGkAbgBnACAARQBQAFAA
IABlAHIAcgBvAHIAcwAsACAAcwBoAG8AdQBsAGQAIABkAGUAZgBpAG4AZQAgAG4AZQB3
ACAAYwBvAGQAZQBzAA0AUwBPAEEAUAAgAGEAcwAgAGEAIAAYIHQAcgBhAG4AcwBwAG8A
cgB0ABkgDQBEAG8AIAB3AGUAIABuAGUAZQBkACAAdABvACAAYwBvAG4AcwB0AHIAYQBp
AG4AIABhAGMAdAB1AGEAbAAgAHQAcgBhAG4AcwBwAG8AcgB0ACAAcAByAG8AdABvAGMA
bwBsAHMAIAB1AHMAZQBkACAAYgB5ACAAUwBPAEEAUAA/AA0AQwBoAGEAcgB0AGUAcgAg
AGEAbgBkACAAVwBHACAAaQB0AGUAbQAgAHMAdABhAHQAdQBzAA0ASABvAHcAIABkAG8A
ZQBzACAAdABoAGkAcwAgAGQAcgBhAGYAdAAgAGYAaQB0ACAAdwBpAHQAaAAgAGUAeABp
AHMAdABpAG4AZwAgAGQAZQBsAGkAdgBlAHIAYQBiAGwAZQBzACAAbwBmACAAdABoAGUA
IABwAHIAbwB2AHIAZQBnACAAYwBoAGEAcgB0AGUAcgA/AAAAoQ+kAAAAJwAAAAAAABAA
AFoAQgAAAAEAABAAAFoADQAAAAAAABAAAFoAZwAAAAEAABAAAFoAQQAAAAIAABAAAFoA
GwAAAAEAABAAAFoASwAAAAIAABAAAFoAJwAAAAAAAgAVAEIAAAAAAAIAFAANAAAAAAQC
AAEEFQBnAAAAAAgCAAEIFABBAAAAAAgCAAEIFAAbAAAAAAwCAAEMFABLAAAAABACAAEQ
FAAAAKoPGgAAAHMBAAAAAAAACAAAAAEAAAADAAkAAAAAAAAAAADqAwAAAAAAAHIXCAAA
AAEAEADFEwAAAAD1DxwAAAAAAQAArxEAA6ETAAC4HAAAAQAAABQAAAABAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAUgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQD//////////wEAAAAQjYFkm0/P
EYbqAKoAuSnoAAAAAAAAAAAAAAAAANcLEMGbwgENAAAAgAIAAAAAAABQAG8AdwBlAHIA
UABvAGkAbgB0ACAARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAKAACAQIAAAADAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAIAAADsHAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBv
AG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBBAAAAP//////////AAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAIAVAAAAAAAABQBEAG8AYwB1
AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAA
AAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAFAIAAAAAAAD//////////wMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkA
AAAKAAAACwAAABsAAAD/////JAAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAW
AAAAFwAAABgAAAD+//////////////8cAAAAHQAAAB4AAAAfAAAA/v///yIAAAD9////
/v////7////+////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
/////////////////////////0MAdQByAHIAZQBuAHQAIABVAHMAZQByAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIA////////////////AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAACgAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgA
AAD+/////v//////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
//////////////////////////////9lIFRpdGxlcwADAAAAAQAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2DyAAAAAUAAAAX8CR
48gcAAAIAPQDAwCC8EFSSU4gTmV0CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG8A
bgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
--============_-1172544961==_============--



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBANrZ9p021278 for <[e-mail]>; Wed, 11 Dec 2002 00:53:35 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gBANrZHK021277 for ietf-provreg-outgoing; Wed, 11 Dec 2002 00:53:35 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from isrv4.isc.org (isrv4.isc.org [204.152.184.27]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBANrW9p021272 for <[e-mail]>; Wed, 11 Dec 2002 00:53:33 +0100 (MET)
Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by isrv4.isc.org (Postfix) with ESMTP id 019626AF; Tue, 10 Dec 2002 23:53:31 +0000 (UTC) (envelope-from [e-mail])
Received: by farside.isc.org (Postfix, from userid 10015) id 6DD31AA7C; Tue, 10 Dec 2002 23:53:30 +0000 (UTC)
To: Michael Graff <[e-mail]>
Cc: "Hollenbeck, Scott" <[e-mail]>, [e-mail]
Subject: Re: EPP statuses and other questions
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: Michael Graff <[e-mail]>
Date: 10 Dec 2002 23:53:30 +0000
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 72
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBADik9p015303 for <[e-mail]>; Tue, 10 Dec 2002 14:44:46 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gBADikot015302 for ietf-provreg-outgoing; Tue, 10 Dec 2002 14:44:46 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBADii9p015297 for <[e-mail]>; Tue, 10 Dec 2002 14:44:44 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA24411; Tue, 10 Dec 2002 08:44:42 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <YRRVPSPS>; Tue, 10 Dec 2002 08:39:20 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Hong Liu'" <[e-mail]>, [e-mail]
Subject: RE: EPP Compliance (Was Re: lastVerified: optional vs. extension)
Date: Tue, 10 Dec 2002 08:43:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBADCQ9p015061 for <[e-mail]>; Tue, 10 Dec 2002 14:12:26 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gBADCPYV015060 for ietf-provreg-outgoing; Tue, 10 Dec 2002 14:12:25 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from web14310.mail.yahoo.com (web14310.mail.yahoo.com [216.136.224.60]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gBADCO9p015055 for <[e-mail]>; Tue, 10 Dec 2002 14:12:24 +0100 (MET)
Message-ID: <[e-mail]>
Received: from [159.226.7.85] by web14310.mail.yahoo.com via HTTP; Tue, 10 Dec 2002 05:12:22 PST
Date: Tue, 10 Dec 2002 05:12:22 -0800 (PST)
From: Hong Liu <[e-mail]>
Subject: RE: EPP Compliance (Was Re: lastVerified: optional vs. extension)
To: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

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" <[e-mail]>
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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBABjD9p014393 for <[e-mail]>; Tue, 10 Dec 2002 12:45:13 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gBABjDGv014392 for ietf-provreg-outgoing; Tue, 10 Dec 2002 12:45:13 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gBABjC9p014387 for <[e-mail]>; Tue, 10 Dec 2002 12:45:12 +0100 (MET)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id gBABj8kS817598; Tue, 10 Dec 2002 12:45:08 +0100 (CET)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id EE62710F13; Tue, 10 Dec 2002 12:45:07 +0100 (CET)
Date: Tue, 10 Dec 2002 12:45:07 +0100
From: Stephane Bortzmeyer <[e-mail]>
To: Rick Wesson <[e-mail]>
Cc: Hong Liu <[e-mail]>, [e-mail]
Subject: Re: lastVerified: optional vs. extension
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.28i
X-Operating-System: Debian GNU/Linux 3.0
X-Kernel: Linux 2.4.18-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
Sender: [e-mail]
Precedence: bulk

On Mon, Dec 09, 2002 at 08:39:19AM -0800,
 Rick Wesson <[e-mail]> 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.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9L1B9p007521 for <[e-mail]>; Mon, 9 Dec 2002 22:01:11 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB9L1BcU007520 for ietf-provreg-outgoing; Mon, 9 Dec 2002 22:01:11 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9L1A9p007515 for <[e-mail]>; Mon, 9 Dec 2002 22:01:11 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id QAA01545; Mon, 9 Dec 2002 16:01:09 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <YRRV399Z>; Mon, 9 Dec 2002 15:55:49 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Hong Liu'" <[e-mail]>, [e-mail]
Subject: RE: EPP Compliance (Was Re: lastVerified: optional vs. extension)
Date: Mon, 9 Dec 2002 16:00:09 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9K2U9p007038 for <[e-mail]>; Mon, 9 Dec 2002 21:02:30 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB9K2UKg007037 for ietf-provreg-outgoing; Mon, 9 Dec 2002 21:02:30 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from web14302.mail.yahoo.com (web14302.mail.yahoo.com [216.136.173.78]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gB9K2S9p007029 for <[e-mail]>; Mon, 9 Dec 2002 21:02:29 +0100 (MET)
Message-ID: <[e-mail]>
Received: from [211.150.221.195] by web14302.mail.yahoo.com via HTTP; Mon, 09 Dec 2002 12:02:28 PST
Date: Mon, 9 Dec 2002 12:02:28 -0800 (PST)
From: Hong Liu <[e-mail]>
Subject: EPP Compliance (Was Re: lastVerified: optional vs. extension)
To: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9GdM9p004991 for <[e-mail]>; Mon, 9 Dec 2002 17:39:22 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB9GdMvi004990 for ietf-provreg-outgoing; Mon, 9 Dec 2002 17:39:22 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9GdK9p004985 for <[e-mail]>; Mon, 9 Dec 2002 17:39:21 +0100 (MET)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id gB9GdJSQ010744; Mon, 9 Dec 2002 08:39:19 -0800 (PST)
Date: Mon, 9 Dec 2002 08:39:19 -0800 (PST)
From: Rick Wesson <[e-mail]>
To: Hong Liu <[e-mail]>
cc: <[e-mail]>
Subject: RE: lastVerified: optional vs. extension
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Hong,


> As I 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







Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9GEr9p004622 for <[e-mail]>; Mon, 9 Dec 2002 17:14:53 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB9GErSV004621 for ietf-provreg-outgoing; Mon, 9 Dec 2002 17:14:53 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9GEq9p004616 for <[e-mail]>; Mon, 9 Dec 2002 17:14:52 +0100 (MET)
Received: from dev3.int.libertyrms.com ([10.1.2.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 18LQYO-0003gn-00; Mon, 09 Dec 2002 11:14:44 -0500
Message-ID: <[e-mail]>
Date: Mon, 09 Dec 2002 11:22:44 -0500
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3custom i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Rick Wesson <[e-mail]>
CC: Hong Liu <[e-mail]>, "'[e-mail]'" <[e-mail]>, Ram Mohan <[e-mail]>
Subject: Re: lastVerified: optional vs. extension
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9GBr9p004572 for <[e-mail]>; Mon, 9 Dec 2002 17:11:53 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB9GBrJO004571 for ietf-provreg-outgoing; Mon, 9 Dec 2002 17:11:53 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail7.knipp.de (mail7.knipp.de [195.253.6.55]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9GBp9p004565 for <[e-mail]>; Mon, 9 Dec 2002 17:11:51 +0100 (MET)
Received: (from root@localhost) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) id RAA10595; Mon, 9 Dec 2002 17:11:48 +0100 (MET)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id RAA10587; Mon, 9 Dec 2002 17:11:46 +0100 (MET)
Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id RAA19428; Mon, 9 Dec 2002 17:11:45 +0100 (MET)
Message-ID: <[e-mail]>
Date: Mon, 09 Dec 2002 17:12:14 +0100
From: Klaus Malorny <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20021205
X-Accept-Language: en, de
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>
CC: [e-mail]
Subject: Re: lastVerified: optional vs. extension
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by AMaViS perl-11
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id gB9GBp9p004566
Sender: [e-mail]
Precedence: bulk

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




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9G8a9p004515 for <[e-mail]>; Mon, 9 Dec 2002 17:08:36 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB9G8aq5004514 for ietf-provreg-outgoing; Mon, 9 Dec 2002 17:08:36 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9G8Y9p004509 for <[e-mail]>; Mon, 9 Dec 2002 17:08:35 +0100 (MET)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id gB9G8VSQ010500; Mon, 9 Dec 2002 08:08:31 -0800 (PST)
Date: Mon, 9 Dec 2002 08:08:31 -0800 (PST)
From: Rick Wesson <[e-mail]>
To: janusz sienkiewicz <[e-mail]>
cc: Hong Liu <[e-mail]>, "'[e-mail]'" <[e-mail]>, Ram Mohan <[e-mail]>
Subject: Re: lastVerified: optional vs. extension
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On 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




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9FuI9p004320 for <[e-mail]>; Mon, 9 Dec 2002 16:56:18 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB9FuHHR004319 for ietf-provreg-outgoing; Mon, 9 Dec 2002 16:56:17 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9FuG9p004314 for <[e-mail]>; Mon, 9 Dec 2002 16:56:17 +0100 (MET)
Received: from dev3.int.libertyrms.com ([10.1.2.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 18LQGV-0003RG-00; Mon, 09 Dec 2002 10:56:15 -0500
Message-ID: <[e-mail]>
Date: Mon, 09 Dec 2002 11:04:16 -0500
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3custom i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Hong Liu <[e-mail]>
CC: [e-mail]
Subject: Re: lastVerified: optional vs. extension
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9FGQ9p003794 for <[e-mail]>; Mon, 9 Dec 2002 16:16:26 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB9FGQfk003793 for ietf-provreg-outgoing; Mon, 9 Dec 2002 16:16:26 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9FGP9p003788 for <[e-mail]>; Mon, 9 Dec 2002 16:16:25 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA04162; Mon, 9 Dec 2002 10:16:23 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <YRRV3MR7>; Mon, 9 Dec 2002 10:11:04 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Klaus Malorny'" <[e-mail]>
Cc: [e-mail]
Subject: RE: lastVerified: optional vs. extension
Date: Mon, 9 Dec 2002 10:15:24 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9F379p003614 for <[e-mail]>; Mon, 9 Dec 2002 16:03:07 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB9F37Uv003613 for ietf-provreg-outgoing; Mon, 9 Dec 2002 16:03:07 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9F359p003608 for <[e-mail]>; Mon, 9 Dec 2002 16:03:06 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA03212; Mon, 9 Dec 2002 10:03:03 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <YRRV3MHK>; Mon, 9 Dec 2002 09:57:43 -0500
Message-ID: <[e-mail]>
From: "Gould, James" <[e-mail]>
To: "'Stephane Bortzmeyer'" <[e-mail]>, Joe Abley <[e-mail]>
Cc: [e-mail]
Subject: RE: Standard mappings hardwired in EPP servers? (Was: lastVerifie d: optional vs. extension
Date: Mon, 9 Dec 2002 10:02:02 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
Sent: Monday, December 09, 2002 4:58 AM
To: Joe Abley
Cc: [e-mail]
Subject: Standard mappings hardwired in EPP servers? (Was: lastVerified:
optional vs. extension


On Fri, Dec 06, 2002 at 10:59:11AM -0500,
 Joe Abley <[e-mail]> 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...


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9EnI9p003448 for <[e-mail]>; Mon, 9 Dec 2002 15:49:18 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB9EnICQ003447 for ietf-provreg-outgoing; Mon, 9 Dec 2002 15:49:18 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail7.knipp.de (mail7.knipp.de [195.253.6.55]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9EnH9p003442 for <[e-mail]>; Mon, 9 Dec 2002 15:49:17 +0100 (MET)
Received: (from root@localhost) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) id PAA00990; Mon, 9 Dec 2002 15:49:13 +0100 (MET)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id PAA22486; Mon, 9 Dec 2002 15:13:46 +0100 (MET)
Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id OAA26865; Mon, 9 Dec 2002 14:41:34 +0100 (MET)
Message-ID: <[e-mail]>
Date: Mon, 09 Dec 2002 14:42:04 +0100
From: Klaus Malorny <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20021205
X-Accept-Language: en, de
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>
CC: [e-mail]
Subject: Re: lastVerified: optional vs. extension
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by AMaViS perl-11
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id gB9EnI9p003443
Sender: [e-mail]
Precedence: bulk

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





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9Cqr9p002585 for <[e-mail]>; Mon, 9 Dec 2002 13:52:53 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB9CqrOv002584 for ietf-provreg-outgoing; Mon, 9 Dec 2002 13:52:53 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9Cqq9p002579 for <[e-mail]>; Mon, 9 Dec 2002 13:52:52 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA28253; Mon, 9 Dec 2002 07:52:49 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <YMR99F26>; Mon, 9 Dec 2002 07:52:05 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Klaus Malorny'" <[e-mail]>
Cc: [e-mail]
Subject: RE: lastVerified: optional vs. extension
Date: Mon, 9 Dec 2002 07:51:42 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> I'm not 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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9C6w9p002308 for <[e-mail]>; Mon, 9 Dec 2002 13:06:58 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB9C6vx9002307 for ietf-provreg-outgoing; Mon, 9 Dec 2002 13:06:57 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail7.knipp.de (mail7.knipp.de [195.253.6.55]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9C6u9p002302 for <[e-mail]>; Mon, 9 Dec 2002 13:06:56 +0100 (MET)
Received: (from root@localhost) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) id NAA29276; Mon, 9 Dec 2002 13:06:50 +0100 (MET)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id NAA29268; Mon, 9 Dec 2002 13:06:48 +0100 (MET)
Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id NAA25324; Mon, 9 Dec 2002 13:06:45 +0100 (MET)
Message-ID: <[e-mail]>
Date: Mon, 09 Dec 2002 13:07:15 +0100
From: Klaus Malorny <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20021205
X-Accept-Language: en, de
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>
CC: [e-mail]
Subject: Re: lastVerified: optional vs. extension
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by AMaViS perl-11
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id gB9C6v9p002303
Sender: [e-mail]
Precedence: bulk

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




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9Ai59p001855 for <[e-mail]>; Mon, 9 Dec 2002 11:44:05 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB9Ai54c001854 for ietf-provreg-outgoing; Mon, 9 Dec 2002 11:44:05 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nohope.patoche.org (nohope.patoche.org [80.67.173.199]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9Ai49p001849 for <[e-mail]>; Mon, 9 Dec 2002 11:44:04 +0100 (MET)
Received: from nohope.patoche.org (localhost.gandi.net [127.0.0.1]) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) with ESMTP id gB9Ahx9P009904 for <[e-mail]>; Mon, 9 Dec 2002 11:43:59 +0100
Received: (from patrick@localhost) by nohope.patoche.org (8.12.1/8.12.1/Debian -5) id gB9AhxsU009902 for [e-mail]; Mon, 9 Dec 2002 11:43:59 +0100
Date: Mon, 9 Dec 2002 11:43:59 +0100
From: Patrick <[e-mail]>
To: [e-mail]
Subject: Re: Standard mappings hardwired in EPP servers? (Was: lastVerified: optional vs. extension
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.24i
X-PGP-KeyID: A241FB6B
X-PGP-Fingerprint: 9DA9 5054 7A5D 03FC A9AD  9AFF 1371 9F06 A241 FB6B
X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B
Organization: Gandi
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB9AG79p001646 for <[e-mail]>; Mon, 9 Dec 2002 11:16:07 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB9AG7fg001643 for ietf-provreg-outgoing; Mon, 9 Dec 2002 11:16:07 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from web14310.mail.yahoo.com (web14310.mail.yahoo.com [216.136.224.60]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gB9AG59p001634 for <[e-mail]>; Mon, 9 Dec 2002 11:16:05 +0100 (MET)
Message-ID: <[e-mail]>
Received: from [159.226.7.85] by web14310.mail.yahoo.com via HTTP; Mon, 09 Dec 2002 02:16:04 PST
Date: Mon, 9 Dec 2002 02:16:04 -0800 (PST)
From: Hong Liu <[e-mail]>
Subject: Re: Standard mappings hardwired in EPP servers? (Was: lastVerified: o ptional vs. extension
To: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

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

--- Stephane Bortzmeyer <[e-mail]> wrote:
> On Fri, Dec 06, 2002 at 10:59:11AM -0500,
>  Joe Abley <[e-mail]> 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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB99w19p001404 for <[e-mail]>; Mon, 9 Dec 2002 10:58:01 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB99w1pf001403 for ietf-provreg-outgoing; Mon, 9 Dec 2002 10:58:01 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB99vl9p001384 for <[e-mail]>; Mon, 9 Dec 2002 10:57:53 +0100 (MET)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id gB99vegV1520431; Mon, 9 Dec 2002 10:57:40 +0100 (CET)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id 5A45AFF9F; Mon,  9 Dec 2002 10:57:40 +0100 (CET)
Date: Mon, 9 Dec 2002 10:57:40 +0100
From: Stephane Bortzmeyer <[e-mail]>
To: Joe Abley <[e-mail]>
Cc: [e-mail]
Subject: Standard mappings hardwired in EPP servers? (Was: lastVerified: optional vs. extension
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.28i
X-Operating-System: Debian GNU/Linux 3.0
X-Kernel: Linux 2.4.18-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
Sender: [e-mail]
Precedence: bulk

On Fri, Dec 06, 2002 at 10:59:11AM -0500,
 Joe Abley <[e-mail]> 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...



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB99vt9p001401 for <[e-mail]>; Mon, 9 Dec 2002 10:57:55 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB99vtEV001400 for ietf-provreg-outgoing; Mon, 9 Dec 2002 10:57:55 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB99vj9p001383 for <[e-mail]>; Mon, 9 Dec 2002 10:57:53 +0100 (MET)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id gB99vegV1520431; Mon, 9 Dec 2002 10:57:40 +0100 (CET)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id 5A45AFF9F; Mon,  9 Dec 2002 10:57:40 +0100 (CET)
Date: Mon, 9 Dec 2002 10:57:40 +0100
From: Stephane Bortzmeyer <[e-mail]>
To: Joe Abley <[e-mail]>
Cc: [e-mail]
Subject: Standard mappings hardwired in EPP servers? (Was: lastVerified: optional vs. extension
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.28i
X-Operating-System: Debian GNU/Linux 3.0
X-Kernel: Linux 2.4.18-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
Sender: [e-mail]
Precedence: bulk

On Fri, Dec 06, 2002 at 10:59:11AM -0500,
 Joe Abley <[e-mail]> 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...



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB7HBc9p018068 for <[e-mail]>; Sat, 7 Dec 2002 18:11:38 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB7HBcj7018067 for ietf-provreg-outgoing; Sat, 7 Dec 2002 18:11:38 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from web14304.mail.yahoo.com (web14304.mail.yahoo.com [216.136.173.80]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gB7HBa9p018062 for <[e-mail]>; Sat, 7 Dec 2002 18:11:37 +0100 (MET)
Message-ID: <[e-mail]>
Received: from [211.150.229.9] by web14304.mail.yahoo.com via HTTP; Sat, 07 Dec 2002 09:11:36 PST
Date: Sat, 7 Dec 2002 09:11:36 -0800 (PST)
From: Hong Liu <[e-mail]>
Subject: RE: lastVerified: optional vs. extension
To: Rick Wesson <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Rick,

Please see my comments in line. 

Cheers,

--Hong

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB7GeW9p017912 for <[e-mail]>; Sat, 7 Dec 2002 17:40:32 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB7GeW2C017911 for ietf-provreg-outgoing; Sat, 7 Dec 2002 17:40:32 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from web14305.mail.yahoo.com (web14305.mail.yahoo.com [216.136.173.81]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gB7GeU9p017906 for <[e-mail]>; Sat, 7 Dec 2002 17:40:31 +0100 (MET)
Message-ID: <[e-mail]>
Received: from [211.150.229.9] by web14305.mail.yahoo.com via HTTP; Sat, 07 Dec 2002 08:40:29 PST
Date: Sat, 7 Dec 2002 08:40:29 -0800 (PST)
From: Hong Liu <[e-mail]>
Subject: Re: lastVerified: optional vs. extension
To: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB7GZu9p017891 for <[e-mail]>; Sat, 7 Dec 2002 17:35:56 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB7GZunO017890 for ietf-provreg-outgoing; Sat, 7 Dec 2002 17:35:56 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB7GZt9p017885 for <[e-mail]>; Sat, 7 Dec 2002 17:35:55 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA23705; Sat, 7 Dec 2002 11:35:52 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <V87KJC1P>; Sat, 7 Dec 2002 11:30:36 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Klaus Malorny'" <[e-mail]>
Cc: [e-mail]
Subject: RE: * excuse * was:  Re: lastVerified: optional vs. extension
Date: Sat, 7 Dec 2002 11:34:51 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB7GXe9p017877 for <[e-mail]>; Sat, 7 Dec 2002 17:33:40 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB7GXeVJ017876 for ietf-provreg-outgoing; Sat, 7 Dec 2002 17:33:40 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB7GXd9p017871 for <[e-mail]>; Sat, 7 Dec 2002 17:33:40 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA23693; Sat, 7 Dec 2002 11:33:35 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <YMR98HVX>; Sat, 7 Dec 2002 11:32:54 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Klaus Malorny'" <[e-mail]>
Cc: [e-mail]
Subject: RE: lastVerified: optional vs. extension
Date: Sat, 7 Dec 2002 11:32:39 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB7DwI9p017154 for <[e-mail]>; Sat, 7 Dec 2002 14:58:18 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB7DwI2l017153 for ietf-provreg-outgoing; Sat, 7 Dec 2002 14:58:18 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from web14302.mail.yahoo.com (web14302.mail.yahoo.com [216.136.173.78]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gB7DwH9p017148 for <[e-mail]>; Sat, 7 Dec 2002 14:58:17 +0100 (MET)
Message-ID: <[e-mail]>
Received: from [211.150.179.234] by web14302.mail.yahoo.com via HTTP; Sat, 07 Dec 2002 05:58:16 PST
Date: Sat, 7 Dec 2002 05:58:16 -0800 (PST)
From: Hong Liu <[e-mail]>
Subject: Re: lastVerified: optional vs. extension
To: [e-mail]
In-Reply-To: <a05111b11ba16dfd8af91@[192.149.252.235]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]> 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                                        
>  [phone]
> ARIN Research Engineer


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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6NbJ9p012355 for <[e-mail]>; Sat, 7 Dec 2002 00:37:19 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB6NbJPe012354 for ietf-provreg-outgoing; Sat, 7 Dec 2002 00:37:19 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6NbH9p012348 for <[e-mail]>; Sat, 7 Dec 2002 00:37:18 +0100 (MET)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id gB6NbFSQ020116; Fri, 6 Dec 2002 15:37:15 -0800 (PST)
Date: Fri, 6 Dec 2002 15:37:15 -0800 (PST)
From: Rick Wesson <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: Michael Graff <[e-mail]>, <[e-mail]>
Subject: Re: lastVerified: optional vs. extension
In-Reply-To: <a05111b11ba16dfd8af91@[192.149.252.235]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> 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





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6NGE9p012137 for <[e-mail]>; Sat, 7 Dec 2002 00:16:14 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB6NGExa012136 for ietf-provreg-outgoing; Sat, 7 Dec 2002 00:16:14 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6NGD9p012131 for <[e-mail]>; Sat, 7 Dec 2002 00:16:13 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gB6NGAYm075615; Fri, 6 Dec 2002 18:16:10 -0500 (EST)
Received: from [192.149.252.235] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id SAA08944; Fri, 6 Dec 2002 18:16:09 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b11ba16dfd8af91@[192.149.252.235]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <a05111b08ba167b111106@[192.149.252.235]> <[e-mail]>
Date: Fri, 6 Dec 2002 18:16:47 -0500
To: Michael Graff <[e-mail]>, Edward Lewis <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: lastVerified: optional vs. extension
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6MHU9p011475 for <[e-mail]>; Fri, 6 Dec 2002 23:17:30 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB6MHUMp011474 for ietf-provreg-outgoing; Fri, 6 Dec 2002 23:17:30 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail7.knipp.de (mail7.knipp.de [195.253.6.55]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6MHT9p011469 for <[e-mail]>; Fri, 6 Dec 2002 23:17:29 +0100 (MET)
Received: (from root@localhost) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) id XAA25173; Fri, 6 Dec 2002 23:17:24 +0100 (MET)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id XAA25165; Fri, 6 Dec 2002 23:17:22 +0100 (MET)
Received: from knipp.de (hp9000.do.knipp.de [195.253.2.54]) by hp9000.do.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id XAA18455; Fri, 6 Dec 2002 23:17:21 +0100 (MET)
Message-ID: <[e-mail]>
Date: Fri, 06 Dec 2002 23:20:49 +0100
From: Klaus Malorny <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021126
X-Accept-Language: en, de
MIME-Version: 1.0
To: Edward Lewis <[e-mail]>
CC: "Hollenbeck, Scott" <[e-mail]>, [e-mail]
Subject: Re: objections, was Re: lastVerified: optional vs. extension
References: <[e-mail]> <[e-mail]> <a05111b06ba1674066a47@[192.149.252.235]>
In-Reply-To: <a05111b06ba1674066a47@[192.149.252.235]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

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




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6M5c9p011368 for <[e-mail]>; Fri, 6 Dec 2002 23:05:38 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB6M5cml011367 for ietf-provreg-outgoing; Fri, 6 Dec 2002 23:05:38 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail7.knipp.de (mail7.knipp.de [195.253.6.55]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6M5b9p011362 for <[e-mail]>; Fri, 6 Dec 2002 23:05:37 +0100 (MET)
Received: (from root@localhost) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) id XAA24308; Fri, 6 Dec 2002 23:05:32 +0100 (MET)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id XAA24300; Fri, 6 Dec 2002 23:05:30 +0100 (MET)
Received: from knipp.de (hp9000.do.knipp.de [195.253.2.54]) by hp9000.do.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id XAA13888; Fri, 6 Dec 2002 23:05:29 +0100 (MET)
Message-ID: <[e-mail]>
Date: Fri, 06 Dec 2002 23:08:57 +0100
From: Klaus Malorny <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021126
X-Accept-Language: en, de
MIME-Version: 1.0
To: Klaus Malorny <[e-mail]>
CC: "Hollenbeck, Scott" <[e-mail]>, [e-mail]
Subject: * excuse * was:  Re: lastVerified: optional vs. extension
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

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




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6LSA9p010882 for <[e-mail]>; Fri, 6 Dec 2002 22:28:10 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB6LSA71010881 for ietf-provreg-outgoing; Fri, 6 Dec 2002 22:28:10 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail7.knipp.de (mail7.knipp.de [195.253.6.55]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6LS99p010876 for <[e-mail]>; Fri, 6 Dec 2002 22:28:09 +0100 (MET)
Received: (from root@localhost) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) id WAA23369; Fri, 6 Dec 2002 22:28:06 +0100 (MET)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id WAA23361; Fri, 6 Dec 2002 22:28:04 +0100 (MET)
Received: from knipp.de (hp9000.do.knipp.de [195.253.2.54]) by hp9000.do.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id WAA28215; Fri, 6 Dec 2002 22:28:02 +0100 (MET)
Message-ID: <[e-mail]>
Date: Fri, 06 Dec 2002 22:31:30 +0100
From: Klaus Malorny <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021126
X-Accept-Language: en, de
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>
CC: [e-mail]
Subject: Re: lastVerified: optional vs. extension
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

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





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6Knq9p010453 for <[e-mail]>; Fri, 6 Dec 2002 21:49:52 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB6Knq7W010452 for ietf-provreg-outgoing; Fri, 6 Dec 2002 21:49:52 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from isrv4.isc.org (isrv4.isc.org [204.152.184.27]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6Knp9p010447 for <[e-mail]>; Fri, 6 Dec 2002 21:49:51 +0100 (MET)
Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by isrv4.isc.org (Postfix) with ESMTP id E20AB1FC3; Fri,  6 Dec 2002 20:49:49 +0000 (UTC) (envelope-from [e-mail])
Received: by farside.isc.org (Postfix, from userid 10015) id CA370AA75; Fri,  6 Dec 2002 20:49:49 +0000 (UTC)
To: Edward Lewis <[e-mail]>
Cc: [e-mail]
Subject: Re: lastVerified: optional vs. extension
References: <[e-mail]> <a05111b08ba167b111106@[192.149.252.235]>
From: Michael Graff <[e-mail]>
Date: 06 Dec 2002 20:49:49 +0000
In-Reply-To: <a05111b08ba167b111106@[192.149.252.235]>
Message-ID: <[e-mail]>
Lines: 33
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

I 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 <[e-mail]> 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                                          [phone]
> ARIN Research Engineer


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6KXc9p010308 for <[e-mail]>; Fri, 6 Dec 2002 21:33:38 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB6KXcHr010307 for ietf-provreg-outgoing; Fri, 6 Dec 2002 21:33:38 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail7.knipp.de (mail7.knipp.de [195.253.6.55]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6KXa9p010302 for <[e-mail]>; Fri, 6 Dec 2002 21:33:37 +0100 (MET)
Received: (from root@localhost) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) id VAA22068; Fri, 6 Dec 2002 21:33:33 +0100 (MET)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id VAA22060; Fri, 6 Dec 2002 21:33:31 +0100 (MET)
Received: from knipp.de (hp9000.do.knipp.de [195.253.2.54]) by hp9000.do.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id VAA11030; Fri, 6 Dec 2002 21:33:29 +0100 (MET)
Message-ID: <[e-mail]>
Date: Fri, 06 Dec 2002 21:36:57 +0100
From: Klaus Malorny <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021126
X-Accept-Language: en, de
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>
CC: [e-mail]
Subject: Re: lastVerified: optional vs. extension
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

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






Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6KIr9p010157 for <[e-mail]>; Fri, 6 Dec 2002 21:18:53 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB6KIrAa010156 for ietf-provreg-outgoing; Fri, 6 Dec 2002 21:18:53 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6KIq9p010151 for <[e-mail]>; Fri, 6 Dec 2002 21:18:52 +0100 (MET)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id gB6KIoSQ018649; Fri, 6 Dec 2002 12:18:51 -0800 (PST)
Date: Fri, 6 Dec 2002 12:18:50 -0800 (PST)
From: Rick Wesson <[e-mail]>
To: Hong Liu <[e-mail]>
cc: <[e-mail]>
Subject: RE: lastVerified: optional vs. extension
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On 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





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6Jtp9p009878 for <[e-mail]>; Fri, 6 Dec 2002 20:55:51 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB6Jtpti009877 for ietf-provreg-outgoing; Fri, 6 Dec 2002 20:55:51 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6Jto9p009872 for <[e-mail]>; Fri, 6 Dec 2002 20:55:50 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA28720; Fri, 6 Dec 2002 14:55:48 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <V87K2X48>; Fri, 6 Dec 2002 14:50:34 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Joe Abley'" <[e-mail]>, [e-mail]
Subject: RE: lastVerified: optional vs. extension
Date: Fri, 6 Dec 2002 14:54:53 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6HCf9p008316 for <[e-mail]>; Fri, 6 Dec 2002 18:12:41 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB6HCf8w008315 for ietf-provreg-outgoing; Fri, 6 Dec 2002 18:12:41 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from fep02-mail.bloor.is.net.cable.rogers.com (fep02-mail.bloor.is.net.cable.rogers.com [66.185.86.72]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6HCd9p008310 for <[e-mail]>; Fri, 6 Dec 2002 18:12:40 +0100 (MET)
Received: from isc.org ([24.103.90.17]) by fep02-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <[e-mail]> for <[e-mail]>; Fri, 6 Dec 2002 12:12:34 -0500
Date: Fri, 6 Dec 2002 12:12:39 -0500
Subject: Re: lastVerified: optional vs. extension
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v548)
From: Joe Abley <[e-mail]>
To: [e-mail]
Content-Transfer-Encoding: 7bit
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
X-Mailer: Apple Mail (2.548)
X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep02-mail.bloor.is.net.cable.rogers.com from [24.103.90.17] using ID <[e-mail]> at Fri, 6 Dec 2002 12:12:33 -0500
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6GOT9p007840 for <[e-mail]>; Fri, 6 Dec 2002 17:24:29 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB6GOTDu007839 for ietf-provreg-outgoing; Fri, 6 Dec 2002 17:24:29 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from fep02-mail.bloor.is.net.cable.rogers.com (fep02-mail.bloor.is.net.cable.rogers.com [66.185.86.72]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6GOR9p007834 for <[e-mail]>; Fri, 6 Dec 2002 17:24:28 +0100 (MET)
Received: from isc.org ([24.103.90.17]) by fep02-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <[e-mail]>; Fri, 6 Dec 2002 11:24:21 -0500
Date: Fri, 6 Dec 2002 11:24:27 -0500
Subject: Re: lastVerified: optional vs. extension
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v548)
Cc: "Hollenbeck, Scott" <[e-mail]>, [e-mail]
To: Klaus Malorny <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.548)
X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep02-mail.bloor.is.net.cable.rogers.com from [24.103.90.17] using ID <[e-mail]> at Fri, 6 Dec 2002 11:24:21 -0500
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6GFn9p007765 for <[e-mail]>; Fri, 6 Dec 2002 17:15:49 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB6GFnEk007764 for ietf-provreg-outgoing; Fri, 6 Dec 2002 17:15:49 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6GFm9p007759 for <[e-mail]>; Fri, 6 Dec 2002 17:15:48 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA16756; Fri, 6 Dec 2002 11:15:46 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <V5CJKR6D>; Fri, 6 Dec 2002 11:15:06 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Klaus Malorny'" <[e-mail]>
Cc: [e-mail]
Subject: RE: lastVerified: optional vs. extension
Date: Fri, 6 Dec 2002 11:14:51 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6G8B9p007670 for <[e-mail]>; Fri, 6 Dec 2002 17:08:11 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB6G8BpM007669 for ietf-provreg-outgoing; Fri, 6 Dec 2002 17:08:11 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6G899p007664 for <[e-mail]>; Fri, 6 Dec 2002 17:08:10 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gB6G89Ym053274; Fri, 6 Dec 2002 11:08:09 -0500 (EST)
Received: from [192.149.252.235] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA15017; Fri, 6 Dec 2002 11:08:07 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b08ba167b111106@[192.149.252.235]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 6 Dec 2002 11:08:42 -0500
To: Hong Liu <[e-mail]>, [e-mail]
From: Edward Lewis <[e-mail]>
Subject: RE: lastVerified: optional vs. extension
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6G5M9p007627 for <[e-mail]>; Fri, 6 Dec 2002 17:05:22 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB6G5MFP007626 for ietf-provreg-outgoing; Fri, 6 Dec 2002 17:05:22 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6G5L9p007621 for <[e-mail]>; Fri, 6 Dec 2002 17:05:21 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA16044; Fri, 6 Dec 2002 11:05:18 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <V87K2SJB>; Fri, 6 Dec 2002 11:00:05 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Klaus Malorny'" <[e-mail]>
Cc: [e-mail]
Subject: RE: lastVerified: optional vs. extension
Date: Fri, 6 Dec 2002 11:04:22 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6G269p007594 for <[e-mail]>; Fri, 6 Dec 2002 17:02:06 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB6G26ee007593 for ietf-provreg-outgoing; Fri, 6 Dec 2002 17:02:06 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from web14301.mail.yahoo.com (web14301.mail.yahoo.com [216.136.173.77]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gB6G249p007584 for <[e-mail]>; Fri, 6 Dec 2002 17:02:04 +0100 (MET)
Message-ID: <[e-mail]>
Received: from [211.150.229.119] by web14301.mail.yahoo.com via HTTP; Fri, 06 Dec 2002 08:02:03 PST
Date: Fri, 6 Dec 2002 08:02:03 -0800 (PST)
From: Hong Liu <[e-mail]>
Subject: RE: lastVerified: optional vs. extension
To: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

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

--- "Hollenbeck, Scott" <[e-mail]>
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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6FxD9p007520 for <[e-mail]>; Fri, 6 Dec 2002 16:59:13 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB6FxDSs007519 for ietf-provreg-outgoing; Fri, 6 Dec 2002 16:59:13 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from fep03-mail.bloor.is.net.cable.rogers.com (fep03-mail.bloor.is.net.cable.rogers.com [66.185.86.73]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6FxC9p007511 for <[e-mail]>; Fri, 6 Dec 2002 16:59:12 +0100 (MET)
Received: from isc.org ([24.103.90.17]) by fep03-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <[e-mail]>; Fri, 6 Dec 2002 10:59:10 -0500
Date: Fri, 6 Dec 2002 10:59:11 -0500
Subject: Re: lastVerified: optional vs. extension
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v548)
Cc: "'Klaus Malorny'" <[e-mail]>, [e-mail]
To: "Hollenbeck, Scott" <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.548)
X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.103.90.17] using ID <[e-mail]> at Fri, 6 Dec 2002 10:59:10 -0500
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6FkT9p007296 for <[e-mail]>; Fri, 6 Dec 2002 16:46:29 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB6FkTv2007295 for ietf-provreg-outgoing; Fri, 6 Dec 2002 16:46:29 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6FkS9p007288 for <[e-mail]>; Fri, 6 Dec 2002 16:46:28 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gB6FkPYm052403; Fri, 6 Dec 2002 10:46:25 -0500 (EST)
Received: from [192.149.252.235] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA11544; Fri, 6 Dec 2002 10:46:24 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b06ba1674066a47@[192.149.252.235]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]> <[e-mail]>
Date: Fri, 6 Dec 2002 10:47:00 -0500
To: Klaus Malorny <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject:  objections, was Re: lastVerified: optional vs. extension
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6FP79p007089 for <[e-mail]>; Fri, 6 Dec 2002 16:25:07 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB6FP7SY007088 for ietf-provreg-outgoing; Fri, 6 Dec 2002 16:25:07 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail7.knipp.de (mail7.knipp.de [195.253.6.55]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6FP69p007083 for <[e-mail]>; Fri, 6 Dec 2002 16:25:06 +0100 (MET)
Received: (from root@localhost) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) id QAA29696; Fri, 6 Dec 2002 16:25:02 +0100 (MET)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id QAA29554; Fri, 6 Dec 2002 16:24:45 +0100 (MET)
Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id QAA28133; Fri, 6 Dec 2002 16:24:44 +0100 (MET)
Message-ID: <[e-mail]>
Date: Fri, 06 Dec 2002 16:25:06 +0100
From: Klaus Malorny <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20021205
X-Accept-Language: en, de
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>
CC: [e-mail]
Subject: Re: lastVerified: optional vs. extension
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by AMaViS perl-11
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id gB6FP79p007084
Sender: [e-mail]
Precedence: bulk

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





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6CrO9p005891 for <[e-mail]>; Fri, 6 Dec 2002 13:53:24 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB6CrOLI005890 for ietf-provreg-outgoing; Fri, 6 Dec 2002 13:53:24 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6CrN9p005885 for <[e-mail]>; Fri, 6 Dec 2002 13:53:24 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA07796; Fri, 6 Dec 2002 07:53:22 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <V5CJKM31>; Fri, 6 Dec 2002 07:52:42 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, [e-mail]
Subject: RE: lastVerified: optional vs. extension
Date: Fri, 6 Dec 2002 07:52:28 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6Clt9p005820 for <[e-mail]>; Fri, 6 Dec 2002 13:47:55 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB6Cltd1005819 for ietf-provreg-outgoing; Fri, 6 Dec 2002 13:47:55 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB6Cls9p005814 for <[e-mail]>; Fri, 6 Dec 2002 13:47:54 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA07704; Fri, 6 Dec 2002 07:47:41 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <V5CJKMJ0>; Fri, 6 Dec 2002 07:47:01 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Klaus Malorny'" <[e-mail]>
Cc: [e-mail]
Subject: RE: lastVerified: optional vs. extension
Date: Fri, 6 Dec 2002 07:46:47 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB69Vb9p004649 for <[e-mail]>; Fri, 6 Dec 2002 10:31:37 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB69VaEJ004648 for ietf-provreg-outgoing; Fri, 6 Dec 2002 10:31:36 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail7.knipp.de (mail7.knipp.de [195.253.6.55]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB69VZ9p004643 for <[e-mail]>; Fri, 6 Dec 2002 10:31:36 +0100 (MET)
Received: (from root@localhost) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) id KAA12965; Fri, 6 Dec 2002 10:31:31 +0100 (MET)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by mail7.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id KAA12955; Fri, 6 Dec 2002 10:31:29 +0100 (MET)
Received: from knipp.de (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (8.9.3 (PHNE_25184)/8.9.3) with ESMTP id KAA29574; Fri, 6 Dec 2002 10:31:27 +0100 (MET)
Message-ID: <[e-mail]>
Date: Fri, 06 Dec 2002 10:31:52 +0100
From: Klaus Malorny <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20021203
X-Accept-Language: en, de
MIME-Version: 1.0
To: Hong Liu <[e-mail]>
CC: [e-mail]
Subject: Re: lastVerified: optional vs. extension
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by AMaViS perl-11
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id gB69Va9p004644
Sender: [e-mail]
Precedence: bulk

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





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB67rU9p003898 for <[e-mail]>; Fri, 6 Dec 2002 08:53:30 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB67rUL4003897 for ietf-provreg-outgoing; Fri, 6 Dec 2002 08:53:30 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB67rS9p003892 for <[e-mail]>; Fri, 6 Dec 2002 08:53:29 +0100 (MET)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id gB67rPSQ014802; Thu, 5 Dec 2002 23:53:25 -0800 (PST)
Date: Thu, 5 Dec 2002 23:53:25 -0800 (PST)
From: Rick Wesson <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: Hong Liu <[e-mail]>, <[e-mail]>
Subject: Re: lastVerified: optional vs. extension
In-Reply-To: <a05111b0fba15d41f7acf@[66.44.62.225]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> 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




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB64OS9p002798 for <[e-mail]>; Fri, 6 Dec 2002 05:24:28 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB64ORlF002797 for ietf-provreg-outgoing; Fri, 6 Dec 2002 05:24:27 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB64OQ9p002792 for <[e-mail]>; Fri, 6 Dec 2002 05:24:27 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gB64OQYm043449; Thu, 5 Dec 2002 23:24:26 -0500 (EST)
Received: from [66.44.62.225] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id XAA25347; Thu, 5 Dec 2002 23:24:16 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b0fba15d41f7acf@[66.44.62.225]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 5 Dec 2002 23:24:47 -0500
To: Hong Liu <[e-mail]>, [e-mail]
From: Edward Lewis <[e-mail]>
Subject: Re: lastVerified: optional vs. extension
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB646c9p002706 for <[e-mail]>; Fri, 6 Dec 2002 05:06:38 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB646cNf002705 for ietf-provreg-outgoing; Fri, 6 Dec 2002 05:06:38 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from web14308.mail.yahoo.com (web14308.mail.yahoo.com [216.136.173.156]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gB646a9p002700 for <[e-mail]>; Fri, 6 Dec 2002 05:06:37 +0100 (MET)
Message-ID: <[e-mail]>
Received: from [211.150.227.129] by web14308.mail.yahoo.com via HTTP; Thu, 05 Dec 2002 20:06:35 PST
Date: Thu, 5 Dec 2002 20:06:35 -0800 (PST)
From: Hong Liu <[e-mail]>
Subject: Re: lastVerified: optional vs. extension
To: [e-mail]
In-Reply-To: <a05111b06ba15957ba6f9@[66.44.62.225]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]> 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                                        
>  [phone]
> ARIN Research Engineer
> 


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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB622U9p001060 for <[e-mail]>; Fri, 6 Dec 2002 03:02:30 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB622UfS001059 for ietf-provreg-outgoing; Fri, 6 Dec 2002 03:02:30 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB622S9p001054 for <[e-mail]>; Fri, 6 Dec 2002 03:02:29 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gB622SYm042078; Thu, 5 Dec 2002 21:02:28 -0500 (EST)
Received: from [66.44.62.225] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id VAA16133; Thu, 5 Dec 2002 21:02:14 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b0bba15b4c0fb58@[66.44.62.225]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 5 Dec 2002 21:01:01 -0500
To: Hong Liu <[e-mail]>, [e-mail]
From: Edward Lewis <[e-mail]>
Subject: Re: action items from our meeting in atlanta
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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                                    [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB5Nui9p000149 for <[e-mail]>; Fri, 6 Dec 2002 00:56:44 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB5NuiJt000148 for ietf-provreg-outgoing; Fri, 6 Dec 2002 00:56:44 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB5Nug9p000143 for <[e-mail]>; Fri, 6 Dec 2002 00:56:43 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gB5NugYm040217; Thu, 5 Dec 2002 18:56:42 -0500 (EST)
Received: from [66.44.62.225] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id SAA00047; Thu, 5 Dec 2002 18:56:39 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b06ba15957ba6f9@[66.44.62.225]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 5 Dec 2002 18:57:10 -0500
To: Hong Liu <[e-mail]>, [e-mail]
From: Edward Lewis <[e-mail]>
Subject: Re: lastVerified: optional vs. extension
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB5LMi9p028808 for <[e-mail]>; Thu, 5 Dec 2002 22:22:44 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB5LMiSN028807 for ietf-provreg-outgoing; Thu, 5 Dec 2002 22:22:44 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from web14311.mail.yahoo.com (web14311.mail.yahoo.com [216.136.224.61]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gB5LMg9p028802 for <[e-mail]>; Thu, 5 Dec 2002 22:22:43 +0100 (MET)
Message-ID: <[e-mail]>
Received: from [211.150.223.193] by web14311.mail.yahoo.com via HTTP; Thu, 05 Dec 2002 13:22:40 PST
Date: Thu, 5 Dec 2002 13:22:40 -0800 (PST)
From: Hong Liu <[e-mail]>
Subject: lastVerified: optional vs. extension
To: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB5KCm9p028161 for <[e-mail]>; Thu, 5 Dec 2002 21:12:48 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB5KCmNd028160 for ietf-provreg-outgoing; Thu, 5 Dec 2002 21:12:48 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from fep01-mail.bloor.is.net.cable.rogers.com (fep01-mail.bloor.is.net.cable.rogers.com [66.185.86.71]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB5KCl9p028155 for <[e-mail]>; Thu, 5 Dec 2002 21:12:47 +0100 (MET)
Received: from isc.org ([24.103.90.17]) by fep01-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 5 Dec 2002 15:12:45 -0500
Date: Thu, 5 Dec 2002 15:12:45 -0500
Mime-Version: 1.0 (Apple Message framework v548)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: format of contents of <domain:curExpDate>
From: Joe Abley <[e-mail]>
To: [e-mail]
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
X-Mailer: Apple Mail (2.548)
X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep01-mail.bloor.is.net.cable.rogers.com from [24.103.90.17] using ID <[e-mail]> at Thu, 5 Dec 2002 15:12:45 -0500
Sender: [e-mail]
Precedence: bulk

[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 <[e-mail]>
> Date: Thu Dec 5, 2002  13:16:21 Canada/Eastern
> To: Edward Lewis <[e-mail]>
> Cc: [e-mail], "Hollenbeck, Scott" <[e-mail]>
> 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
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB5K9a9p028104 for <[e-mail]>; Thu, 5 Dec 2002 21:09:36 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB5K9aF3028103 for ietf-provreg-outgoing; Thu, 5 Dec 2002 21:09:36 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB5K9Z9p028098 for <[e-mail]>; Thu, 5 Dec 2002 21:09:35 +0100 (MET)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id gB5K9VSQ010903; Thu, 5 Dec 2002 12:09:31 -0800 (PST)
Date: Thu, 5 Dec 2002 12:09:34 -0800 (PST)
From: Rick Wesson <[e-mail]>
To: Hong Liu <[e-mail]>
cc: <[e-mail]>
Subject: RE: action items from our meeting in atlanta
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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






Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB5K8B9p028085 for <[e-mail]>; Thu, 5 Dec 2002 21:08:11 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB5K8B5Z028084 for ietf-provreg-outgoing; Thu, 5 Dec 2002 21:08:11 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB5K899p028079 for <[e-mail]>; Thu, 5 Dec 2002 21:08:09 +0100 (MET)
Received: from user-2inig0i.dialup.mindspring.com ([165.121.64.18] helo=dick.ix.netcom.com) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 18K2I2-0002fs-00; Thu, 05 Dec 2002 15:08:07 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 05 Dec 2002 15:09:29 -0500
To: "Hollenbeck, Scott" <[e-mail]>, "'Edward Lewis'" <[e-mail]>, [e-mail]
From: Richard Shockey <[e-mail]>
Subject: RE: action items from our meeting in atlanta
Cc: [e-mail]
In-Reply-To: <[e-mail]. netsol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

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:[e-mail]        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: [phone]
<mailto:[e-mail]> or <mailto:[e-mail]>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB5Jnu9p027876 for <[e-mail]>; Thu, 5 Dec 2002 20:49:56 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB5JnuDr027875 for ietf-provreg-outgoing; Thu, 5 Dec 2002 20:49:56 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from web14302.mail.yahoo.com (web14302.mail.yahoo.com [216.136.173.78]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gB5Jns9p027870 for <[e-mail]>; Thu, 5 Dec 2002 20:49:55 +0100 (MET)
Message-ID: <[e-mail]>
Received: from [211.150.226.162] by web14302.mail.yahoo.com via HTTP; Thu, 05 Dec 2002 11:49:54 PST
Date: Thu, 5 Dec 2002 11:49:54 -0800 (PST)
From: Hong Liu <[e-mail]>
Subject: RE: action items from our meeting in atlanta
To: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Scott,

Please see my comments below. Cheers,

--Hong

--- "Hollenbeck, Scott" <[e-mail]>
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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB5GK79p025886 for <[e-mail]>; Thu, 5 Dec 2002 17:20:07 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB5GK76C025885 for ietf-provreg-outgoing; Thu, 5 Dec 2002 17:20:07 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB5GK59p025880 for <[e-mail]>; Thu, 5 Dec 2002 17:20:06 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gB5GK5Ym027775; Thu, 5 Dec 2002 11:20:05 -0500 (EST)
Received: from [66.44.92.134] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA26098; Thu, 5 Dec 2002 11:20:02 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b0cba152bd75ada@[66.44.92.134]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Thu, 5 Dec 2002 11:20:32 -0500
To: "Hollenbeck, Scott" <[e-mail]>, "'Edward Lewis'" <[e-mail]>, [e-mail]
From: Edward Lewis <[e-mail]>
Subject: RE: action items from our meeting in atlanta
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB5G1R9p025697 for <[e-mail]>; Thu, 5 Dec 2002 17:01:27 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB5G1RpY025696 for ietf-provreg-outgoing; Thu, 5 Dec 2002 17:01:27 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB5G1Q9p025691 for <[e-mail]>; Thu, 5 Dec 2002 17:01:26 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA06339; Thu, 5 Dec 2002 11:01:25 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <V87K2AXT>; Thu, 5 Dec 2002 10:56:14 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: action items from our meeting in atlanta
Date: Thu, 5 Dec 2002 11:00:33 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB5Fth9p025657 for <[e-mail]>; Thu, 5 Dec 2002 16:55:43 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB5FthCw025656 for ietf-provreg-outgoing; Thu, 5 Dec 2002 16:55:43 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB5FtB9p025647 for <[e-mail]>; Thu, 5 Dec 2002 16:55:11 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gB5Ft8Ym027052; Thu, 5 Dec 2002 10:55:08 -0500 (EST)
Received: from [66.44.92.134] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA22667; Thu, 5 Dec 2002 10:55:05 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b08ba152130dbb7@[66.44.92.134]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Thu, 5 Dec 2002 10:37:38 -0500
To: "Hollenbeck, Scott" <[e-mail]>, "'Edward Lewis'" <[e-mail]>, [e-mail]
From: Edward Lewis <[e-mail]>
Subject: RE: action items from our meeting in atlanta
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB5Eq89p025243 for <[e-mail]>; Thu, 5 Dec 2002 15:52:08 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB5Eq8d7025242 for ietf-provreg-outgoing; Thu, 5 Dec 2002 15:52:08 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from tomts21-srv.bellnexxia.net (tomts21.bellnexxia.net [209.226.175.183]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB5Eq69p025237 for <[e-mail]>; Thu, 5 Dec 2002 15:52:06 +0100 (MET)
Received: from XP1 ([64.229.99.154]) by tomts21-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021205145205.WFRY4242.tomts21-srv.bellnexxia.net@XP1>; Thu, 5 Dec 2002 09:52:05 -0500
Message-ID: <02cb01c29c6e$211d7730$6402a8c0@XP1>
Reply-To: "Ross Wm. Rader" <[e-mail]>
From: "Ross Wm. Rader" <[e-mail]>
To: "Rick Wesson" <[e-mail]>, "Richard Shockey" <[e-mail]>
Cc: "Edward Lewis" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: action items from our meeting in atlanta
Date: Thu, 5 Dec 2002 09:53:52 -0500
Organization: Tucows Inc.
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk

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" <[e-mail]>
To: "Rick Wesson" <[e-mail]>
Cc: "Edward Lewis" <[e-mail]>; <[e-mail]>;
<[e-mail]>
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: [phone]
> <mailto:[e-mail]> or <mailto:[e-mail]>
>   <http://www.neustar.biz> ; <http://www.enum.org>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB5DsN9p024728 for <[e-mail]>; Thu, 5 Dec 2002 14:54:23 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB5DsNc2024727 for ietf-provreg-outgoing; Thu, 5 Dec 2002 14:54:23 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB5DsL9p024722 for <[e-mail]>; Thu, 5 Dec 2002 14:54:22 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA01415; Thu, 5 Dec 2002 08:54:20 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <V87KH9X5>; Thu, 5 Dec 2002 08:49:09 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: action items from our meeting in atlanta
Date: Thu, 5 Dec 2002 08:53:28 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB5Do29p024677 for <[e-mail]>; Thu, 5 Dec 2002 14:50:02 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB5Do2dw024676 for ietf-provreg-outgoing; Thu, 5 Dec 2002 14:50:02 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB5Do19p024671 for <[e-mail]>; Thu, 5 Dec 2002 14:50:01 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA01255; Thu, 5 Dec 2002 08:49:59 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <V5CJJP3G>; Thu, 5 Dec 2002 08:49:21 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Hong Liu'" <[e-mail]>, [e-mail]
Subject: RE: action items from our meeting in atlanta
Date: Thu, 5 Dec 2002 08:49:07 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB568u9p021826 for <[e-mail]>; Thu, 5 Dec 2002 07:08:56 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB568uXx021825 for ietf-provreg-outgoing; Thu, 5 Dec 2002 07:08:56 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from tomts10-srv.bellnexxia.net (tomts10.bellnexxia.net [209.226.175.54]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB568s9p021820 for <[e-mail]>; Thu, 5 Dec 2002 07:08:54 +0100 (MET)
Received: from XP1 ([64.229.99.154]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021205060853.KIDS12038.tomts10-srv.bellnexxia.net@XP1>; Thu, 5 Dec 2002 01:08:53 -0500
Message-ID: <015b01c29c25$09e28b80$6402a8c0@XP1>
Reply-To: "Ross Wm. Rader" <[e-mail]>
From: "Ross Wm. Rader" <[e-mail]>
To: "Rick Wesson" <[e-mail]>, "Richard Shockey" <[e-mail]>
Cc: "Edward Lewis" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: action items from our meeting in atlanta
Date: Thu, 5 Dec 2002 01:10:40 -0500
Organization: Tucows Inc.
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk

> 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" <[e-mail]>
To: "Rick Wesson" <[e-mail]>
Cc: "Edward Lewis" <[e-mail]>; <[e-mail]>;
<[e-mail]>
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: [phone]
> <mailto:[e-mail]> or <mailto:[e-mail]>
>   <http://www.neustar.biz> ; <http://www.enum.org>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB566w9p021811 for <[e-mail]>; Thu, 5 Dec 2002 07:06:58 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB566wfO021810 for ietf-provreg-outgoing; Thu, 5 Dec 2002 07:06:58 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from tomts21-srv.bellnexxia.net (tomts21-srv.bellnexxia.net [209.226.175.183]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB566q9p021805 for <[e-mail]>; Thu, 5 Dec 2002 07:06:53 +0100 (MET)
Received: from XP1 ([64.229.99.154]) by tomts21-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021205060648.HYOJ4242.tomts21-srv.bellnexxia.net@XP1>; Thu, 5 Dec 2002 01:06:48 -0500
Message-ID: <015501c29c24$bfe903b0$6402a8c0@XP1>
Reply-To: "Ross Wm. Rader" <[e-mail]>
From: "Ross Wm. Rader" <[e-mail]>
To: "Rick Wesson" <[e-mail]>, "Richard Shockey" <[e-mail]>
Cc: "Edward Lewis" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: action items from our meeting in atlanta
Date: Thu, 5 Dec 2002 01:08:36 -0500
Organization: Tucows Inc.
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk

> 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" <[e-mail]>
To: "Richard Shockey" <[e-mail]>
Cc: "Edward Lewis" <[e-mail]>; <[e-mail]>;
<[e-mail]>
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
>
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB55hY9p021712 for <[e-mail]>; Thu, 5 Dec 2002 06:43:34 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB55hYth021711 for ietf-provreg-outgoing; Thu, 5 Dec 2002 06:43:34 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from web14308.mail.yahoo.com (web14308.mail.yahoo.com [216.136.173.156]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id gB55hW9p021706 for <[e-mail]>; Thu, 5 Dec 2002 06:43:33 +0100 (MET)
Message-ID: <[e-mail]>
Received: from [159.226.7.85] by web14308.mail.yahoo.com via HTTP; Wed, 04 Dec 2002 21:43:31 PST
Date: Wed, 4 Dec 2002 21:43:31 -0800 (PST)
From: Hong Liu <[e-mail]>
Subject: Re: action items from our meeting in atlanta
To: [e-mail]
In-Reply-To: <a05111b01ba142d50df6c@[192.149.252.235]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Ed,

Thanks for the summary. Please see my comments below.

Cheers,

--Hong

--- Edward Lewis <[e-mail]> 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                                        
>  [phone]
> ARIN Research Engineer
> 


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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB52ZP9p020328 for <[e-mail]>; Thu, 5 Dec 2002 03:35:25 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB52ZPZo020327 for ietf-provreg-outgoing; Thu, 5 Dec 2002 03:35:25 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB52ZO9p020322 for <[e-mail]>; Thu, 5 Dec 2002 03:35:24 +0100 (MET)
Received: from user-uiveque.dsl.mindspring.com ([165.247.107.206] helo=dick.ix.netcom.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 18Jlr8-0008Aa-00; Wed, 04 Dec 2002 21:35:14 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 04 Dec 2002 21:36:11 -0500
To: Rick Wesson <[e-mail]>
From: Richard Shockey <[e-mail]>
Subject: Re: action items from our meeting in atlanta
Cc: Edward Lewis <[e-mail]>, <[e-mail]>, <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

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: [phone]
<mailto:[e-mail]> or <mailto:[e-mail]>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB52Ad9p019196 for <[e-mail]>; Thu, 5 Dec 2002 03:10:39 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB52AdTN019195 for ietf-provreg-outgoing; Thu, 5 Dec 2002 03:10:39 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from fep04-mail.bloor.is.net.cable.rogers.com (fep04-mail.bloor.is.net.cable.rogers.com [66.185.86.74]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB52Ab9p019190 for <[e-mail]>; Thu, 5 Dec 2002 03:10:38 +0100 (MET)
Received: from isc.org ([24.103.90.17]) by fep04-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <[e-mail]>; Wed, 4 Dec 2002 21:10:26 -0500
Date: Wed, 4 Dec 2002 21:10:35 -0500
Subject: Re: action items from our meeting in atlanta
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v548)
Cc: [e-mail], [e-mail]
To: Edward Lewis <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <a05111b01ba142d50df6c@[192.149.252.235]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.548)
X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep04-mail.bloor.is.net.cable.rogers.com from [24.103.90.17] using ID <[e-mail]> at Wed, 4 Dec 2002 21:10:25 -0500
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB51P29p018858 for <[e-mail]>; Thu, 5 Dec 2002 02:25:02 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB51P2F2018857 for ietf-provreg-outgoing; Thu, 5 Dec 2002 02:25:02 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB51P09p018852 for <[e-mail]>; Thu, 5 Dec 2002 02:25:01 +0100 (MET)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id gB51OsSQ004482; Wed, 4 Dec 2002 17:24:54 -0800 (PST)
Date: Wed, 4 Dec 2002 17:24:56 -0800 (PST)
From: Rick Wesson <[e-mail]>
To: Richard Shockey <[e-mail]>
cc: Edward Lewis <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: action items from our meeting in atlanta
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB50kg9p018608 for <[e-mail]>; Thu, 5 Dec 2002 01:46:42 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB50kgHk018607 for ietf-provreg-outgoing; Thu, 5 Dec 2002 01:46:42 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB50kf9p018600 for <[e-mail]>; Thu, 5 Dec 2002 01:46:42 +0100 (MET)
Received: from user-uiveque.dsl.mindspring.com ([165.247.107.206] helo=dick.ix.netcom.com) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 18Jk9z-0002Wj-00; Wed, 04 Dec 2002 19:46:38 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 04 Dec 2002 19:47:41 -0500
To: Edward Lewis <[e-mail]>, [e-mail]
From: Richard Shockey <[e-mail]>
Subject: Re: action items from our meeting in atlanta
Cc: Edward Lewis <[e-mail]>, [e-mail]
In-Reply-To: <a05111b01ba142d50df6c@[192.149.252.235]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

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                                          [phone]
>ARIN Research Engineer


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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB4MwY9p017682 for <[e-mail]>; Wed, 4 Dec 2002 23:58:34 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB4MwYqn017681 for ietf-provreg-outgoing; Wed, 4 Dec 2002 23:58:34 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB4MwX9p017676 for <[e-mail]>; Wed, 4 Dec 2002 23:58:33 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gB4MwWYm013913; Wed, 4 Dec 2002 17:58:32 -0500 (EST)
Received: from [192.149.252.235] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA10433; Wed, 4 Dec 2002 17:58:30 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b01ba142d50df6c@[192.149.252.235]>
Date: Wed, 4 Dec 2002 17:59:00 -0500
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: action items from our meeting in atlanta
Cc: Edward Lewis <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB3CRO9p029071 for <[e-mail]>; Tue, 3 Dec 2002 13:27:24 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB3CROnk029070 for ietf-provreg-outgoing; Tue, 3 Dec 2002 13:27:24 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from fep04-mail.bloor.is.net.cable.rogers.com (fep04-mail.bloor.is.net.cable.rogers.com [66.185.86.74]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB3CRN9p029065 for <[e-mail]>; Tue, 3 Dec 2002 13:27:23 +0100 (MET)
Received: from isc.org ([24.103.90.17]) by fep04-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <[e-mail]>; Tue, 3 Dec 2002 07:27:13 -0500
Date: Tue, 3 Dec 2002 07:27:21 -0500
Subject: Re: <!DOCTYPE> declaration
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v548)
Cc: [e-mail]
To: "Hollenbeck, Scott" <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.548)
X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep04-mail.bloor.is.net.cable.rogers.com from [24.103.90.17] using ID <[e-mail]> at Tue, 3 Dec 2002 07:27:13 -0500
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB3CNn9p029033 for <[e-mail]>; Tue, 3 Dec 2002 13:23:49 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB3CNnjI029032 for ietf-provreg-outgoing; Tue, 3 Dec 2002 13:23:49 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB3CNm9p029027 for <[e-mail]>; Tue, 3 Dec 2002 13:23:48 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA09771; Tue, 3 Dec 2002 07:23:46 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <V87KGRH1>; Tue, 3 Dec 2002 07:18:40 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Joe Abley'" <[e-mail]>
Cc: [e-mail]
Subject: RE: <!DOCTYPE> declaration
Date: Tue, 3 Dec 2002 07:22:54 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB3CGs9p028969 for <[e-mail]>; Tue, 3 Dec 2002 13:16:54 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB3CGsRC028968 for ietf-provreg-outgoing; Tue, 3 Dec 2002 13:16:54 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from fep04-mail.bloor.is.net.cable.rogers.com (fep04-mail.bloor.is.net.cable.rogers.com [66.185.86.74]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB3CGq9p028963 for <[e-mail]>; Tue, 3 Dec 2002 13:16:52 +0100 (MET)
Received: from isc.org ([24.103.90.17]) by fep04-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <[e-mail]>; Tue, 3 Dec 2002 07:16:43 -0500
Date: Tue, 3 Dec 2002 07:16:51 -0500
Subject: Re: <!DOCTYPE> declaration
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v548)
Cc: [e-mail]
To: "Hollenbeck, Scott" <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.548)
X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep04-mail.bloor.is.net.cable.rogers.com from [24.103.90.17] using ID <[e-mail]> at Tue, 3 Dec 2002 07:16:43 -0500
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB3C9J9p028917 for <[e-mail]>; Tue, 3 Dec 2002 13:09:19 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB3C9Ioq028916 for ietf-provreg-outgoing; Tue, 3 Dec 2002 13:09:18 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB3C9H9p028911 for <[e-mail]>; Tue, 3 Dec 2002 13:09:18 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA09535; Tue, 3 Dec 2002 07:09:15 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <V5CJHH5Y>; Tue, 3 Dec 2002 07:08:41 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Joe Abley'" <[e-mail]>, [e-mail]
Subject: RE: <!DOCTYPE> declaration
Date: Tue, 3 Dec 2002 07:08:25 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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:[e-mail]]
> Sent: Tuesday, December 03, 2002 5:23 AM
> To: [e-mail]
> 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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB3ANH9p028239 for <[e-mail]>; Tue, 3 Dec 2002 11:23:17 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB3ANGJm028238 for ietf-provreg-outgoing; Tue, 3 Dec 2002 11:23:16 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from fep04-mail.bloor.is.net.cable.rogers.com (fep04-mail.bloor.is.net.cable.rogers.com [66.185.86.74]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB3ANF9p028233 for <[e-mail]>; Tue, 3 Dec 2002 11:23:15 +0100 (MET)
Received: from isc.org ([24.103.90.17]) by fep04-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <[e-mail]> for <[e-mail]>; Tue, 3 Dec 2002 05:23:06 -0500
Date: Tue, 3 Dec 2002 05:23:14 -0500
Mime-Version: 1.0 (Apple Message framework v548)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: <!DOCTYPE> declaration
From: Joe Abley <[e-mail]>
To: [e-mail]
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
X-Mailer: Apple Mail (2.548)
X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep04-mail.bloor.is.net.cable.rogers.com from [24.103.90.17] using ID <[e-mail]> at Tue, 3 Dec 2002 05:23:06 -0500
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB37cO9p026960 for <[e-mail]>; Tue, 3 Dec 2002 08:38:24 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB37cONd026959 for ietf-provreg-outgoing; Tue, 3 Dec 2002 08:38:24 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB37cI9p026954 for <[e-mail]>; Tue, 3 Dec 2002 08:38:18 +0100 (MET)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id gB37cASQ012807; Mon, 2 Dec 2002 23:38:14 -0800 (PST)
Date: Mon, 2 Dec 2002 23:38:12 -0800 (PST)
From: Rick Wesson <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Joe Abley'" <[e-mail]>, <[e-mail]>
Subject: RE: "ok" status on domains (and other objects)
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB37VR9p026937 for <[e-mail]>; Tue, 3 Dec 2002 08:31:27 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB37VRUU026936 for ietf-provreg-outgoing; Tue, 3 Dec 2002 08:31:27 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB37VQ9p026931 for <[e-mail]>; Tue, 3 Dec 2002 08:31:26 +0100 (MET)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id gB37VJSQ012733; Mon, 2 Dec 2002 23:31:19 -0800 (PST)
Date: Mon, 2 Dec 2002 23:31:21 -0800 (PST)
From: Rick Wesson <[e-mail]>
To: Richard Shockey <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Subject: RE: milestones, was Re: a week later...
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB31Bh9p023825 for <[e-mail]>; Tue, 3 Dec 2002 02:11:43 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB31Bh9B023824 for ietf-provreg-outgoing; Tue, 3 Dec 2002 02:11:43 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB31Bf9p023819 for <[e-mail]>; Tue, 3 Dec 2002 02:11:42 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id UAA25326; Mon, 2 Dec 2002 20:11:39 -0500 (EST)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <V5CJG9HQ>; Mon, 2 Dec 2002 20:11:06 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Joe Abley'" <[e-mail]>
Cc: [e-mail]
Subject: RE: "ok" status on domains (and other objects)
Date: Mon, 2 Dec 2002 20:10:42 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB2LlC9p021798 for <[e-mail]>; Mon, 2 Dec 2002 22:47:12 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB2LlCYP021797 for ietf-provreg-outgoing; Mon, 2 Dec 2002 22:47:12 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB2LlB9p021792 for <[e-mail]>; Mon, 2 Dec 2002 22:47:11 +0100 (MET)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id gB2Ll5OG018231 for <[e-mail]>; Mon, 2 Dec 2002 22:47:05 +0100 (CET) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id gB2Ll5s3018230 for [e-mail]; Mon, 2 Dec 2002 22:47:05 +0100 (CET)
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB2LZh9p021632 for <[e-mail]>; Mon, 2 Dec 2002 22:35:43 +0100 (MET)
Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id gB2LZ9b25431; Mon, 2 Dec 2002 21:35:09 GMT
Message-Id: <[e-mail]>
X-Sender: 
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 02 Dec 2002 16:35:59 -0500
To: Rick Wesson <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>
From: Richard Shockey <[e-mail]>
Subject: RE: milestones, was Re: a week later...
Cc: "'Edward Lewis'" <[e-mail]>, <[e-mail]>, <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

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: [phone]
<mailto:[e-mail]> or <mailto:[e-mail]>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB2L4v9p021260 for <[e-mail]>; Mon, 2 Dec 2002 22:04:57 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB2L4vDO021259 for ietf-provreg-outgoing; Mon, 2 Dec 2002 22:04:57 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from fep03-mail.bloor.is.net.cable.rogers.com (fep03-mail.bloor.is.net.cable.rogers.com [66.185.86.73]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB2L4t9p021254 for <[e-mail]>; Mon, 2 Dec 2002 22:04:56 +0100 (MET)
Received: from isc.org ([24.103.90.17]) by fep03-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <[e-mail]>; Mon, 2 Dec 2002 16:04:49 -0500
Date: Mon, 2 Dec 2002 16:04:52 -0500
Subject: Re: "ok" status on domains (and other objects)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v548)
Cc: Michael Graff <[e-mail]>, [e-mail]
To: Edward Lewis <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <a05111b1bba1163b0a7c4@[66.44.64.242]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.548)
X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.103.90.17] using ID <[e-mail]> at Mon, 2 Dec 2002 16:04:49 -0500
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB2JXf9p020103 for <[e-mail]>; Mon, 2 Dec 2002 20:33:41 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB2JXfpS020102 for ietf-provreg-outgoing; Mon, 2 Dec 2002 20:33:41 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB2JXc9p020095 for <[e-mail]>; Mon, 2 Dec 2002 20:33:38 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gB2JXZYm040627; Mon, 2 Dec 2002 14:33:35 -0500 (EST)
Received: from [66.44.64.242] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA11492; Mon, 2 Dec 2002 14:33:34 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b1bba1163b0a7c4@[66.44.64.242]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]> <a05111b0cba11264e44c7@[66.44.64.242]> <[e-mail]>
Date: Mon, 2 Dec 2002 14:30:22 -0500
To: Michael Graff <[e-mail]>, Edward Lewis <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: "ok" status on domains (and other objects)
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB2IQ29p019133 for <[e-mail]>; Mon, 2 Dec 2002 19:26:02 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB2IQ2Ex019132 for ietf-provreg-outgoing; Mon, 2 Dec 2002 19:26:02 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from isrv4.isc.org (isrv4.isc.org [204.152.184.27]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB2IQ19p019127 for <[e-mail]>; Mon, 2 Dec 2002 19:26:01 +0100 (MET)
Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by isrv4.isc.org (Postfix) with ESMTP id 532041C1C; Mon,  2 Dec 2002 18:25:58 +0000 (UTC) (envelope-from [e-mail])
Received: by farside.isc.org (Postfix, from userid 10015) id E29FCAA75; Mon,  2 Dec 2002 18:25:57 +0000 (UTC)
To: Edward Lewis <[e-mail]>
Cc: [e-mail]
Subject: Re: "ok" status on domains (and other objects)
References: <[e-mail]> <a05111b0cba11264e44c7@[66.44.64.242]>
From: Michael Graff <[e-mail]>
Date: 02 Dec 2002 18:25:57 +0000
In-Reply-To: <a05111b0cba11264e44c7@[66.44.64.242]>
Message-ID: <[e-mail]>
Lines: 22
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Edward Lewis <[e-mail]> 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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB2HX59p018443 for <[e-mail]>; Mon, 2 Dec 2002 18:33:05 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB2HX5sb018442 for ietf-provreg-outgoing; Mon, 2 Dec 2002 18:33:05 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB2HX39p018437 for <[e-mail]>; Mon, 2 Dec 2002 18:33:04 +0100 (MET)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id gB2HWrSQ006508; Mon, 2 Dec 2002 09:32:53 -0800 (PST)
Date: Mon, 2 Dec 2002 09:32:55 -0800 (PST)
From: Rick Wesson <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Edward Lewis'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: milestones, was Re: a week later...
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB2FMB9p016865 for <[e-mail]>; Mon, 2 Dec 2002 16:22:11 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB2FMBeO016864 for ietf-provreg-outgoing; Mon, 2 Dec 2002 16:22:11 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB2FM99p016859 for <[e-mail]>; Mon, 2 Dec 2002 16:22:10 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA24820; Mon, 2 Dec 2002 10:22:08 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <V87KGA0W>; Mon, 2 Dec 2002 10:17:03 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: milestones, was Re: a week later...
Date: Mon, 2 Dec 2002 10:21:14 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB2FJD9p016832 for <[e-mail]>; Mon, 2 Dec 2002 16:19:13 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB2FJC13016831 for ietf-provreg-outgoing; Mon, 2 Dec 2002 16:19:12 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB2FJB9p016821 for <[e-mail]>; Mon, 2 Dec 2002 16:19:11 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gB2FJ7Ym032377 for <[e-mail]>; Mon, 2 Dec 2002 10:19:08 -0500 (EST)
Received: from [66.44.64.242] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA25940 for <[e-mail]>; Mon, 2 Dec 2002 10:19:00 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b0cba11264e44c7@[66.44.64.242]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Mon, 2 Dec 2002 10:17:57 -0500
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: RE: "ok" status on domains (and other objects)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB2Exj9p016672 for <[e-mail]>; Mon, 2 Dec 2002 15:59:45 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id gB2Exjj9016671 for ietf-provreg-outgoing; Mon, 2 Dec 2002 15:59:45 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB2Exi9p016666 for <[e-mail]>; Mon, 2 Dec 2002 15:59:44 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gB2ExhYm031772; Mon, 2 Dec 2002 09:59:43 -0500 (EST)
Received: from [66.44.64.242] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA22442; Mon, 2 Dec 2002 09:59:40 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b0aba1123849d8c@[66.44.64.242]>
In-Reply-To: <a05111b13ba097848ba6c@[66.44.91.230]>
References: <a05111b13ba097848ba6c@[66.44.91.230]>
Date: Mon, 2 Dec 2002 10:00:03 -0500
To: Edward Lewis <[e-mail]>, [e-mail]
From: Edward Lewis <[e-mail]>
Subject: milestones, was Re: a week later...
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB2EZQ9p016460 for <[e-mail]>; Mon, 2 Dec 2002 15:35:26 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id gB2EZQIO016459 for ietf-provreg-outgoing; Mon, 2 Dec 2002 15:35:26 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id gB2EZO9p016454 for <[e-mail]>; Mon, 2 Dec 2002 15:35:25 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id gB2EZNYm031101 for <[e-mail]>; Mon, 2 Dec 2002 09:35:23 -0500 (EST)
Received: from [66.44.64.242] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA19656; Mon, 2 Dec 2002 09:35:20 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b09ba111fa6b53e@[66.44.64.242]>
Date: Mon, 2 Dec 2002 09:35:46 -0500
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: raw, uncooked notes from the meeting in Atlanta
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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                                          [phone]
ARIN Research Engineer