RE: [ietf-provreg] Question about Transfer query command

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

> I note that between draft-ietf-provreg-epp-domain-05.txt and
> draft-ietf-provreg-epp-domain-07.txt that the formal syntax 
> for transferType
> has changed.  The element authInfo now has a minOccurs="0" attribute.
> 
> Q1: Are there any other cases other than "query" where authInfo may be
> ommitted?

No, it's explained in the text how it's optional with a query and required
with the other transfer operations.  The change took place in -06, where
this text was included in the section describing changes from the previous
version:

"Made transfer authInfo optional in sections 3.1.3 and 4 to allow queries in
a manner consistent with the <info> command."

> Q2: If an authInfo value is provided with the "query" 
> command, should it be
> ignored or should an error occur?  Should the error be 
> conditional based on
> the validity of the authInfo value?

As written in section 3.1.3 of the current draft:

"If this element is not provided or if the authorization information is
invalid, server policy determines if the command is rejected or if response
information will be returned to the client."

If authInfo is provided it can't be ignored -- the server can either return
an error or it can return information, just like the info command.  I'd
prefer that an error be returned if bad data is received, but WG discussion
around the issue of authInfo and queries was somewhat more liberal.

-Scott-



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4TIYkSX000728 for <[e-mail]>; Thu, 29 May 2003 20:34:46 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h4TIYklL000727 for ietf-provreg-outgoing; Thu, 29 May 2003 20:34:46 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4TIYiSX000722 for <[e-mail]>; Thu, 29 May 2003 20:34:45 +0200 (MEST)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h4TIa7dr000014; Thu, 29 May 2003 14:36:07 -0400 (EDT)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <K8ZFGP4F>; Thu, 29 May 2003 14:34:43 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Mike Lampson'" <[e-mail]>, "'ietf-provregcafaxse'" <[e-mail]>
Subject: RE: [ietf-provreg] Question about Transfer query command
Date: Thu, 29 May 2003 14:34:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> I note that between draft-ietf-provreg-epp-domain-05.txt and
> draft-ietf-provreg-epp-domain-07.txt that the formal syntax 
> for transferType
> has changed.  The element authInfo now has a minOccurs="0" attribute.
> 
> Q1: Are there any other cases other than "query" where authInfo may be
> ommitted?

No, it's explained in the text how it's optional with a query and required
with the other transfer operations.  The change took place in -06, where
this text was included in the section describing changes from the previous
version:

"Made transfer authInfo optional in sections 3.1.3 and 4 to allow queries in
a manner consistent with the <info> command."

> Q2: If an authInfo value is provided with the "query" 
> command, should it be
> ignored or should an error occur?  Should the error be 
> conditional based on
> the validity of the authInfo value?

As written in section 3.1.3 of the current draft:

"If this element is not provided or if the authorization information is
invalid, server policy determines if the command is rejected or if response
information will be returned to the client."

If authInfo is provided it can't be ignored -- the server can either return
an error or it can return information, just like the info command.  I'd
prefer that an error be returned if bad data is received, but WG discussion
around the issue of authInfo and queries was somewhat more liberal.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4TFMLSX028825 for <[e-mail]>; Thu, 29 May 2003 17:22:21 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h4TFMLpJ028824 for ietf-provreg-outgoing; Thu, 29 May 2003 17:22:21 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp02.infoave.net (smtp02.infoave.net [165.166.0.27]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4TFMKSX028819 for <[e-mail]>; Thu, 29 May 2003 17:22:20 +0200 (MEST)
Received: from mikel ([165.166.144.206]) by SMTP00.InfoAve.Net (PMDF V6.1-1IA5 #38780) with SMTP id <[e-mail]> for [e-mail]; Thu, 29 May 2003 11:17:04 -0400 (EDT)
Date: Thu, 29 May 2003 11:17:02 -0400
From: Mike Lampson <[e-mail]>
Subject: [ietf-provreg] Question about Transfer query command
To: "'ietf-provregcafaxse'" <[e-mail]>
Message-id: <00b601c325f5$5be5ade0$720218ac@mikel>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References:  <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Dear List,

I have some more questions - this time about the transfer command:

I note that between draft-ietf-provreg-epp-domain-05.txt and
draft-ietf-provreg-epp-domain-07.txt that the formal syntax for transferType
has changed.  The element authInfo now has a minOccurs="0" attribute.

Q1: Are there any other cases other than "query" where authInfo may be
ommitted?

Q2: If an authInfo value is provided with the "query" command, should it be
ignored or should an error occur?  Should the error be conditional based on
the validity of the authInfo value?

The action that I am trying to accomplish is to verify the accuracy of a
customer-entered authInfo value without actually initiating a transfer
request.

Thanks,

Mike Lampson
The Registry at Info Avenue, LLC




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4REJXSX000965 for <[e-mail]>; Tue, 27 May 2003 16:19:33 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h4REJXDS000964 for ietf-provreg-outgoing; Tue, 27 May 2003 16:19:33 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4REJWSX000959 for <[e-mail]>; Tue, 27 May 2003 16:19:32 +0200 (MEST)
Received: by smtp1.arin.net (Postfix, from userid 5003) id 70D4F41F; Tue, 27 May 2003 10:19:30 -0400 (EDT)
Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 0A2CA3B7 for <[e-mail]>; Tue, 27 May 2003 10:19:30 -0400 (EDT)
Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b6) with ESMTP id 300094; Tue, 27 May 2003 10:17:57 -0400
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b07baf92405a630@[192.168.1.100]>
Date: Tue, 27 May 2003 10:19:35 -0400
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: [ietf-provreg] last day for last call comments
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_SPARSE, SPAM_PHRASE_02_03 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

A reminder...

>Date: Wed, 14 May 2003 15:30:29 +0200
>To: [e-mail]
>From: Edward Lewis <[e-mail]>
>Subject: [ietf-provreg] WG last call for Guidelines for Extending ...EPP
>Cc: Edward Lewis <[e-mail]>, [e-mail]
>
>Let this message start a WG last call for comments on the 
>"Guidelines for Extending EPP" document.  The URL for the current 
>document is:
>
>    http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-ext-02.txt
>
>This document is intended to be forwarded to the IESG as an Informational RFC.
>
>The last call will end on May 27 [1], with the desire to forward the 
>document onward by May 30.  So far we haven't seen much discussion 
>on this document, so I don't anticipate that there will be a high 
>volume of comments.
>
>So - why advance this document and not drop it?
>
>This document was prompted by a number of efforts to extend EPP 
>outside of the WG purview.  In many cases, these folks made contact 
>with Scott for tips and hints when it was apparent that the 
>extension was going awry.  This document was asked for by the WG to 
>give others a general path toward extending EPP and to also free up 
>Scott to pursue other things - like his normally assigned work. ;)
>
>So, although this document isn't about interoperability per se, it 
>is important to the group to capture this knowledge before declaring 
>that we have defined a proposed standard version of EPP.
>
>[1] If you want to choose a specific minute - May 28, 1200 UTC.  But 
>remember, it's never too late to comment...

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

Your office is *not* a reality-based sit-com TV show.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4QB50RN014052 for <[e-mail]>; Mon, 26 May 2003 13:05:00 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h4QB50bl014051 for ietf-provreg-outgoing; Mon, 26 May 2003 13:05:00 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4QB4wRN014046 for <[e-mail]>; Mon, 26 May 2003 13:04:59 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h4QAwZdn041787; Mon, 26 May 2003 06:58:35 -0400 (EDT)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: Stephane Bortzmeyer <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: [ietf-provreg] [OT] A paper on EPP in The Register 
In-Reply-To: Message from Stephane Bortzmeyer <[e-mail]>  of "Mon, 26 May 2003 10:12:13 -0000." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 26 May 2003 06:58:35 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> Personal opinion: mostly BS

Agree. He/She/It wrote http://www.theregister.co.uk/content/6/30170.html,
and apparently forgot to cite his/hers/its sources, one of which seems to
be http://nic-iq.nic-naa.net/

-e



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4QAEeRN013711 for <[e-mail]>; Mon, 26 May 2003 12:14:40 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h4QAEel6013710 for ietf-provreg-outgoing; Mon, 26 May 2003 12:14:40 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail-aubervilliers.netaktiv.com (soyouz.netaktiv.com [80.67.170.6]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4QAEcRN013705 for <[e-mail]>; Mon, 26 May 2003 12:14:39 +0200 (MEST)
Received: by mail-aubervilliers.netaktiv.com (Postfix, from userid 10) id 458E823D68; Mon, 26 May 2003 12:14:34 +0200 (CEST)
Received: by laperouse.internatif.org (Postfix, from userid 1000) id 7FCB6DE1C; Mon, 26 May 2003 10:12:13 +0000 (WET)
Date: Mon, 26 May 2003 10:12:13 +0000
From: Stephane Bortzmeyer <[e-mail]>
To: [e-mail]
Subject: [ietf-provreg] [OT] A paper on EPP in The Register
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
X-Transport: UUCP rules
X-Operating-System: Debian GNU/Linux 3.0
Sender: [e-mail]
Precedence: bulk

http://www.theregister.co.uk/content/6/30862.html

Personal opinion: mostly BS


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4NIcERN019198 for <[e-mail]>; Fri, 23 May 2003 20:38:14 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h4NIcE0U019197 for ietf-provreg-outgoing; Fri, 23 May 2003 20:38:14 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp03.infoave.net (smtp03.infoave.net [165.166.0.28]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4NIcDRN019192 for <[e-mail]>; Fri, 23 May 2003 20:38:13 +0200 (MEST)
Received: from mikel ([165.166.144.145]) by SMTP00.InfoAve.Net (PMDF V6.1-1IA5 #38776) with SMTP id <[e-mail]> for [e-mail]; Fri, 23 May 2003 14:37:22 -0400 (EDT)
Date: Fri, 23 May 2003 14:37:22 -0400
From: Mike Lampson <[e-mail]>
Subject: Re: [ietf-provreg] Question about e164StringType definition
To: "'ietf-provregcafaxse'" <[e-mail]>
Cc: Hollenbeck Scott <[e-mail]>
Message-id: <02b501c3215a$5946eee0$720218ac@mikel>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References:  <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Scott,

Thanks for the explanation.  I guess I'll put a little business logic in the
XML construction layer of our software to make sure the maximum length of
the destination code is conditional based on the country code length.

Cheers,

_Mike

----- Original Message -----
From: "Hollenbeck Scott" <[e-mail]>
To: "'Mike Lampson'" <[e-mail]>; "'ietf-provregcafaxse'"
<[e-mail]>
Sent: Friday, May 23, 2003 1:40 PM
Subject: RE: [ietf-provreg] Question about e164StringType definition


> I am working on upgrading our EPP implementation to support
> the PIR Registry
> and have come across an issue that I'm not sure is a problem with the
> protocol definition or the implementation.
>
> Both contact-05 (which PIR uses) and contact-07 describe the
> e164StringType
> as follows:
>
>     <simpleType name="e164StringType">
>       <restriction base="token">
>         <pattern value="(\+[0-9]{1,3}\.[0-9]{1,14})?"/>
>         <maxLength value="17"/>
>       </restriction>
>     </simpleType>
>
> Should be maxLength be 19 instead of 17 to allow for the 2
> fixed characters?

This might be confusing because of the way E.164 (included in the spec as an
informative reference) defines number syntax.  The maximum total length of
an E.164 number is 15 digits (add the two for the separators we're using and
you get the 17 that you see in the spec), with the maximum length of the
national destination code (the part to the right of the ".") _dependent_ on
the country code -- it's defined as "maximum 15-cc digits".  If you have a
one-digit country code the national destination code can contain up to 14
digits, if you have a two-digit country code the national destination code
can contain up to 13 digits, and if you have a three-digit country code the
national destination code can contain up to 12 digits.

So, the protocol spec is accurate.  The length of the country code
determines the maximum length of the national destination code, and the
pattern specified is general to allow all of the legal combinations.
Unfortunately regexp syntax doesn't allow if-then constructs to make the max
length of the second field dependent on the length of the first.

-Scott-



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4NHeqRN018654 for <[e-mail]>; Fri, 23 May 2003 19:40:52 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h4NHeqsK018653 for ietf-provreg-outgoing; Fri, 23 May 2003 19:40:52 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4NHeoRN018648 for <[e-mail]>; Fri, 23 May 2003 19:40:50 +0200 (MEST)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h4NHgCdr021693; Fri, 23 May 2003 13:42:12 -0400 (EDT)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <K8ZFDPJC>; Fri, 23 May 2003 13:40:49 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Mike Lampson'" <[e-mail]>, "'ietf-provregcafaxse'" <[e-mail]>
Subject: RE: [ietf-provreg] Question about e164StringType definition
Date: Fri, 23 May 2003 13:40:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> I am working on upgrading our EPP implementation to support 
> the PIR Registry
> and have come across an issue that I'm not sure is a problem with the
> protocol definition or the implementation.
> 
> Both contact-05 (which PIR uses) and contact-07 describe the 
> e164StringType
> as follows:
> 
>     <simpleType name="e164StringType">
>       <restriction base="token">
>         <pattern value="(\+[0-9]{1,3}\.[0-9]{1,14})?"/>
>         <maxLength value="17"/>
>       </restriction>
>     </simpleType>
> 
> Should be maxLength be 19 instead of 17 to allow for the 2 
> fixed characters?

This might be confusing because of the way E.164 (included in the spec as an
informative reference) defines number syntax.  The maximum total length of
an E.164 number is 15 digits (add the two for the separators we're using and
you get the 17 that you see in the spec), with the maximum length of the
national destination code (the part to the right of the ".") _dependent_ on
the country code -- it's defined as "maximum 15-cc digits".  If you have a
one-digit country code the national destination code can contain up to 14
digits, if you have a two-digit country code the national destination code
can contain up to 13 digits, and if you have a three-digit country code the
national destination code can contain up to 12 digits.

So, the protocol spec is accurate.  The length of the country code
determines the maximum length of the national destination code, and the
pattern specified is general to allow all of the legal combinations.
Unfortunately regexp syntax doesn't allow if-then constructs to make the max
length of the second field dependent on the length of the first.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4NGh8RN017900 for <[e-mail]>; Fri, 23 May 2003 18:43:08 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h4NGh8RR017899 for ietf-provreg-outgoing; Fri, 23 May 2003 18:43:08 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp03.infoave.net (smtp03.infoave.net [165.166.0.28]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4NGh6RN017894 for <[e-mail]>; Fri, 23 May 2003 18:43:07 +0200 (MEST)
Received: from mikel ([165.166.144.145]) by SMTP00.InfoAve.Net (PMDF V6.1-1IA5 #38780) with SMTP id <[e-mail]> for [e-mail]; Fri, 23 May 2003 12:39:10 -0400 (EDT)
Date: Fri, 23 May 2003 12:39:09 -0400
From: Mike Lampson <[e-mail]>
Subject: [ietf-provreg] Question about e164StringType definition
To: "'ietf-provregcafaxse'" <[e-mail]>
Message-id: <00f901c32149$d5ff1860$720218ac@mikel>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References:  <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Hi,

I am working on upgrading our EPP implementation to support the PIR Registry
and have come across an issue that I'm not sure is a problem with the
protocol definition or the implementation.

Both contact-05 (which PIR uses) and contact-07 describe the e164StringType
as follows:

    <simpleType name="e164StringType">
      <restriction base="token">
        <pattern value="(\+[0-9]{1,3}\.[0-9]{1,14})?"/>
        <maxLength value="17"/>
      </restriction>
    </simpleType>

Should be maxLength be 19 instead of 17 to allow for the 2 fixed characters?

Thanks,

Mike Lampson
The Registry at Info Avenue, LLC





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4MJVFRN004830 for <[e-mail]>; Thu, 22 May 2003 21:31:15 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h4MJVF96004829 for ietf-provreg-outgoing; Thu, 22 May 2003 21:31:15 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from tom.interq.or.jp (tom.interq.or.jp [210.172.128.229]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4MJVDRN004824 for <[e-mail]>; Thu, 22 May 2003 21:31:14 +0200 (MEST)
Received: from imap.interq.or.jp (imap.interq.or.jp [210.157.0.31]) by tom.interq.or.jp  with ESMTP id h4MJVBVp025795;) Fri, 23 May 2003 04:31:11 +0900 (JST)
Date: Fri, 23 May 2003 04:31:11 +0900 (JST)
From: Peter Chow <[e-mail]>
X-X-Sender: [e-mail]
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Subject: Re: [ietf-provreg] FW: I-D ACTION:draft-hollenbeck-epp-rgp-00.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Thu, 22 May 2003, Hollenbeck, Scott wrote:

> This new I-D might be of interest to anyone having to implement ICANN's
> Redemption Grace Period policy within EPP.  Comments and suggestions around
> the "TBD" items are welcome.

Scott, in section 2 you said "(TBD: should the report be submitted through
the protocol (as part of the <restore>) or an out-of-band facility such as
a web site?)"

I would prefer if there is a mechanism in the protocol to submit the
reports.  Recently VGRS started an IDN renewal period extension program
that would allow registrars to have extra time to convince customers to
renew IDN domains.  This program required that the IDN domains first be
deleted and then restored, with the restore reports being submitted via
the Registrar Tool website.

The amount of manual work required to submit the restore report via the
website made this solution ineffective.  A mechanism for us to submit
the reports through the protocol would have allowed us to participate
in this program.

Peter


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4MH6gRN003178 for <[e-mail]>; Thu, 22 May 2003 19:06:43 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h4MH6g87003177 for ietf-provreg-outgoing; Thu, 22 May 2003 19:06:42 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4MH6fRN003172 for <[e-mail]>; Thu, 22 May 2003 19:06:42 +0200 (MEST)
Received: by smtp1.arin.net (Postfix, from userid 5003) id D10A8388; Thu, 22 May 2003 13:06:33 -0400 (EDT)
Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 7661D381; Thu, 22 May 2003 13:06:33 -0400 (EDT)
Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 268952; Thu, 22 May 2003 13:05:24 -0400
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b0dbaf2b335ce94@[192.168.1.100]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Thu, 22 May 2003 13:06:44 -0400
To: "Hollenbeck, Scott" <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: RE: [ietf-provreg] FW: I-D ACTION:draft-hollenbeck-epp-rgp-00.txt
Cc: "'janusz sienkiewicz'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,IN_REP_TO,OUTLOOK_FW_MSG,REFERENCES, SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_01_02 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

At 12:36 -0400 5/22/03, Hollenbeck, Scott wrote:
>Janusz,
>
>Thanks for reading the document and taking time to comment.  We should
>probably take this discussion off the provreg list, though, as this document
>isn't a provreg work item.  I'll follow up with you privately.

I would encourage you to continue to make use of the mailing list. 
The list will outlast the group (assuming the current plan of 
shutting down the group at PS holds).  The list will be a good place 
to collect implementation thoughts, etc., and a good place to make a 
call to form a group to publish the Draft Standard documents.

Keep in mind, In RFC 2026, section 4.1.1.:

    Implementors should treat Proposed Standards as immature
    specifications.  It is desirable to implement them in order to gain
    experience and to validate, test, and clarify the specification.
    However, since the content of Proposed Standards may be changed if
    problems are found or better solutions are identified, deploying
    implementations of such standards into a disruption-sensitive
    environment is not recommended.

So, draft standard is something folks should have an eye on down the road.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

Your office is *not* a reality-based sit-com TV show.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4MGaGRN002775 for <[e-mail]>; Thu, 22 May 2003 18:36:16 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h4MGaGgv002774 for ietf-provreg-outgoing; Thu, 22 May 2003 18:36:16 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4MGaERN002769 for <[e-mail]>; Thu, 22 May 2003 18:36:15 +0200 (MEST)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h4MGbbdr021300; Thu, 22 May 2003 12:37:37 -0400 (EDT)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <K8ZFC5TL>; Thu, 22 May 2003 12:36:14 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'janusz sienkiewicz'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: [ietf-provreg] FW: I-D ACTION:draft-hollenbeck-epp-rgp-00.txt
Date: Thu, 22 May 2003 12:36:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Janusz,

Thanks for reading the document and taking time to comment.  We should
probably take this discussion off the provreg list, though, as this document
isn't a provreg work item.  I'll follow up with you privately.

-Scott-

> -----Original Message-----
> From: janusz sienkiewicz [mailto:[e-mail]]
> Sent: Thursday, May 22, 2003 11:33 AM
> To: Hollenbeck, Scott
> Cc: '[e-mail]'
> Subject: Re: [ietf-provreg] FW: I-D
> ACTION:draft-hollenbeck-epp-rgp-00.txt
> 
> 
> As the state diagram on page 5 shows rgp restore is in fact a 
> two step process.
> Step one is submitting <rgp:restore> request and step two is 
> submitting resore
> report. Step two can be repeated in case incorrect data was 
> submitted in the
> original report.
> 
> I think it would be useful if <rgp:restore> syntax allowed submiting
> information required in restore report. It could be 
> acomplished by introducing
> "op" attribute (similiar to the one in transfer request). 
> Valid values for the
> attribute would be: "request", "validate".
> 
> Example restore request command:
> 
> ...
> <rgp:restore op="request"/>
> ...
> 
> 
> Example restore validate command:
> 
> ...
> <rgp:restore op="validate">
>     <!-- the content of restore report -->
> </rgp:restore>
> ...
> 
> Multiple restore validate requests should be allowed. It is 
> possible that a
> client may send incorrect restore data so correction may be required.
> 
> Janusz Sienkiewicz
> 
> 
> 
> "Hollenbeck, Scott" wrote:
> 
> > This new I-D might be of interest to anyone having to 
> implement ICANN's
> > Redemption Grace Period policy within EPP.  Comments and 
> suggestions around
> > the "TBD" items are welcome.
> >
> > -Scott-
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Tuesday, May 20, 2003 7:26 AM
> > To: IETF-Announce; @ietf.org
> > Subject: I-D ACTION:draft-hollenbeck-epp-rgp-00.txt
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >         Title           : Redemption Grace Period Mapping 
> for the Extensible
> >
> >                           Provisioning Protocol
> >         Author(s)       : S. Hollenbeck
> >         Filename        : draft-hollenbeck-epp-rgp-00.txt
> >         Pages           : 22
> >         Date            : 2003-5-19
> >
> > This document describes an Extensible Provisioning Protocol (EPP)
> > extension mapping for the management of Domain Name System (DNS)
> > domain names subject to the Redemption Grace Period (RGP) policies
> > defined by the Internet Corporation for Assigned Names and Numbers
> > (ICANN).  Specified in XML, this mapping extends the EPP domain name
> > mapping to provide additional features required for RGP processing.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-rgp-00.txt
> >
> > To remove yourself from the IETF Announcement list, send a 
> message to
> > ietf-announce-request with the word unsubscribe in the body 
> of the message.
> >
> > Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> >         "get draft-hollenbeck-epp-rgp-00.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> >         [e-mail].
> > In the body type:
> >         "FILE /internet-drafts/draft-hollenbeck-epp-rgp-00.txt".
> >
> > NOTE:   The mail server at ietf.org can return the document in
> >         MIME-encoded form by using the "mpack" utility.  To use this
> >         feature, insert the command "ENCODING mime" before 
> the "FILE"
> >         command.  To decode the response(s), you will need 
> "munpack" or
> >         a MIME-compliant mail reader.  Different 
> MIME-compliant mail readers
> >         exhibit different behavior, especially when dealing with
> >         "multipart" MIME messages (i.e. documents which 
> have been split
> >         up into multiple messages), so check your local 
> documentation on
> >         how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> 


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4MFWwRN001763 for <[e-mail]>; Thu, 22 May 2003 17:32:58 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h4MFWwTj001762 for ietf-provreg-outgoing; Thu, 22 May 2003 17:32:58 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4MFWvRN001757 for <[e-mail]>; Thu, 22 May 2003 17:32:57 +0200 (MEST)
Received: from dev3.int.libertyrms.com ([10.1.2.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 19Is3q-0006Ak-00; Thu, 22 May 2003 11:32:54 -0400
Message-ID: <[e-mail]>
Date: Thu, 22 May 2003 11:32:55 -0400
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3custom i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: [ietf-provreg] FW: I-D ACTION:draft-hollenbeck-epp-rgp-00.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

As the state diagram on page 5 shows rgp restore is in fact a two step process.
Step one is submitting <rgp:restore> request and step two is submitting resore
report. Step two can be repeated in case incorrect data was submitted in the
original report.

I think it would be useful if <rgp:restore> syntax allowed submiting
information required in restore report. It could be acomplished by introducing
"op" attribute (similiar to the one in transfer request). Valid values for the
attribute would be: "request", "validate".

Example restore request command:

...
<rgp:restore op="request"/>
...


Example restore validate command:

...
<rgp:restore op="validate">
    <!-- the content of restore report -->
</rgp:restore>
...

Multiple restore validate requests should be allowed. It is possible that a
client may send incorrect restore data so correction may be required.

Janusz Sienkiewicz



"Hollenbeck, Scott" wrote:

> This new I-D might be of interest to anyone having to implement ICANN's
> Redemption Grace Period policy within EPP.  Comments and suggestions around
> the "TBD" items are welcome.
>
> -Scott-
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, May 20, 2003 7:26 AM
> To: IETF-Announce; @ietf.org
> Subject: I-D ACTION:draft-hollenbeck-epp-rgp-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>         Title           : Redemption Grace Period Mapping for the Extensible
>
>                           Provisioning Protocol
>         Author(s)       : S. Hollenbeck
>         Filename        : draft-hollenbeck-epp-rgp-00.txt
>         Pages           : 22
>         Date            : 2003-5-19
>
> This document describes an Extensible Provisioning Protocol (EPP)
> extension mapping for the management of Domain Name System (DNS)
> domain names subject to the Redemption Grace Period (RGP) policies
> defined by the Internet Corporation for Assigned Names and Numbers
> (ICANN).  Specified in XML, this mapping extends the EPP domain name
> mapping to provide additional features required for RGP processing.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-rgp-00.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-hollenbeck-epp-rgp-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>         [e-mail].
> In the body type:
>         "FILE /internet-drafts/draft-hollenbeck-epp-rgp-00.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4MC7wRN029581 for <[e-mail]>; Thu, 22 May 2003 14:07:58 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h4MC7wXr029580 for ietf-provreg-outgoing; Thu, 22 May 2003 14:07:58 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4MC7uRN029575 for <[e-mail]>; Thu, 22 May 2003 14:07:56 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h4MC9Idr011704 for <[e-mail]>; Thu, 22 May 2003 08:09:18 -0400 (EDT)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <J8TWTS1N>; Thu, 22 May 2003 08:07:53 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: [ietf-provreg] FW: I-D ACTION:draft-hollenbeck-epp-rgp-00.txt
Date: Thu, 22 May 2003 08:07:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

This new I-D might be of interest to anyone having to implement ICANN's
Redemption Grace Period policy within EPP.  Comments and suggestions around
the "TBD" items are welcome.

-Scott-

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Tuesday, May 20, 2003 7:26 AM
To: IETF-Announce; @ietf.org
Subject: I-D ACTION:draft-hollenbeck-epp-rgp-00.txt


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


	Title		: Redemption Grace Period Mapping for the Extensible

                          Provisioning Protocol
	Author(s)	: S. Hollenbeck
	Filename	: draft-hollenbeck-epp-rgp-00.txt
	Pages		: 22
	Date		: 2003-5-19
	
This document describes an Extensible Provisioning Protocol (EPP)
extension mapping for the management of Domain Name System (DNS)
domain names subject to the Redemption Grace Period (RGP) policies
defined by the Internet Corporation for Assigned Names and Numbers
(ICANN).  Specified in XML, this mapping extends the EPP domain name
mapping to provide additional features required for RGP processing.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-hollenbeck-epp-rgp-00.txt".

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


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

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4KGopRN002316 for <[e-mail]>; Tue, 20 May 2003 18:50:51 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h4KGopOE002315 for ietf-provreg-outgoing; Tue, 20 May 2003 18:50:51 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4KGonRN002310 for <[e-mail]>; Tue, 20 May 2003 18:50:49 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id E15964A8; Tue, 20 May 2003 12:50:48 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 610F751D; Tue, 20 May 2003 12:50:48 -0400 (EDT)
Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 265525; Tue, 20 May 2003 12:49:48 -0400
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b06baf00d3d9746@[192.149.252.108]>
Date: Tue, 20 May 2003 12:50:55 -0400
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: [ietf-provreg] A reminder...
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_SPARSE, SPAM_PHRASE_02_03 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

A reminder, half way through the period:

>Date: Wed, 14 May 2003 15:30:29 +0200
>To: [e-mail]
>From: Edward Lewis <[e-mail]>
>Subject: WG last call for Guidelines for Extending ...EPP
>Cc: Edward Lewis <[e-mail]>, [e-mail]
>
>Let this message start a WG last call for comments on the 
>"Guidelines for Extending EPP" document.  The URL for the current 
>document is:
>
>    http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-ext-02.txt
>
>This document is intended to be forwarded to the IESG as an Informational RFC.
>
>The last call will end on May 27 [1], with the desire to forward the 
>document onward by May 30.  So far we haven't seen much discussion 
>on this document, so I don't anticipate that there will be a high 
>volume of comments.
>
>So - why advance this document and not drop it?
>
>This document was prompted by a number of efforts to extend EPP 
>outside of the WG purview.  In many cases, these folks made contact 
>with Scott for tips and hints when it was apparent that the 
>extension was going awry.  This document was asked for by the WG to 
>give others a general path toward extending EPP and to also free up 
>Scott to pursue other things - like his normally assigned work. ;)
>
>So, although this document isn't about interoperability per se, it 
>is important to the group to capture this knowledge before declaring 
>that we have defined a proposed standard version of EPP.
>
>[1] If you want to choose a specific minute - May 28, 1200 UTC.  But 
>remember, it's never too late to comment...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

Your office is *not* a reality-based sit-com TV show.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4JEvsRN016071 for <[e-mail]>; Mon, 19 May 2003 16:57:54 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h4JEvsPU016070 for ietf-provreg-outgoing; Mon, 19 May 2003 16:57:54 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4JEvrRN016065 for <[e-mail]>; Mon, 19 May 2003 16:57:53 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h4JExEdr005935; Mon, 19 May 2003 10:59:14 -0400 (EDT)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <J8TWQDVL>; Mon, 19 May 2003 10:57:50 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Otmar Lendl'" <[e-mail]>, [e-mail]
Subject: RE: [ietf-provreg] XML namespace shortcuts
Date: Mon, 19 May 2003 10:57:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Otmar,

To answer your question: yes, the second form is valid.  A bit wordier than
it needs to be, but valid.  It explicitly identifies all of the involved
namespaces using different strings for the namespace identifiers, whereas
the examples I provide attempt to balance explicit identification with
reading ease and understandability by using "epp:" as a default namespace
and strings like "host" to identify the host namespace.

More below.

-Scott-

> -----Original Message-----
> From: Otmar Lendl [mailto:[e-mail]]
> Sent: Monday, May 19, 2003 9:59 AM
> To: [e-mail]
> Subject: [ietf-provreg] XML namespace shortcuts
> 
> 
> 
> I've recently come across some issues concerning the use of XML
> namespaces within EPP. I think the draft could be a bit more 
> explicit here.
> 
> According to http://www.rpbourret.com/xml/NamespacesFAQ.htm#q3_2 ,
> namespace definitions tie namespace Names to prefixes; in the case
> of epp, this is done e.g. here:
> 
>    <host:create xmlns:host="urn:ietf:params:xml:ns:host-1.0">
> 
> which makes "host:" basically a shortcut for 
> "urn:ietf:params:xml:ns:host-1.0".

Not really.  What it does is say that the string "host" is bound to the
given namespace URI within the scope of the enclosing element.  What's
important is the URI, not the string used to identify the namespace.  That
might be what you meant to say, though, so maybe I'm agreeing with you.

> The lastest draft says:
> 
>   The EPP <create> command provides a transform operation 
> that allows a
>   client to create a host object.  In addition to the standard EPP
>   command elements, the <create> command MUST contain a <host:create>
>   element that identifies the host namespace and the location of the
>   host schema.  
> 
> This is IMHO ambiguous. As I read it, it requires that the <create>
> tag must be put into the "urn:ietf:params:xml:ns:host-1.0" namespace.

That's the correct reading, and that's why you don't see "host" written as
"host:" as you describe below.  I see where the confusion comes in, though:
saying "<host:create>" could be read as "you MUST use the string "host" to
identify the host namespace", though XML doesn't really care which string
you use as long as you use it consistently.

> But one could also read that paragraph as requiring that the 
> prefix must
> always be "host:". After all, in all the examples that is the case.

Personally I don't see it that way, but I see how it might be read that way.

> What are the real implications?
> 
> Example mod_epp:
> 
> 	mod_epp parses the XML into a DOM-tree and then serializes the
> 	tree again when passing the command to the backend. The
> 	expat-light library included in Apache 2.0 uses simple 
> 	prefixes for all known namespaces when serializing, 
> thus it turns:
> 
> 	<?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>
> 	      <host:create
> 	       xmlns:host="urn:ietf:params:xml:ns:host-1.0"
> 	       xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0
> 	       host-1.0.xsd">
> 		<host:name>ns1.example.com</host:name>
> 		<host:addr ip="v4">192.0.2.2</host:addr>
> 		<host:addr ip="v4">192.0.2.29</host:addr>
> 		<host:addr 
> ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>
> 	      </host:create>
> 	    </create>
> 	    <clTRID>ABC-12345</clTRID>
> 	  </command>
> 	</epp>
> 
> 	into
> 
> 	<ns2:epp ns1:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
> 	epp-1.0.xsd" xmlns:ns3="urn:ietf:params:xml:ns:host-1.0"
> 	xmlns:ns2="urn:ietf:params:xml:ns:epp-1.0"
> 	xmlns:ns1="http://www.w3.org/2001/XMLSchema-instance" 
> xmlns:ns0="DAV:">
> 	  <ns2:command>
> 	    <ns2:create>
> 	      <ns3:create 
> ns1:schemaLocation="urn:ietf:params:xml:ns:host-1.0
> 	host-1.0.xsd">
> 		<ns3:name>ns1.example.com</ns3:name>
> 		<ns3:addr ip="v4">192.0.2.2</ns3:addr>
> 		<ns3:addr ip="v4">192.0.2.29</ns3:addr>
> 		<ns3:addr ip="v6">1080:0:0:0:8:800:200C:417A</ns3:addr>
> 	      </ns3:create>
> 	    </ns2:create>
> 	    <ns2:clTRID>ABC-12345</ns2:clTRID>
> 	  </ns2:command>
> 	</ns2:epp> 
> 
> 	(the xmlns:ns0="DAV:" is leftover from the webDAV implementation
> 	which caused expat to be included in Apache.)
> 
> 	As I understand XML namespaces, these two paragraphs define
> 	the same XML object.
> 
> 	Is the seconds paragraph RFC-draft-compliant?

It's perfectly valid XML that satisfies the schemas listed in the drafts.
Maybe I can do something when I have a chance during the author's 48 hour
editorial review before the documents are published as RFCs.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4JDx8RN015498 for <[e-mail]>; Mon, 19 May 2003 15:59:08 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h4JDx83W015497 for ietf-provreg-outgoing; Mon, 19 May 2003 15:59:08 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from arachne.lendl.priv.at (vianet-ispa-gw01.via.at [194.96.143.146] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4JDx6RN015491 for <[e-mail]>; Mon, 19 May 2003 15:59:07 +0200 (MEST)
Received: from lendl by arachne.lendl.priv.at with local (Exim 3.36 #1 (Debian)) id 19HlAQ-0005ai-00 for <[e-mail]>; Mon, 19 May 2003 15:59:06 +0200
Date: Mon, 19 May 2003 15:59:06 +0200
From: Otmar Lendl <[e-mail]>
To: [e-mail]
Subject: [ietf-provreg] XML namespace shortcuts
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.3i
Sender: [e-mail]
Precedence: bulk

I've recently come across some issues concerning the use of XML
namespaces within EPP. I think the draft could be a bit more explicit here.

According to http://www.rpbourret.com/xml/NamespacesFAQ.htm#q3_2 ,
namespace definitions tie namespace Names to prefixes; in the case
of epp, this is done e.g. here:

   <host:create xmlns:host="urn:ietf:params:xml:ns:host-1.0">

which makes "host:" basically a shortcut for "urn:ietf:params:xml:ns:host-1.0".

The lastest draft says:

  The EPP <create> command provides a transform operation that allows a
  client to create a host object.  In addition to the standard EPP
  command elements, the <create> command MUST contain a <host:create>
  element that identifies the host namespace and the location of the
  host schema.  

This is IMHO ambiguous. As I read it, it requires that the <create>
tag must be put into the "urn:ietf:params:xml:ns:host-1.0" namespace.

But one could also read that paragraph as requiring that the prefix must
always be "host:". After all, in all the examples that is the case.


What are the real implications?

Example mod_epp:

	mod_epp parses the XML into a DOM-tree and then serializes the
	tree again when passing the command to the backend. The
	expat-light library included in Apache 2.0 uses simple 
	prefixes for all known namespaces when serializing, thus it turns:

	<?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>
	      <host:create
	       xmlns:host="urn:ietf:params:xml:ns:host-1.0"
	       xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0
	       host-1.0.xsd">
		<host:name>ns1.example.com</host:name>
		<host:addr ip="v4">192.0.2.2</host:addr>
		<host:addr ip="v4">192.0.2.29</host:addr>
		<host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>
	      </host:create>
	    </create>
	    <clTRID>ABC-12345</clTRID>
	  </command>
	</epp>

	into

	<ns2:epp ns1:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
	epp-1.0.xsd" xmlns:ns3="urn:ietf:params:xml:ns:host-1.0"
	xmlns:ns2="urn:ietf:params:xml:ns:epp-1.0"
	xmlns:ns1="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns0="DAV:">
	  <ns2:command>
	    <ns2:create>
	      <ns3:create ns1:schemaLocation="urn:ietf:params:xml:ns:host-1.0
	host-1.0.xsd">
		<ns3:name>ns1.example.com</ns3:name>
		<ns3:addr ip="v4">192.0.2.2</ns3:addr>
		<ns3:addr ip="v4">192.0.2.29</ns3:addr>
		<ns3:addr ip="v6">1080:0:0:0:8:800:200C:417A</ns3:addr>
	      </ns3:create>
	    </ns2:create>
	    <ns2:clTRID>ABC-12345</ns2:clTRID>
	  </ns2:command>
	</ns2:epp> 

	(the xmlns:ns0="DAV:" is leftover from the webDAV implementation
	which caused expat to be included in Apache.)

	As I understand XML namespaces, these two paragraphs define
	the same XML object.

	Is the seconds paragraph RFC-draft-compliant?

Example OpenReg

	OpenReg 1.0.1 completely ignores the namespace definition and
	only relies on the tag's name as encountered between < and >. 
	Thus it would choke on the second paragraph from above.

	Is that ok?

	[I've sent the ISC people a patch which solves this, btw. That
	was only about ~20 lines of diff.]

-=-=-=

I think the correct solution is to allow arbitrary namespace prefixes.

Comments?

/ol
-- 
< Otmar Lendl <[e-mail]>  | nic.at Systems Engineer >


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4EDlPRN017711 for <[e-mail]>; Wed, 14 May 2003 15:47:25 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h4EDlPHq017710 for ietf-provreg-outgoing; Wed, 14 May 2003 15:47:25 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4EDlORN017705 for <[e-mail]>; Wed, 14 May 2003 15:47:24 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id 6DF996DA; Wed, 14 May 2003 09:47:23 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id EA8606D3; Wed, 14 May 2003 09:47:22 -0400 (EDT)
Received: from [127.0.0.1] (HELO [193.0.8.217]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 257032; Wed, 14 May 2003 09:46:52 -0400
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b09bae7f23281b7@[193.0.8.217]>
Date: Wed, 14 May 2003 15:30:29 +0200
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: [ietf-provreg] WG last call for Guidelines for Extending ...EPP
Cc: Edward Lewis <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_02_03 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

Let this message start a WG last call for comments on the "Guidelines 
for Extending EPP" document.  The URL for the current document is:

    http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-ext-02.txt

This document is intended to be forwarded to the IESG as an Informational RFC.

The last call will end on May 27 [1], with the desire to forward the 
document onward by May 30.  So far we haven't seen much discussion on 
this document, so I don't anticipate that there will be a high volume 
of comments.

So - why advance this document and not drop it?

This document was prompted by a number of efforts to extend EPP 
outside of the WG purview.  In many cases, these folks made contact 
with Scott for tips and hints when it was apparent that the extension 
was going awry.  This document was asked for by the WG to give others 
a general path toward extending EPP and to also free up Scott to 
pursue other things - like his normally assigned work. ;)

So, although this document isn't about interoperability per se, it is 
important to the group to capture this knowledge before declaring 
that we have defined a proposed standard version of EPP.

[1] If you want to choose a specific minute - May 28, 1200 UTC.  But 
remember, it's never too late to comment...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

Your office is *not* a reality-based sit-com TV show.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4EBO7RN016408 for <[e-mail]>; Wed, 14 May 2003 13:24:07 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h4EBO7YW016407 for ietf-provreg-outgoing; Wed, 14 May 2003 13:24:07 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4EBO6RN016402 for <[e-mail]>; Wed, 14 May 2003 13:24:06 +0200 (MEST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12791; Wed, 14 May 2003 07:21:02 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-ext-02.txt
Date: Wed, 14 May 2003 07:21:01 -0400
Sender: [e-mail]
Precedence: bulk

--NextPart

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

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

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-ext-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.9/8.12.9) with ESMTP id h4DBlaRN000858 for <[e-mail]>; Tue, 13 May 2003 13:47:36 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h4DBlZV1000857 for ietf-provreg-outgoing; Tue, 13 May 2003 13:47:35 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4DBlYRN000852 for <[e-mail]>; Tue, 13 May 2003 13:47:35 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h4DBmvaj012243; Tue, 13 May 2003 07:48:57 -0400 (EDT)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <J8TWKCF9>; Tue, 13 May 2003 07:47:32 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: [ietf-provreg] okay, now for the next item(s)
Date: Tue, 13 May 2003 07:47:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

> ...that being said, can you add this to the document real soon now? 
> Jaap and I are at the RIPE meeting and talked about the document.  We 
> plan to issue a last call now so we can maybe get some folks to give 
> us input here.
> 
> Either way we'd like to start the unofficial semi-formal last call by 
> tomorrow, preferably with the extra diagram & text. ;)


I think I can get an updated document in today.  I'll let you know if that
doesn't happen.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4D6eZRN027664 for <[e-mail]>; Tue, 13 May 2003 08:40:35 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h4D6eZSo027663 for ietf-provreg-outgoing; Tue, 13 May 2003 08:40:35 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4D6eYRN027653 for <[e-mail]>; Tue, 13 May 2003 08:40:35 +0200 (MEST)
Received: by smtp1.arin.net (Postfix, from userid 5003) id DB1FB386; Tue, 13 May 2003 02:40:33 -0400 (EDT)
Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 822DE382; Tue, 13 May 2003 02:40:33 -0400 (EDT)
Received: from [127.0.0.1] (HELO [193.0.8.217]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 254837; Tue, 13 May 2003 02:40:09 -0400
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b04bae642c57520@[193.0.8.217]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Tue, 13 May 2003 08:40:23 +0200
To: "Hollenbeck, Scott" <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: RE: [ietf-provreg] okay, now for the next item(s)
Cc: "'Edward Lewis'" <[e-mail]>, [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,CALL_NOW,IN_REP_TO,REFERENCES,SIGNATURE_SHORT_SPARSE, SPAM_PHRASE_00_01 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

A WG last call is an informal event - it's not defined in 2026 (the 
IETF process document).  A last call in a WG is a more substantial 
nudge to get folks to read the document...

...that being said, can you add this to the document real soon now? 
Jaap and I are at the RIPE meeting and talked about the document.  We 
plan to issue a last call now so we can maybe get some folks to give 
us input here.

Either way we'd like to start the unofficial semi-formal last call by 
tomorrow, preferably with the extra diagram & text. ;)

PS - There is a presentation in the RIPE DNR WG on the state of 
EPP/provreg.  I'll be reviewing the IESG response mail.

At 11:57 -0400 5/12/03, Hollenbeck, Scott wrote:
>
>Would it be OK to get this in before a WG last call, or would you prefer to
>deal with this as a last-call comment?
>
>-Scott-

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

Your office is *not* a reality-based sit-com TV show.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4CFvpRN019375 for <[e-mail]>; Mon, 12 May 2003 17:57:51 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h4CFvpxk019374 for ietf-provreg-outgoing; Mon, 12 May 2003 17:57:51 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h4CFvnRN019369 for <[e-mail]>; Mon, 12 May 2003 17:57:49 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h4CFx4aj017111; Mon, 12 May 2003 11:59:04 -0400 (EDT)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <J8TWJBNX>; Mon, 12 May 2003 11:57:40 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: [ietf-provreg] okay, now for the next item(s)
Date: Mon, 12 May 2003 11:57:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> Three is the remaining WG draft:
>     
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-ext-01.txt
> 
> In the next few days-weeks I anticipate a last call on this document, 
> probably at least overlapping with the RIPE meeting next week.  (Jaap 
> and I will be there, we can collect comments in person.)  When we 
> pass this up, it will go as Informational.

Ed, there's one thing that I'd like to add to the draft: a flow chart or
some other form of decision tree to help the reader determine the right
place to define an extension.  I was involved in a conversation with some
people last week that made it clear to me that additional guidance is needed
in this area.

Would it be OK to get this in before a WG last call, or would you prefer to
deal with this as a last-call comment?

-Scott-


Return-Path: <[e-mail]>
Received: from bdc.altech.com.tw (adsl-61-66-6-30.NH.sparqnet.net [61.66.6.30] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h46LonRN008570 for <[e-mail]>; Tue, 6 May 2003 23:50:50 +0200 (MEST)
Message-Id: <[e-mail]>
Received: from smtp0361.mail.yahoo.com (S-SERVER01 [218.20.219.119]) by bdc.altech.com.tw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id KMGB3YCW; Wed, 7 May 2003 05:50:47 +0800
Date: Tue, 6 May 2003 21:49:23 GMT
From: [e-mail]
X-Priority: 3
To: [e-mail]
Subject: GREETING
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

FROM THE OFFICE OF ENGR.OSI RIAMHE
FEDERAL MINISTRY OF WORKS AND HOUSING 
FEDERAL SECRETARIAT OFFICE COMPLEX 
FALOMO, IKOYI - LAGOS. 


ATTN: THE PRESIDENT/CEO, 

Dear Sir, 

First, I must solicit your strictest confidence in this transaction, this is 
by virtue of it's nature as being utterly confidential and top secret as you 
were introduced to us in confidence through the Nigerian Chamber of Commerce, 
foreign trade division. 

We are top officials from the Federal Ministry of Works and Housing,(FMWH),
Federal Ministry of Finance and the Presidency, making up the Contract Review 
Panel (CRP) set up by the Federal Government of Nigeria to review contracts 
awarded by the past military administration. 

In the course of our work on the CRP, we discovered this fund which resulted 
from grossly over-invoiced contracts which were executed for theFMW&H during 
the last administration. The companies that executed the contracts have been 
duly paid and the contracts commissioned leaving the sum of US$15.4 Million 
floating in the escrow account of the Central Bank of Nigeria ready for 
payment. 

I have therefore been mandated as a matter of trust by my colleagues in the 
panel to look for an overseas partner to whom we could transfer the sum of 
US$15.4M legally subcontracting the entitlement to your company. This is 
bearing in mind that our civil service code of conduct forbids us from owning 
foreign company or running foreign account while in government service 
hence the need for an overseas partner. 

We have agreed that the funds will be shared thus after it has been paid into 
your account: 

(1) 30% of the money will go to you for acting as the beneficiary of the fund.

(2) 10% has been set aside as an abstract projection for reimbursment to both 
parties for incidental expences that may be incurred in the course of the 
transaction. 
(3) 60% to us the government officials (with which we wish to commence an 
importation business in conjunction with you ). 

All logistics are in place and all modalities worked out for the smooth 
conclusion of the transaction within ten to fourteen days of commencement 
after receipt of the following information: Your company name, address, 
company's details & activities, telephone & fax numbers. 

These information will enable us make the applications and lodge claims to 
the concerned ministries & agencies in favour of your company and it is 
pertinent to state here that this transaction is entirely based on trust as 
the solar bank draft or certified cheque drawable in any of the Central Bank 
of Nigeria correspondent bankers around the world is going to be made in your 
name. 

Please acknowledge the receipt of this letter using the above email address. 
Yours faithfully, 

Engr.Osi Riamhe

NB: Bank Account Details not necessary as preferred mode of payment is by 
draft or cheque 




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h45JLRRN021412 for <[e-mail]>; Mon, 5 May 2003 21:21:27 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h45JLRug021411 for ietf-provreg-outgoing; Mon, 5 May 2003 21:21:27 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h45JLPRN021406 for <[e-mail]>; Mon, 5 May 2003 21:21:26 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id 5A85A2F8; Mon,  5 May 2003 15:21:25 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id C76D22F4; Mon,  5 May 2003 15:21:24 -0400 (EDT)
Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 225148; Mon, 05 May 2003 15:10:43 -0400
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b04badc65b02231@[192.149.252.108]>
Date: Mon, 5 May 2003 15:21:20 -0400
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: [ietf-provreg] okay, now for the next item(s)
Cc: Edward Lewis <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_00_01 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

As Ted has mentioned, the IESG will be considering our core documents 
real soon.

We have two other outstanding items, okay three.

One is to clean up the milestones - a couple on the web page should 
have been deleted.

Two is that alternative transports is an issue that is essentially 
dead in the WG.  Not saying that alternative transports are illegal, 
forbidden, or otherwise politically untenable, just that there hasn't 
been enough energy to date to work on them as a WG item.  I don't 
foresee any lightening bolts in this area hitting soon, and 
considering that we just have one more work item, it might be that 
the WG is shut down without a second transport document.  (See my 
note below about what shutting down the group means.)

Three is the remaining WG draft:
    http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-ext-01.txt

In the next few days-weeks I anticipate a last call on this document, 
probably at least overlapping with the RIPE meeting next week.  (Jaap 
and I will be there, we can collect comments in person.)  When we 
pass this up, it will go as Informational.

What does it mean to close a WG?  It means that there are no formal 
document discussions, no IETF in person meetings, no nagging chairs 
whining about process and consensus.  However, you still have a 
mailing list, so long as there is a volunteer to maintain it.  (I'm 
not saying that cafax.se has hinted that it would pull the list 
service, but it is something to keep in mind, someone might want to 
be ready to take it over if need be.)

I'm sure there will be traffic on the list after the group closes 
down.  I'll stay subscribed for reference purposes, for one.  On this 
list implementation issues can be discussed and collected until it is 
time to progress from Proposed to Draft Standard.  When that time 
comes, a new WG will be formed to do the needed document review - and 
I trust that the formation of that will be a lot easier than the 
formation of the current one (there'll be a pre-existing charter to 
copy).

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

Note to pilots: a three-point landing SHOULD NOT include a wing.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h45IiPRN021086 for <[e-mail]>; Mon, 5 May 2003 20:44:25 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h45IiP08021085 for ietf-provreg-outgoing; Mon, 5 May 2003 20:44:25 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h45IiORN021080 for <[e-mail]>; Mon, 5 May 2003 20:44:24 +0200 (MEST)
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h45IiIJo017055; Mon, 5 May 2003 11:44:19 -0700 (PDT)
Received: from qualcomm.com (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h45IiEkQ014922; Mon, 5 May 2003 11:44:16 -0700 (PDT)
Date: Mon, 5 May 2003 11:44:14 -0700
Subject: Re: [ietf-provreg] provreg wg responses to IESG comments
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: [e-mail]
To: Edward Lewis <[e-mail]>
From: Ted Hardie <[e-mail]>
In-Reply-To: <a05111b02bad2d71131b5@[192.136.136.76]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Sender: [e-mail]
Precedence: bulk

Thanks for the message and all of your work on the documents.  I've 
asked that
these documents go on to the next IESG telechat agenda.  Because one of 
the
original discuss comments was from a member of the IESG who is no longer
serving, current practice requires that these appear on an agenda.   
This is
not a complete re-ballot of the issue; Jon, in this case, will 
represent Scott Bradner
in evaluating the document and responses given by the working group.  
I've
asked the continuing IESG members to review the responses as quickly
as possible.
			thanks again,
						Ted Hardie



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h42FAjRN019164 for <[e-mail]>; Fri, 2 May 2003 17:10:45 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h42FAjtN019163 for ietf-provreg-outgoing; Fri, 2 May 2003 17:10:45 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h42FAhRN019158 for <[e-mail]>; Fri, 2 May 2003 17:10:43 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id C5629452; Fri,  2 May 2003 11:10:42 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 7482144F for <[e-mail]>; Fri,  2 May 2003 11:10:40 -0400 (EDT)
Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 222556; Fri, 02 May 2003 11:00:10 -0400
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b0bbad839eba906@[192.149.252.108]>
Date: Fri, 2 May 2003 11:10:53 -0400
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: [ietf-provreg] For the archives, full minutes of the meeting in SF
Cc: Edward Lewis <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BALANCE_FOR_LONG_20K,RISK_FREE,SIGNATURE_SHORT_SPARSE, SPAM_PHRASE_01_02 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

For one reason or another, the minutes for the SF meeting have taken 
a long time to appear.  The Jabber logs were used for the official 
minutes that were due two weeks ago.  In the "better late than never" 
category, here are the other minutes taken by Kim Davies.  This is 
the first posting of them, please take time to review them to see if 
1) they are accurate and 2) if there are questions about the 
discussions.

  - - - -

IETF 56 - Provisioning Registry Protcol (provreg)

Administrivia:
     - Chairs: Ed Lewis (EL) and Jaap Akkerhuis (JA)
     - Scribe: Kim Davies; Jabber: Andrew Newton

Agenda Bashing:
     - Agenda has been revised recently due to recent developments.
     - For bull session, need to firstly identify what needs to be
       solved - work out what the IESG comment means - and also address
       the concerns people have about building to that requirement.

State of the Group:
     - Group hinged on one issue that is causing many problems.
     - Answers to IESG comments
         - www.cafax.se/ietf-provreg/maillist/2003-03/msg00067.html
     - Core Documents (proposed standards):
         - EPP
         - EPP Contact Mapping
         - EPP Domain Name Mapping
         - EPP Host Mapping
         - EPP Transport over TCP
     - Remainign Document (informational):
         - Guidelines for Extending the Extensible Provisiong Protocol
     - Other documents exist as individual submissions, not working group
       candidates now.
     - Nothing stops experimentation.
         - Why are documents being discouraged? Track record is that
           no documents has gathered general interest in some time.
     - Aim to shutdown the group once core documents and 1 informational
       document is published.
     - Milestones:
         - March 2003: Respond to IESG Comments, Submit Guidelines for
           extending EPP.
         - April 2003: Decision on Alternative Transports
         - Likely to drop the remaining for September/October 2003
           (Perform interoperability tests, submit reports and revised
           specifications to IESG). If people really want to do this,
           to bring documents to Draft Standard, could reconvene later.

     - Rick Wesson (RW): Should we be evaluating extensions?

     - EL: The track record is that nothing has come along that
       was a good example of what we want to do. If someone wants
       to do something themselves there is no interoperability
       considerations - so why would the WG need to look at it.
       Also - we have not seen any drafts to describe them.

     - Scott Hollenbeck: Some of the extensions I have seen are not
       of interest to this WG, but of interest to others.

     - RW: We should have the opportunity to discuss it.

     - EL: We haven't seen a reason to justify the groups existence
       based on what has come in. We dont want to have the group
       constituted based on what may or may not come. Any extensions
       so far have not needed WG review.

     - RW: So the only way an extension gets documents is through an
       individual submission?

     - EL: Yes, we have to see enough support from the group to
       bring it in to the group.

     - AN: If it is being published as informational it could just
       go directly to the RFC Editor.

     - John Klensin: Are you going to address I18N issues or just assume
       everything is IDNA?

     - SH: If the issues are significant enough to warrant protocol
       changes that is suitable for an extension. The protocol already
       supports Unicode.

Privacy "bull" session:

     - Ted Hardie: I believe I can represent Randy Bush and Patrick
       Faltstrom's opinions on this. Scott has explained each IESG
       comment and its resolution. I believe Allison's comments have
       been resolved by these. I believe you are correct that the one
       remaining issue is the privacy issue raised by Randy Bush.
       "Why do domain/contact/.. not have granular information about
       privacy?" The suggestion was making the existing DCP element
       mandatory. I quoted this to Randy. All we are talking about
       is the registry-registrar part of it. DCP handles the registry
       telling the registrar the privacy policy of the registry. It
       is inheriting parts from EPP. In that case, when the registry
       and registrar have agreed on the way privacy is that if the
       registrant expresses privacy concerns to the registrar, the
       registrar evaluates the preference against the registry policy
       and if they dont match rejects the registration.
       Randy has said, OK, lets assume the registry handles these
       preferences and the registrar passes through the registrants
       privacy needs as expressed. He would like to see a standard
       mechanism available so the registrant and registry can make
       that decision too.

       This is not a mechanism that must be turned on, it just needs to exist
       in the protocol. He put it as per-element granularity for social data.
       The way I put this to Scott accidentally implied a particular syntax,
       which was wrong. He believes the protocol needs the registry and
       registrar to agree that it is the registry who will handle the
       decision rather than the registrar.
       Is that clear?

     - Rich Shockey: Everyone would like to do this but it adds
       complication. It could require a rewrite of contracts between
       registries and registrars, and registries and ICANN. A protocol
       burden being placed on registries and registrars that may not be
       able to be accomplished in a legal environment.

     - TH: I get no sense that this needs to be turned on in any
       bilateral agreement. If they can't do it, it does not need
       to be turned on. By creating a protocol mechanism, you believe
       it is going to imply something about the R-R relationship?

     - EL: We are being asked to make the protocol allow to do this?

     - RB: It must be mandatory to implement, optional to use.

     - RW: If these things were used today, it would violate our ICANN
       contracts.

     - RB: That is your problem.

     - RW: I agree we need to ignore these things and move it through. It is
       up to ICANN to mandate it.

     - RS: We want to do the right thing. When it is mandatory to implement
       and optional to use that is relatively OK. But what happens if the
       registrar sends the flags "do not use" and we ignore that, that
       causes a rat hole. If we dont accept the data it is a rejection of
       the registration which we cant do either.

     - JK: With all due respect I think this is a red herring. If
       we accept this is true. If you think it is a contract problem
       then you should not accept registrations with the wrong bits.

     - EL: One of the questions I have here for the IESG was about laws and
       protocols. This is the first time I have seen this argument clearly.
       I didn't see now the issue was anything more than privacy.

     - RB: Our job as protocol designers is simply to make sure the
       mechanisms are there.

     - TH: One thing I have inferred from Randy. We dont want to get into
       silly states where one party sends one state, and another sends
       another; and we dont want a sitation of arbiting the intersection.
       In a particular R-R mapping, only one is in use, so a registry using
       a DCP model can drop the request on the floor if it doesn't match.
       You can either use DND or DCP. I can then take my individual privacy
       policies and figure if they match it.

     - RB: Yes, there are many aspects of this protocol where if you
       dont like it you can throw it away.

     - TH: We had said DCP was mandatory. If they have made the decision to
       have the registry forward the information, if they use that can they
       not use DCP?

     - RB: DCP is aggregated DND in one sense.

     - TH: DCP is the glob that expresses privacy policy.

     - EL: DNP? Do not publish?

     - EL: Should it be per session?

     - RW: I have a real problem that we have to educate the ADs on these
       topics. As an implementor I have a particular view I would like to
       express with AD's negotiating their position before I express my
       point of view. I would like the DNP as a per object container, not
       per session.

     - RS: I consider this only applying to social information - personal
       information. I would make it explicit that we are referring to this.

     - SH: I had some conversations with patrick to get clarification on
       this information. He said we cant narrow this down to social
       information as that is a policy decision. SO it needs to be
       supported for all elements.. IP addresses etc.

     - RB: Are there any grey areas?

     - SH: Not that we know about.

     - RW: Talking about silly states. If someone marks their IP address
       as do-not-disclose, it should just return an error.

     - Edmon Chung: How does one disclose for what it can not be disclosed?

     - TH: A registrar talking to a registry needs to know about that
       bilaterial exchange.

     - George Michaelson: Randy is making a case for work being done to the
       protocol, and we are discussing policy issues. These areas are at right
       angles. Implement the feature, and pursue the social policy issues
       later. If we don't support it we are making a policy decision we don't
       want to support this behaviour.

     - RS: The adverse argument, if the feature is implemented, our
       courts might read that the feature is there and not being uses
       implies a behaviour. If it is there implies a kind of mandatory
       use. This is a rat-hole of legal issues.

     - EL: One of my questions before I saw this as a technical problem,
       it seems as if we are engineering to legal requirements. Some people
       falt it this way. I think it is clear now with this situation is
       we are trying to shift where an algorithm decision is made.

     - RB: We just want to give a protocol mechanism to allow people to
       do this. In different cultures it can be handled differently.

     - RS: I have to play Lessig - Code is Law at some times. What we do
       has legal implications we have to live with.
       The fact it is mandatory to implement, lawyers will start to sue on
       these kinds of things.

     - EL: I know enough about the law to know that I know nothing.
       We are here as engineers. We should stick to that and not worry
       about the law unless we know there is an empirical reason not to
       do this.

     - RW: I agree with RS there are legal trickle down problems, but I want
       to bring this back tot he technical. I want to see a proposal on how
       to do this. I want to do this on a per-registration basis. I dont know
       if they can be submitted on a per update basis. Per object I would like
       to describe what bits get set on each element. The legal issues will
       get us nowhere.

     - TH: You do not need to wait for the privacy draft from Blaze. My
       presumption is the protocol mechanism will allow expressing preference
       to the registry. Once it is reviewed by the IESG who had issue with
       this, it should move forward as this was the only outstanding issue.

     - EL: People seem to think this is a reasonable issue to solve.

     - Janusz Sientiewicz: There seems to be little support for "mandatory
       to implement, optional to use". Many support DCP per session. Any
       practical server implementation will only support a very limited
       subset for privacy options. There is cost in implementing things
       that are only optional.  Why should everyone be burdened with the
       cost that no-one will use.

     - EL: If it turns out no-one uses this feature, it will go away if
       we go to Draft Standard. We want to stop debating about this and
       start testing it. We can't wait for the perfect protocol - we need
       to test and refine.

     - JK: Looking at this from another perspective, ignoring the IESG.
       The likelihood of someone making a law against this protocol is somewhere
       near zero. The likelihood of a law that says you can't have this
       protocol without privacy issues, is very high given world events.
       So the make this mandatory to implement, optional to use is very
       pragmatic. So I disagree with RS.

     - RS: Extensions.

     - JK: No, for interoperability it needs to be in the core.

     - RS: I have strong objection to the fact the IESG has mandated that
       this has been done. I would rather this have been a core extensions
       that is mandatory to implement.

     - TH: I am not a lawyer, and I think this is an engineering question.
       I want to make sure the room has a common understanding of the eng.
       requirement that has been expressed. I want to check there is no
       confusion on the expectation here. Can we get a hum? Are we looking
       for a protocol mech. that allows a registrar to express to a registry
       at a binary level, a do-not-publish or do-not-disclose that applies
       on a per element basis - however it is done syntactically?

     - GW: It could be done per session though.

     - EL: The question is not yet complete...

     - TH: My understanding is, A mechanism to allow the registrar to tell
       the registry on a per element basis which elements it requires not
       be distributed or published. It doesn't mean it is syntactically on
       a per element.

     - JS: I want us to define privacy here, we should define which elements
       on the protocol level.

     - RW: There are different requirements... registry enforcement,
       registrar enforcement, per session, per object. We need a solution
       that suits all.

     - SH: I think one of the previous proposals already meets all the
       requirements expressed. [[so no extra work is needed]]

     - GM: I think we should enumerate which elements for which we consider
       the constraints should apply to identify what we consider to be the
       social data.

     - EC: Why can't this be in extensions?

     - EL: Procedurally, if we use extensions, we delay things. Plus the
       IESG would not accept it.

     - EL: Rick's request was something concrete to supply to the list.

     - RW: We dont have a concrete problem statement.

     - EL: OK:

           Want to allow "movement of enforcement point" between
           the registry and registrar. It should be mandatory to
           implement and option to use, and allow granularity of
           meta-data. It should be per element or per session.

     - RW: Another req. is that it could be expressed on a per object
       or per session basis.

     - SH: What does that mean? When a registrar creates a session they
       express parameters for the entire session. In my experience,
       no-one will want to express "every object i manipulate in this
       session i dont want you to publish"

     - RW: strike per session.

     - GM: It is only "per element" that qualifies as a social element.

     - RW: per object? per element? per facet? per value?

     - SH: See www.cafax.se/ietf-provreg/maillist/2002-12/asg00093.html
       and www.cafax.se/ietf-provreg/maillist/2002-12/msg00102.html

Extensions Document:

     - EL: Something the working group asked for a while ago. People trying to
       write extensions would come to Scott and asked if it was right. There
       was no guidance on how to do an extension to EPP. A few weeks short
       of 6 months ago. no other comments.

Host Objects:

     - EL: The one thing discussed with me in the last few weeks is the host
       objects. Hopefully someone with an issue with these will say something
       here. Scott thinks this problem is solved if you think of EPP in a
       different way. The other thing I hope to hear here is an explanation
       of EPP requiring host objects is causing people problems in doing
       registration. In Apricot I saw someone stand up and say what bad things
       EPP does to them. Hopefully someone can speak to what they said.
       Does anyone want to volunteer information about this recent discussion?

     - RW: What discussion?

     - Suzanne Woolf: We have expressions of concern from some registries.
       They should express them.

     - Frederico Neves (.br): What is the real reason to have a host object? It
       is only because of the historical model of gTLDs?

     - SH: I'll admit it started because it is the model I am familiar with.
       We have talked about this at great length on the list. I know .DE
       does this a little differently. There are bulk operations that typically
       happen in some registries that makes the object model much more
       efficient. That is why they are still there. Such as address changes,
       name changes.

     - FN: If you talk about address changes, you are only talking about
       glue records. You are only talking domains where the ns is under
       that domain. This is the only place. I only see host objects here
       handling host name changes. I see problems with registries with
       different security models. We saw on the mailing list many times
       people wondering about hostname registration by registries that dont
       have authority of the tld of that host. This is a security problem
       to have this data in your database. How do you authenticate this
       information to be put in your database and how do you know the
       people putting this information in your database is actually
       responsible or authoritative for this infomation. We know that
       there is a lot of deadlocks in this dfatabase because of this
       problems. I am just  trying to point that enforicng this in the
       protocol it is probably maintaing a model that is causing
       problems in the past.

     - SH: If I want to delegate a domain to ns1.foo.bar, whether I refer
       to that as an object or a name has no security problems.

     - Jorg Bauer: There are good reasons to use object, but there are reasons
       not to do it. We are talking here about a default mapping. It just
       defined an environment to set up a regitry. the problem comes with
       an old registry that have special policies. alot of these registries
       dont fit in this model, so they have to make a decision to either
       create new basic object and define them, or working with extensions,
       or a mixture. i think this leads us nowhere. everytime we have
       this discussion we get nowhere.

     - RW: We made a decision and we knew the implications. One problem we
       have is we cant delete a host object because it is being used by
       other domains. That is part of the trade-off. We could structure
       EPP to allow either/or... we could solve this with either functionality
       if we choose to go down that road. There is tradeoff with moth ways.
       I don't see that we cant figure out a way to integreate both, but
       what i hear is people are upset or disgruntled about using this,
       but they don't see either... a complete change. we have to do one
       or another.

     - EL: Document that is was a design choice and the rationale

     - RW: Need to find a way, now that we have more use cases, to allow
       these other uses.

     - EL: People come in late in the case, and dont want to rock the boat.

     - SH: Check the archives, discussed in the past with a proposal.
       It allows either/or. It was shot down on the list.

     - ??: another interesting thing in Australia.. we weren't using host
       objects and we are now. epp in encouraging a move to a uniform model.

     - FN: we have to write extensions to support something so basic like
       do a delegation. this is a protocol for domain delegations. this is
       a problem.

     - EL: I was hoping to hear from Joe Abley who had a good list.

Other obstacles to Proposed Standard:

     - There are a bunch of issues, like ROID, I haven't listed. Anyone
       want to speak about that. If not, we will just pass over this.
       This is one of the issues. Another issue from RW was the last
       verified in Atlanta we dicded to add as an extension.

     - RW: You say concensus and only one proposed that.

     - EL: Well there were a few. It fit the extensions solution. Now
       instead of arguing about the process. Is there anything you want
       to say about that to make us change our name?

     - RW: I will be a good person.

     - EL: Any other topics? We have the privacy stuff, and a better idea
       of the problem but not optimistic that we have a solution. If that
       works we have the proposed standard documents. SO I am grovelling
       for any other reasons to have something else said about the docs?
       If not, we're done.

       OK, so we are done. Thanks for showing up.

       Actions are to take privacy problem to mailing list. I will send
       out a summary.

       RW: Succinctly state the problem in 3-4 sentences when sent to the
       list, indented a few spaces.

       Message will go out early next week, when I get home. After a week
       after that, will send out solutions. Period of a month? Well before
       Vienna.

     - SH: What to do with the _09 draft? The queue was closed. That makes
       the DCP mandatory. I hear today that is not where we are going and
       there is no risk of expiry
     - RW: and people implement these drafts if he says DCP is mandatory it
       will end up in implementations.

     - EL: That question should go to the mailing list. some people said
       if the IESG agrees to this they agree. as that is not enough we
       have to reask this.
     - RW: We can say now we know this does not fulfil their requirements.
       Nothing is going to change that statement.

     - EL: I admit I wasn't thinking that way during the discussion.

     - TH: If you are expecting implementations that might do the wrong
       thing then we should probably hold off.

     - EL: OK.

End of Meeting.

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

It's true, my last college class really was "Introduction to Ada."


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h41FT1RN006774 for <[e-mail]>; Thu, 1 May 2003 17:29:01 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h41FT1KC006773 for ietf-provreg-outgoing; Thu, 1 May 2003 17:29:01 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h41FT0RN006768 for <[e-mail]>; Thu, 1 May 2003 17:29:00 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id 18DD93B5; Thu,  1 May 2003 11:29:00 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 8FA713A1; Thu,  1 May 2003 11:28:59 -0400 (EDT)
Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 221192; Thu, 01 May 2003 11:18:32 -0400
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b11bad6edb72269@[192.149.252.108]>
In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF10E71A@vsvapostal8>
References: <5BEA6CDB196A4241B8BE129D309AA4AF10E71A@vsvapostal8>
Date: Thu, 1 May 2003 11:29:10 -0400
To: "Hollenbeck, Scott" <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: RE: [ietf-provreg] provreg wg responses to IESG comments
Cc: "'Edward Lewis'" <[e-mail]>, [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,IN_REP_TO,REFERENCES,SIGNATURE_SHORT_SPARSE, SPAM_PHRASE_00_01 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

At 11:19 -0400 5/1/03, Hollenbeck, Scott wrote:
>So what's your point ;-)?  Keep the text as-is, or change it to say
>something else?

As-is.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

It's true, my last college class really was "Introduction to Ada."


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h41FLsRN006703 for <[e-mail]>; Thu, 1 May 2003 17:21:54 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h41FLsLf006702 for ietf-provreg-outgoing; Thu, 1 May 2003 17:21:54 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h41FLrRN006697 for <[e-mail]>; Thu, 1 May 2003 17:21:53 +0200 (MEST)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h41FNDaj015935; Thu, 1 May 2003 11:23:13 -0400 (EDT)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <J1JWKTT9>; Thu, 1 May 2003 11:19:58 -0400
Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF10E71A@vsvapostal8>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: [ietf-provreg] provreg wg responses to IESG comments
Date: Thu, 1 May 2003 11:19:58 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> Given that we want the core to be extensible, albeit focused for now 
> on domains, I think we want to be inclusive of other ideas.  I also 
> think that the description as written accurately reflects the 
> consensus of the group when it comes the adoption of what was in P3P 
> as it relates to us.

So what's your point ;-)?  Keep the text as-is, or change it to say
something else?

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h41F7ZRN006523 for <[e-mail]>; Thu, 1 May 2003 17:07:35 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h41F7ZuZ006522 for ietf-provreg-outgoing; Thu, 1 May 2003 17:07:35 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h41F7YRN006517 for <[e-mail]>; Thu, 1 May 2003 17:07:34 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h41Ev8Zj027935 for <[e-mail]>; Thu, 1 May 2003 10:57:09 -0400 (EDT)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: [ietf-provreg] Where "individual" means ... plural or fictive
Date: Thu, 01 May 2003 10:57:08 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Apropos of an issue settled, I learned in yesterday's P3P Spec WG call that
at least one EU jurisdiction does extend the sense of "individual" to entities
other than persons -- Italy. Additionally, Greece may also have waived that
distinction.

File under trivia.
Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h41EsiRN006386 for <[e-mail]>; Thu, 1 May 2003 16:54:44 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h41Esi2Y006385 for ietf-provreg-outgoing; Thu, 1 May 2003 16:54:44 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h41EshRN006379 for <[e-mail]>; Thu, 1 May 2003 16:54:43 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id 0F81350D; Thu,  1 May 2003 10:54:41 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 922D2485; Thu,  1 May 2003 10:54:40 -0400 (EDT)
Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 221149; Thu, 01 May 2003 10:44:13 -0400
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b0cbad6e358b41e@[192.149.252.108]>
In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF10E70D@vsvapostal8>
References: <5BEA6CDB196A4241B8BE129D309AA4AF10E70D@vsvapostal8>
Date: Thu, 1 May 2003 10:54:49 -0400
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: RE: [ietf-provreg] provreg wg responses to IESG comments
Cc: Edward Lewis <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,IN_REP_TO,MARKETING,REFERENCES,SIGNATURE_SHORT_SPARSE, SPAM_PHRASE_00_01 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

Trimmed the cc list a bit:

>I think it's important to be up front with the purpose of this element,
>which is to disclose that data might be used to contact individuals for
>marketing purposes.  Softening the text to make this less obvious sounds
>like a bad move to me.  It might help me understand where you're coming from
>if you explain why you think that disclosing direct marketing practices is a
>bad idea.

Given that we want the core to be extensible, albeit focused for now 
on domains, I think we want to be inclusive of other ideas.  I also 
think that the description as written accurately reflects the 
consensus of the group when it comes the adoption of what was in P3P 
as it relates to us.

Judging from omissions in the old DNS documents, it's better to 
mention as much as possible even if you think that doing so might 
lead to bad ideas.  Bad ideas that stem from unclear sections of text 
are much harder to debate and fix.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

It's true, my last college class really was "Introduction to Ada."