Subject: UK MensHealth Discount ID553591

From: © Pfizer Inc ® 1990-2010 <[email-masked]>
Date: Sun, 31 Jan 2010 20:58:52 -0800 (PST)

1.2.2010

New from WebMD: Dear [email-masked] Sign-up today!

You are subscribed as [email-masked].

View and manage your WebMD newsletter preferences.

Subscribe to more newsletters. Change/update your email address.

WebMD Privacy Policy
WebMD Office of Privacy
1175 Peachtree Street, Suite 2400, Atlanta, GA 30361
2010 WebMD, LLC. All rights reserved.

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0VFNJNp014012 for ; Sun, 31 Jan 2010 16:23:19 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0VFNJuh028754 for ietf-provreg-outgoing; Sun, 31 Jan 2010 16:23:19 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0VFNIJY002467 for ; Sun, 31 Jan 2010 16:23:18 +0100 (MET)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o0VF4HsR016562; Sun, 31 Jan 2010 10:04:18 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 31 Jan 2010 10:23:16 -0500
Received: from 10.169.80.3 ([10.169.80.3]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Sun, 31 Jan 2010 15:23:15 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Sun, 31 Jan 2010 10:23:13 -0500
Subject: Re: [ietf-provreg] rfc4310bis 03 AD Feedback
From: James Gould
To: Michael Young , Howard Eland
CC: EPP Provreg , Andrew Sullivan
Message-ID:
Thread-Topic: [ietf-provreg] rfc4310bis 03 AD Feedback
Thread-Index: AcqiVsGOh2oLclurS0m88aVXX4taDwAMowR7
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
X-OriginalArrivalTime: 31 Jan 2010 15:23:16.0275 (UTC) FILETIME=[4F934030:01CAA289]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o0VFNIJY022625
Sender: [email-masked]
Precedence: bulk

Michael & Howard,

Do either you have thoughts related to the maxSigLife attribute in RFC 4310?
In review, the AD had the following comment to the draft:

>> An OPTIONAL element that indicates a child's
>> preference for the number of seconds after signature generation
>> when the parent's signature on the DS information provided by the
>> child will expire. A client SHOULD specify the same > maxSigLife> value for all elements associated with
>> a domain. If the is not present, or if
>> multiple values are requested, the default
>> signature expiration policy of the server operator (as determined
>> using an out-of-band mechanism) applies.
>
> I am slightly surprised that the latter is not an error condition.
> But if this what people have implemented, then Ok.

I agree that at a minimum the server should return an error instead of
applying the server default when multiple maxSigLife values are requested.
To address this I have the following options. I would like to hear from
anyone using the maxSigLife attribute or planning on using the maxSigLife
attribute.

1. Keep the maxSigLife as an element of secDNS:dsData or secDNS:keyData.
Update the text to require the server to return an 2305 ³Object association
prohibits operation² or 2004 ³Parameter value range error² error when
multiple maxSigLife values are requested. I¹m leaning towards the 2004
error. I would also recommend that we change ³A client SHOULD specify the
same value² to ³A client MUST specify the same
value², since I don¹t know the use case where the value
could be different per DS.
2. Move the maxSigLife element out of the secDNS:dsData and secDNS:keyData,
so that it can be set as a single value for a domain. The maxSigLife
applies to the RRSIG, so it doesn¹t make much sense to set it at the DS
level. This would mean that maxSigLife would be an optional element
directly under secDNS:create, secDNS:update, and secDNS:infData. This
breaks backward compatibility, but backward compatibility is already broken
by changing the URI.
3. Remove the maxSigLife element all together. This doesn¹t sound like much
of an option if there are servers using it. This breaks backward
compatibility, but backward compatibility is already broken by changing the
URI.
4. Update the text to allow for different maxSigLife values without the
server applying the default. If we allow for multiple maxSigLife values I
don¹t believe it is correct for the server to return a successful response
and then pretty much ignore the requested values.

If there are any other options for this or if there are preferences to the
options I proposed above, please respond to the list or to me privately.

Thanks,

--

JG

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior written
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

From: Andrew Sullivan
Date: Sun, 31 Jan 2010 03:59:29 -0500
To: EPP Provreg
Subject: Re: [ietf-provreg] rfc4310bis 03 AD Feedback

On Fri, Jan 29, 2010 at 10:15:13AM -0500, James Gould wrote:
> Is there anyone out there supporting or planning on supporting the client
> specified maxSigLife. In looking into this in more detail if this attribute

Afilias supports it now, IIRC.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0V8xZ10009950 for ; Sun, 31 Jan 2010 09:59:35 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0V8xZNg011993 for ietf-provreg-outgoing; Sun, 31 Jan 2010 09:59:35 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0V8xYXY021168 for ; Sun, 31 Jan 2010 09:59:34 +0100 (MET)
Received: from crankycanuck.ca (host002.n219-127-109-000.pri.iprevolution.ne.jp [219.127.109.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id B438E1ECC15B for ; Sun, 31 Jan 2010 08:59:32 +0000 (UTC)
Date: Sun, 31 Jan 2010 03:59:29 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] rfc4310bis 03 AD Feedback
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References:
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Fri, Jan 29, 2010 at 10:15:13AM -0500, James Gould wrote:
> Is there anyone out there supporting or planning on supporting the client
> specified maxSigLife. In looking into this in more detail if this attribute

Afilias supports it now, IIRC.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0UHs5fp002082 for ; Sat, 30 Jan 2010 18:54:05 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0UHs5gZ007882 for ietf-provreg-outgoing; Sat, 30 Jan 2010 18:54:05 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0UHs47H020193 for ; Sat, 30 Jan 2010 18:54:04 +0100 (MET)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NbHWB-0000dK-BB; Sat, 30 Jan 2010 18:53:59 +0100
Date: Sat, 30 Jan 2010 18:53:59 +0100 (CET)
From: Bernie Hoeneisen
X-X-Sender: [email-masked]
To: Alexey Melnikov
cc: [email-masked], [email-masked], EPP Provreg
Subject: [ietf-provreg] Re: Last Call: draft-gould-rfc4310bis (Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol
In-Reply-To: <[email-masked]>
Message-ID:
References: <[email-masked]>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: [email-masked]
X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false
Sender: [email-masked]
Precedence: bulk

Hi Alexey

On Sat, 30 Jan 2010, Alexey Melnikov wrote:

> Many Area Directors put documents on IESG telechats before IETF Last Calls
> are over. In such cases Area Directors assume that any issues will be settled
> before the selected telechat date. But a document can be moved to another
> telechat or taken off any particular telechat at any moment.

Thanks for your clarifications on this.

>> The current proposal is still premature.
>
> Ok, I will make sure the issues are resolved before the document goes to
> IESG.

Good.

>> Furthermore due to lack of a Working Group (and lack of an _official_
>> IETF mailing list for EPP ), many stakeholders are not even aware of
>> EPP proposals going through standardization, which is somewhat in
>> contradiction to the IETF transparency goals.

> Can you please explain your concerns about lack of an official IETF mailing
> list?

I care about the following:

1) Quality of the Standards
2) Openness / transparency of the Standards process
3) Checks and balance in the system

I am not sure whether the EPP standardization has always addressed these
points adequately in the past.

Since the provreg WG has been closed (approx. 7 years ago), quite some
standardization work has been done on EPP. The proposals were discussed on
the provreg list (hosted outside IETF for historical reasons) and went
through the IESG as AD sponsored. I am not sure whether all the relevant
stakeholders have been involved in this process adequately.

To come back to your question: An _official_ mailing list hosted by the
IETF makes it easier for people, who do not know the history of EPP, to
get to know about ongoing standardization work and join the discussion
early.

The more I think about, the more I believe we need a Working Group to
handle (future) Registry/Registrar related matters such a EPP (but that's
a different topic...).

Have a nice weekend!

cheers,
Bernie

--

http://ucom.ch/
Tech Consulting for Internet Standardization
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0U9VPeN018524 for ; Sat, 30 Jan 2010 10:31:25 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0U9VPfH023288 for ietf-provreg-outgoing; Sat, 30 Jan 2010 10:31:25 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0U9VOBC010139 for ; Sat, 30 Jan 2010 10:31:24 +0100 (MET)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1Nb9fi-0008VB-GM; Sat, 30 Jan 2010 10:31:18 +0100
Date: Sat, 30 Jan 2010 10:31:18 +0100 (CET)
From: Bernie Hoeneisen
X-X-Sender: [email-masked]
To: [email-masked], Alexey Melnikov
cc: [email-masked], EPP Provreg
Subject: [ietf-provreg] Re: Last Call: draft-gould-rfc4310bis (Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol
Message-ID:
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: [email-masked]
X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false
Sender: [email-masked]
Precedence: bulk

I am a bit puzzeled that according to

https://datatracker.ietf.org/idtracker/draft-gould-rfc4310bis/

draft-gould-rfc4310bis has already been placed on the IESG Telechat
agenda, before the IETF Last Call has even ended.

Did this happen intentionally or by mistake?

Please be informed that on the provreg mailing list

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

there is a heavy discussion going on about the shortcomings of the current
proposal. At least two issues have been identified so far:

1) XML namespace (interoperability issues as with the current proposal
the feature negotiation does not work anymore as defined by the EPP
core spec)

2) need for active / inactive flag (e.g. to mark a DS to be used for
emergency key rollover)

Before these (and other) issues have been resolved, IMHO it does not make
sense to discuss the I-D on the IESG Telechat.

The current proposal is still premature.

Furthermore due to lack of a Working Group (and lack of an _official_ IETF
mailing list for EPP), many stakeholders are not even aware of EPP
proposals going through standardization, which is somewhat in
contradiction to the IETF transparency goals.

Have a nice weekend!

cheers,
Bernie

--

http://ucom.ch/
Tech Consulting for Internet Standardization

Original Message:
> [...]
> Please send substantive comments to the
> [email-masked] mailing lists by 2010-02-16. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
> [...]
> IESG discussion can be tracked via
> [...]
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19451&rfc_flag=0
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0TGFn45007625 for ; Fri, 29 Jan 2010 17:15:49 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0TGFno0005628 for ietf-provreg-outgoing; Fri, 29 Jan 2010 17:15:49 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0TGFmLS005702 for ; Fri, 29 Jan 2010 17:15:48 +0100 (MET)
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o0TFuqSO001763; Fri, 29 Jan 2010 10:56:52 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 11:15:46 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Fri, 29 Jan 2010 16:15:46 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Fri, 29 Jan 2010 10:15:13 -0500
Subject: Re: [ietf-provreg] rfc4310bis 03 AD Feedback
From: James Gould
To:
CC: EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] rfc4310bis 03 AD Feedback
Thread-Index: AcqgMxyUZt5wcbEwS8urg3QSuo1DmgAwr4ci
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3347608530_11645765"
X-OriginalArrivalTime: 29 Jan 2010 16:15:46.0895 (UTC) FILETIME=[50AA35F0:01CAA0FE]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3347608530_11645765
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Is there anyone out there supporting or planning on supporting the client
specified maxSigLife. In looking into this in more detail if this attribut=
e
were supported, doesn=B9t it make more sense for it to be an attribute outsid=
e
the dsData or keyData, since it applies to the domain=B9s RRSIG and not to an
individual DS? This means that it=B9s an attribute of the domain and not of
the DS. Since we=B9re not worried about backward compatibility any longer
with the change in the URI we=B9re open to remove or move this element. Any
thoughts to this? =20

--=20

JG=20

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

=20
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior writte=
n
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

From:
Date: Thu, 28 Jan 2010 11:00:52 -0500
To: James Gould
Cc: EPP Provreg
Subject: Re: [ietf-provreg] rfc4310bis 03 AD Feedback

> An OPTIONAL element that indicates a child's
> preference for the number of seconds after signature generation
> when the parent's signature on the DS information provided by the
> child will expire. A client SHOULD specify the same maxSigLife> value for all elements associated with
> a domain. If the is not present, or if
> multiple values are requested, the default
> signature expiration policy of the server operator (as determined
> using an out-of-band mechanism) applies

Please forgive my ignorance, as I wasn't around when 4310 was written.

What's the rationale for giving the child _any_ say in the DS record
signature lifetimes as presented in the parent zone?

kind regards,=20

Ray=20

--=20
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

--B_3347608530_11645765
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] rfc4310bis 03 AD Feedback

Is there anyone out there supporting or planning on supporting the client =
specified maxSigLife.  In looking into this in more detail if this attr=
ibute were supported, doesn’t it make more sense for it to be an attri=
bute outside the dsData or keyData, since it applies to the domain’s R=
RSIG and not to an individual DS?  This means that it’s an attrib=
ute of the domain and not of the DS.  Since we’re not worried abo=
ut backward compatibility any longer with the change in the URI we’re =
open to remove or move this element.  Any thoughts to this?

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

From: <[email-masked]>

Date: Thu, 28 Jan 2010 11:00:52 -0500

To: James Gould <[email-masked]=
m>

Cc: EPP Provreg <ietf-provreg@caf=
ax.se>

Subject: Re: [ietf-provreg] rfc4310bis 03 AD Feedback

>   An OPTIONAL <secDNS:maxSigLife> element that indicat=
es a child's

>   preference for the number of seconds after signature gener=
ation

>   when the parent's signature on the DS information provided=
by the

>   child will expire.  A client SHOULD specify the same =
<secDNS:

>   maxSigLife> value for all <secDNS:dsData> element=
s associated with

>   a domain.  If the <secDNS:maxSigLife> is not pr=
esent, or if

>   multiple <secDNS:maxSigLife> values are requested, t=
he default

>   signature expiration policy of the server operator (as det=
ermined

>   using an out-of-band mechanism) applies

Please forgive my ignora=
nce, as I wasn't around when 4310 was written.

What's the rationale for=
giving the child _any_ say in the DS record signature lifetimes as presente=
d in the parent zone?=

kind regards,

Ray

--

Ray Bellis, MA(Oxon) MIET

Senior Researcher in Advanced Projects, Nominet

e: [email-masked], t: +44 1865 332211<=
BR>

--B_3347608530_11645765--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0SJGBm7023669 for ; Thu, 28 Jan 2010 20:16:11 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0SJGAKn012838 for ietf-provreg-outgoing; Thu, 28 Jan 2010 20:16:10 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0SJG9bn028606 for ; Thu, 28 Jan 2010 20:16:10 +0100 (MET)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o0SJBAIu025651; Thu, 28 Jan 2010 14:11:10 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 14:16:08 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Thu, 28 Jan 2010 19:16:07 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Thu, 28 Jan 2010 14:16:04 -0500
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310
From: James Gould
To: Eduardo Duarte
CC: EPP Provreg , WG-DNS
Message-ID:
Thread-Topic: off-list was Re: [ietf-provreg] Revision of 4310
Thread-Index: AcqgTlW/1GN6bOODiUqez5Prg9/nuw==
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3347532965_10531363"
X-OriginalArrivalTime: 28 Jan 2010 19:16:08.0444 (UTC) FILETIME=[5865CBC0:01CAA04E]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3347532965_10531363
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Eduardo,

So this is purely informational for the client to understand the status of
publishing DS or a key when the server is doing scheduled zone cuts? There
is inherent delay between the provisioning system and DNS with or without
dynamic updates, where the value in the central provisioning system doesn=B9t
guarantee that all of the DNS servers have fully propagated the update and
that the recursive resolvers have refreshed their cache. The client is
responsible for managing their keys (scheduled or emergency) based on
multiple timed values (time it takes the client to send the update to the
server, the time it takes the server to update the master zone, the time it
takes to update all of the slave zones, and then taking into account the
TTL). An additional attribute returned from the provisioning system is jus=
t
one piece of the puzzle that by itself won=B9t address the issue. I can see
the argument for adding a client specified flag to drive server-side
validation of when the DNSKEY is published in the child zone, but I really
don=B9t see the need for a flag for the server to indicate to the client that
the DS has been published to the parent zone. Do others feel differently
about this? =20

--=20

JG=20

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

=20
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior writte=
n
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

From: Eduardo Duarte
Date: Thu, 28 Jan 2010 18:10:27 +0000
To: James Gould
Cc: EPP Provreg , WG-DNS
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310

Hello,

Well in our case there is always a small steps in the middle... We still
don't have dynamic updates running so there will always be a small delay
from the publishing to the releasing in the zone, and we are thinking of
adding a DS validator in order to publish only the correct DS's. Also we
always have our data in the database and there we keep the multiple keys
associated with the domain some in publish state and other in a unpublished
state. So when a user adds a DS to our system he is adding it to the
database and not to the zone itself and after, when generating the zone the
script, will only pick-up and add to the zone the "actives" DS's.
So you see that between adding a record and publishing it on the zone are
some steps in the middle!

I Think this is what you where asking but if you have any more doubts, don'=
t
hesitate to ask them! ;)

Best regards,

Eduardo Duarte

James Gould wrote, On 27-01-2010 19:47:
> Re: off-list was Re: [ietf-provreg] Revision of 4310 Eduardo,
> =20
> I=B9m getting a little bit confused with the request. Can you describe the=
use
> case step-by-step on the usage of the active flag? The current RFC and d=
raft
> assumes that the server publishes the DS as soon as possible after receiv=
ing
> it from the client, where it would be considered active (with some delay =
to
> propagate) from a provisioning perspective. Is there additional server-s=
ide
> logic that I=B9m not aware of?
> =20
> Thanks,
> =20
> =20
> --=20
> =20
> =20
> JG=20
> =20
> -------------------------------------------------------
> James F. Gould
> Principal Software Engineer
> VeriSign Naming Services
> [email-masked]
> Direct: 703.948.3271
> Mobile: 703.628.7063
> =20
> =20
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
> =20
> Notice to Recipient: This e-mail contains confidential, proprietary and=
/or
> Registry Sensitive information intended solely for the recipient and, th=
us
> may not be retransmitted, reproduced or disclosed without the prior writ=
ten
> consent of VeriSign Naming and Directory Services. If you have received
> this e-mail message in error, please notify the sender immediately by
> telephone or reply e-mail and destroy the original message without making=
a
> copy. Thank you.
> =20
> =20
> =20
>=20
> From: Eduardo Duarte
> Date: Wed, 27 Jan 2010 06:08:55 -0500
> To: EPP Provreg
> Cc: WG-DNS
> Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310
> =20
> Hello,
> =20
> First of all sorry not to have contributed yesterday but I had no time
> to read all the emails... :(
> =20
> Well when I was thinking of this flag I was thinking that it would mean
> if the key is publish in the parent zone and I was not thinking to much
> on the create/update commands but more on the info... :P
> On our work model a domain can have more then one key associated with
> domain and they can be in a active or inactive state where active means
> publish or unpublished in the parent zone.
> When adding a key I dont see the problem of it becoming automatically
> publish in the parent zone and the old key to be unpublished as soon at
> is expire or remove. But lets say the owner of the domain keep just
> adding keys! After a while if in the info command you send back all the
> keys associated with the domain you will not have a good hint of wich
> ones are publish... Or if a domain change onwer also will be a bit
> difficult to understand witch of the keys are publish without consulting
> directly the DNS server...
> Also you can say for me to send on the info command just the active key,
> but then I will be not sending all the associated data with the domain...
> So to cover this ground of sending all the data back and the state of
> the DS I proposed the active/inactive flag, that I supposed that is
> backwards compatible.
> =20
> I know that some other registries use this model for managing the client
> keys and that was why I asked if this was already been discussed...
> =20
> Best regards,
> =20
> Eduardo Duarte
> =20
> =20
> Jaap Akkerhuis wrote, On 26-01-2010 22:53:
>> > Was meant to be off-list. Because I'm diving into the details of
>> > DNSSEC itself. (And not saying anything new.)
>> >
>> > To come back to EPP, I think we need to revisit "active/inactive"=
and
>> > the implications it has to a registry.
>> >
>> > Well, since Eduardo Duarte from the .PT registry proposed it, maybe
>> > he should starts to explain what problems he wants to solve with this.
>> >
>> > jaap
>> > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D-=3D-
>> > List run by majordomo software. For (Un-)subscription and similar det=
ails
>> > send "help" to [email-masked]
>> >
>> > =20
> -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
=3D-
> List run by majordomo software. For (Un-)subscription and similar detail=
s
> send "help" to [email-masked]
> =20
> =20
> =20

--B_3347532965_10531363
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: off-list was Re: [ietf-provreg] Revision of 4310

Eduardo,

So this is purely informational for the client to understand the status of =
publishing DS or a key when the server is doing scheduled zone cuts?  T=
here is inherent delay between the provisioning system and DNS with or witho=
ut dynamic updates, where the value in the central provisioning system doesn=
’t guarantee that all of the DNS servers have fully propagated the upd=
ate and that the recursive resolvers have refreshed their cache.  The c=
lient is responsible for managing their keys (scheduled or emergency) based =
on multiple timed values (time it takes the client to send the update to the=
server, the time it takes the server to update the master zone, the time it=
takes to update all of the slave zones, and then taking into account the TT=
L).  An additional attribute returned from the provisioning system is j=
ust one piece of the puzzle that by itself won’t address the issue. &n=
bsp;I can see the argument for adding a client specified flag to drive serve=
r-side validation of when the DNSKEY is published in the child zone, but I r=
eally don’t see the need for a flag for the server to indicate to the =
client that the DS has been published to the parent zone.  Do others fe=
el differently about this?

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

From: Eduardo Duarte <[email-masked]>

Date: Thu, 28 Jan 2010 18:10:27 +0000

To: James Gould <[email-masked]=
m>

Cc: EPP Provreg <ietf-provreg@caf=
ax.se>, WG-DNS <[email-masked]>
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310

Hello,

Well in our case there is always a small steps in the middle...  We st=
ill don't have dynamic updates running so there will always be a small delay=
from the publishing to the releasing in the zone, and we are thinking of ad=
ding a DS validator in order to publish only the correct DS's. Also we alway=
s have our data in the database and there we keep the multiple keys associat=
ed with the domain some in publish state and other in a unpublished state. S=
o when a user adds a DS to our system he is adding it to the database and no=
t to the zone itself and after, when generating the zone the script, will on=
ly pick-up and add to the zone the "actives" DS's.

So you see that between adding a record and publishing it on the zone are s=
ome steps in the middle!

I Think this is what you where asking but if you have any more doubts, don'=
t hesitate to ask them! ;)

Best regards,

Eduardo Duarte

James Gould wrote, On 27-01-2010 19:47:

<=
SPAN STYLE=3D'font-size:11pt'> Re: off-list was Re: [ietf-provreg] Revision of=
4310 Eduardo,

I’m getting a little bit confused with the request.  Can you des=
cribe the use case step-by-step on the usage of the active flag?  The c=
urrent RFC and draft assumes that the server publishes the DS as soon as pos=
sible after receiving it from the client, where it would be considered activ=
e (with some delay to propagate) from a provisioning perspective.  Is t=
here additional server-side logic that I’m not aware of?

Thanks,

--

JG

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

=
James F. Gould

=
Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, =
proprietary and/or Registry  Sensitive information intended solely for =
the recipient and, thus may not be  retransmitted, reproduced or disclo=
sed without the prior written consent of  VeriSign Naming and Directory=
Services.  If you have received  this e-mail message in error,=
please notify the sender immediately by  telephone or reply e-mail and=
destroy the original message without making a  copy.  Thank y=
ou.

From: Eduardo Duarte <[email-masked]>

Date: Wed, 27 Jan 2010 06:08:55 -0500

To: EPP Provreg <ietf-provr=
[email-masked]>

Cc: WG-DNS <[email-masked]>=

Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310<=
BR>

Hello,

First of all sorry not to have contributed yesterday but I had no time

to read all the emails... :(

Well when I was thinking of this flag I was thinking that it would mean

if the key is publish in the parent zone and I was not thinking to much

on the create/update commands but more on the info... :P

On our work model a domain can have more then one key associated with

domain and they can be in a active or inactive state where active means

publish or unpublished  in the parent zone.

When adding a key I dont see the problem of it becoming automatically

publish in the parent zone and the old key to be unpublished as soon at

is expire or remove.  But lets say the owner of the domain keep just
adding keys! After a while if in the info command you send back all the

keys associated with the domain you will not have a good hint of wich

ones are publish... Or if a domain change onwer also will be a bit

difficult to understand witch of the keys are publish without consulting
directly the DNS server...

Also you can say for me to send on the info command just the active key,
but then I will be not sending all the associated data with the domain...
So to cover this ground of sending all the data back and the state of

the DS I proposed the active/inactive flag, that I supposed that is

backwards compatible.

I know that some other registries use this model for managing the client
keys and that was why I asked if this was already been discussed...

Best regards,

Eduardo Duarte

Jaap Akkerhuis wrote, On 26-01-2010 22:53:

>      Was meant to be off-list.  Because =
I'm diving into the details of

>      DNSSEC itself.  (And not saying any=
thing new.)

>      To come back to EPP, I think we need to =
revisit "active/inactive" and

>      the implications it has to a registry.
>

> Well, since Eduardo Duarte from the .PT registry proposed it, maybe
> he should starts to explain what problems he wants to solve with this.=

>       jaap

> -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D-=3D-

> List run by majordomo software.  For (Un-)subscription and simila=
r details

> send "help" to ietf-=
[email-masked]

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=

List run by majordomo software.  For (Un-)subscription and similar det=
ails

send "help" to ietf-provr=
[email-masked]

=

--B_3347532965_10531363--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0SIAU9O028407 for ; Thu, 28 Jan 2010 19:10:30 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0SIAUBs006734 for ietf-provreg-outgoing; Thu, 28 Jan 2010 19:10:30 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from app01.fccn.pt (app01.fccn.pt [193.137.198.36]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0SIATiK002280 for ; Thu, 28 Jan 2010 19:10:29 +0100 (MET)
Received: from mx.anubis.local (ste [10.1.2.2]) by outbound.anubis.local (Postfix) with ESMTP id C879A2FDAD for ; Thu, 28 Jan 2010 18:10:28 +0000 (WET)
Received: from [193.136.44.92] (gaea.corp.fccn.pt [193.136.44.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: [email-masked]) by mx.anubis.local (Postfix) with ESMTP id ABF032FC9F; Thu, 28 Jan 2010 18:10:28 +0000 (WET)
Message-ID: <[email-masked]>
Date: Thu, 28 Jan 2010 18:10:27 +0000
From: Eduardo Duarte
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: James Gould
CC: EPP Provreg , WG-DNS
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310
References:
In-Reply-To:
Content-Type: multipart/alternative; boundary="------------000702060801040403010501"
Sender: [email-masked]
Precedence: bulk

This is a multi-part message in MIME format.
--------------000702060801040403010501
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hello,

Well in our case there is always a small steps in the middle... We
still don't have dynamic updates running so there will always be a small
delay from the publishing to the releasing in the zone, and we are
thinking of adding a DS validator in order to publish only the correct
DS's. Also we always have our data in the database and there we keep the
multiple keys associated with the domain some in publish state and other
in a unpublished state. So when a user adds a DS to our system he is
adding it to the database and not to the zone itself and after, when
generating the zone the script, will only pick-up and add to the zone
the "actives" DS's.
So you see that between adding a record and publishing it on the zone
are some steps in the middle!

I Think this is what you where asking but if you have any more doubts,
don't hesitate to ask them! ;)

Best regards,

Eduardo Duarte

James Gould wrote, On 27-01-2010 19:47:
> Eduardo,
> I'm getting a little bit confused with the request. Can you describe
> the use case step-by-step on the usage of the active flag? The
> current RFC and draft assumes that the server publishes the DS as soon
> as possible after receiving it from the client, where it would be
> considered active (with some delay to propagate) from a provisioning
> perspective. Is there additional server-side logic that I'm not aware
> of?
>
> Thanks,
>
>
> --
>
>
> JG
>
> -------------------------------------------------------
> *James F. Gould
> **Principal Software Engineer
> *VeriSign Naming Services
> [email-masked]
> *Direct:* 703.948.3271
> *Mobile:* 703.628.7063
>
>
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>
> */Notice to Recipient: /*/This e-mail contains confidential,
> proprietary and/or Registry Sensitive information intended solely for
> the recipient and, thus may not be retransmitted, reproduced or
> disclosed without the prior written consent of VeriSign Naming and
> Directory Services. *If you have received this e-mail message in
> error, please notify the sender immediately by telephone or reply
> e-mail and destroy the original message without making a copy.*
> Thank you.
> /
>
> ------------------------------------------------------------------------
> *From: *Eduardo Duarte
> *Date: *Wed, 27 Jan 2010 06:08:55 -0500
> *To: *EPP Provreg
> *Cc: *WG-DNS
> *Subject: *Re: off-list was Re: [ietf-provreg] Revision of 4310
>
> Hello,
>
> First of all sorry not to have contributed yesterday but I had no time
> to read all the emails... :(
>
> Well when I was thinking of this flag I was thinking that it would mean
> if the key is publish in the parent zone and I was not thinking to much
> on the create/update commands but more on the info... :P
> On our work model a domain can have more then one key associated with
> domain and they can be in a active or inactive state where active means
> publish or unpublished in the parent zone.
> When adding a key I dont see the problem of it becoming automatically
> publish in the parent zone and the old key to be unpublished as soon at
> is expire or remove. But lets say the owner of the domain keep just
> adding keys! After a while if in the info command you send back all the
> keys associated with the domain you will not have a good hint of wich
> ones are publish... Or if a domain change onwer also will be a bit
> difficult to understand witch of the keys are publish without consulting
> directly the DNS server...
> Also you can say for me to send on the info command just the active key,
> but then I will be not sending all the associated data with the domain...
> So to cover this ground of sending all the data back and the state of
> the DS I proposed the active/inactive flag, that I supposed that is
> backwards compatible.
>
> I know that some other registries use this model for managing the client
> keys and that was why I asked if this was already been discussed...
>
> Best regards,
>
> Eduardo Duarte
>
>
> Jaap Akkerhuis wrote, On 26-01-2010 22:53:
> > Was meant to be off-list. Because I'm diving into the details of
> > DNSSEC itself. (And not saying anything new.)
> >
> > To come back to EPP, I think we need to revisit
> "active/inactive" and
> > the implications it has to a registry.
> >
> > Well, since Eduardo Duarte from the .PT registry proposed it, maybe
> > he should starts to explain what problems he wants to solve with this.
> >
> > jaap
> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > List run by majordomo software. For (Un-)subscription and similar
> details
> > send "help" to [email-masked]
> >
> >
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> List run by majordomo software. For (Un-)subscription and similar details
> send "help" to [email-masked]
>
>

--------------000702060801040403010501
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hello,

Well in our case there is always a small steps in the middle...  We
still don't have dynamic updates running so there will always be a
small delay from the publishing to the releasing in the zone, and we
are thinking of adding a DS validator in order to publish only the
correct DS's. Also we always have our data in the database and there we
keep the multiple keys associated with the domain some in publish state
and other in a unpublished state. So when a user adds a DS to our
system he is adding it to the database and not to the zone itself and
after, when generating the zone the script, will only pick-up and add
to the zone the "actives" DS's.

So you see that between adding a record and publishing it on the zone
are some steps in the middle!

I Think this is what you where asking but if you have any more doubts,
don't hesitate to ask them! ;)

Best regards,

Eduardo Duarte

James Gould wrote, On 27-01-2010 19:47:

Re: off-list was Re: [ietf-provreg] Revision of 4310

Eduardo,

I’m getting a little bit confused with the
request.  Can you describe the use case step-by-step on the usage of
the active flag?  The current RFC and draft assumes that the server
publishes the DS as soon as possible after receiving it from the
client, where it would be considered active (with some delay to
propagate) from a provisioning perspective.  Is there additional
server-side logic that I’m not aware of?

Thanks,

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary
and/or Registry  Sensitive information intended solely for the
recipient and, thus may not be  retransmitted, reproduced or disclosed
without the prior written consent of  VeriSign Naming and Directory
Services.  If you have received  this e-mail message in error,
please notify the sender immediately by  telephone or reply e-mail and
destroy the original message without making a  copy.  Thank you.

From: Eduardo Duarte
<[email-masked]>

Date: Wed, 27 Jan 2010 06:08:55 -0500

To: EPP Provreg <[email-masked]>

Cc: WG-DNS <[email-masked]>

Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310

Hello,

First of all sorry not to have contributed yesterday but I had no time

to read all the emails... :(

Well when I was thinking of this flag I was thinking that it would mean

if the key is publish in the parent zone and I was not thinking to much

on the create/update commands but more on the info... :P

On our work model a domain can have more then one key associated with

domain and they can be in a active or inactive state where active means

publish or unpublished  in the parent zone.

When adding a key I dont see the problem of it becoming automatically

publish in the parent zone and the old key to be unpublished as soon at

is expire or remove.  But lets say the owner of the domain keep just

adding keys! After a while if in the info command you send back all the

keys associated with the domain you will not have a good hint of wich

ones are publish... Or if a domain change onwer also will be a bit

difficult to understand witch of the keys are publish without consulting

directly the DNS server...

Also you can say for me to send on the info command just the active key,

but then I will be not sending all the associated data with the
domain...

So to cover this ground of sending all the data back and the state of

the DS I proposed the active/inactive flag, that I supposed that is

backwards compatible.

I know that some other registries use this model for managing the client

keys and that was why I asked if this was already been discussed...

Best regards,

Eduardo Duarte

Jaap Akkerhuis wrote, On 26-01-2010 22:53:

>      Was meant to be off-list.  Because I'm diving into the
details of

>      DNSSEC itself.  (And not saying anything new.)

>      To come back to EPP, I think we need to revisit
"active/inactive" and

>      the implications it has to a registry.

> Well, since Eduardo Duarte from the .PT registry proposed it, maybe

> he should starts to explain what problems he wants to solve with
this.

>       jaap

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

> List run by majordomo software.  For (Un-)subscription and similar
details

> send "help" to [email-masked]

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

List run by majordomo software.  For (Un-)subscription and similar
details

send "help" to [email-masked]

--------------000702060801040403010501--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0SIA8WD007872 for ; Thu, 28 Jan 2010 19:10:08 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0SIA82X010928 for ietf-provreg-outgoing; Thu, 28 Jan 2010 19:10:08 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.dotandco.com (triglav.dotandco.com [194.242.114.22]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0SIA7HM010620 for ; Thu, 28 Jan 2010 19:10:07 +0100 (MET)
Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by mail.dotandco.com (8.13.8/8.13.8/Debian-3) with ESMTP id o0SIA5cR005320; Thu, 28 Jan 2010 19:10:06 +0100
Received: from localhost (localhost [[UNIX: localhost]]) by triglav.dotandco.com (8.13.8/8.13.8/Submit) id o0SIA4vP005315; Thu, 28 Jan 2010 19:10:04 +0100
X-Authentication-Warning: triglav.dotandco.com: patrick set sender to [email-masked] using -f
Date: Thu, 28 Jan 2010 19:10:01 +0100
From: Patrick Mevzek
To: [email-masked]
Subject: Re: [ietf-provreg] a question for the list
Message-ID: <[email-masked]>
References:
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To:
Organization: Dot And Co
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (mail.dotandco.com [127.0.0.1]); Thu, 28 Jan 2010 19:10:06 +0100 (CET)
Sender: [email-masked]
Precedence: bulk

Edward Lewis 2010-01-14 18:23
> EPP is also growing in deployments. Early it was the registration
> protocol for the ICANN shared registry model but it has been spreading to
> other registries that are not subject to ICANN's overview. With less
> "evidence" on hand, a few registries have had to modify something to get
> an EPP interface. I suspect that some of the extensions have not been
> published as RFCs (which is fine, but, it would be nice).

I confirm (as an EPP client implementor of more than 30 extensions)
that almost all EPP extensions have NOT been published as
RFCs, even as drafts except for a few exceptions, most of the times
unmaitained. Worse than that, as other have said, not all EPP
extensions specifications are available publicly.

> Based on this, I wanted to ask the audience of this list if they thought
> it would be a good idea to organize a new WG to cover EPP.

Maybe. Depending on the goals, and indeed on the global reach of
participants to avoid the previous case where ccTLDs have seen EPP as
a purely gTLD thing, before entering the arena with 5 to 10 years of
useless delay.

> I can imagine extensions being discussed here, as well as trying to
> promote the existing ones to Draft and Full. Also, a document that
> discusses what could have been done better in EPP (as maybe a
> requirements to EPP 2.0).

Some of you may recall one of my posting on this list more than one
year ago (!) with a link to some notes I've made as an implementor,
seeing many extensions of various qualities, and the rationale being
them being sometimes some shortcomings in the current EPP.

The document is still at
http://www.deepcore.org/ietf/draft-mevzek-epp-implementor-experience-00.txt
but I've not worked on it since then. It could be used as a base.

Also in light of the recent DNSSEC discussions, please have a look at
§3.3.2 that deals with some kind of EPP extensions used by some
registries (.CZ and .EU if I recall correctly) for handling key
materials.

And about using EPP for non provisioning operations, see §3.8.3

> So - the question here is - is there interest?

I really believe there are two separate points that may not be good
to deal at the same time in the same place even if there is some
overlap:

- discussion/work on an EPPv2, taking into account some current
shortcomings (such as static list of status codes, domain name
status, contact types ; handling of clTRID, etc... see my draft)

- enhancement of the current state of EPP, without changing its core,
but by taking into account all current extensions and trying to
persuade all stakeholders to work together to make some superseeding
extensions with some factorizations and enhancements (again see my
draft). Or at least producing some strong advises/recommandations to
extensions creator, as RFC3735 is a good starting point but is not
enough.

I'm personnally interested to contribute in both of them,
but I do not have a lot of free time to invest in them.
I do fear however that,
specially for the second point, even if there is indeed a lot of work
to do technically (meaning that I think many extensions could be made
better), there is a reduced probability that it would be useful in
the sense that, specially without broad participation by the
extension creators themselves, there would be no motivation to change
the current extensions as they are already deployed and working even
if not perfect.
While there was and still is a pressure for some ccTLDs to finally
switch to EPP, in part by their registrars, I do not believe there
will be the same kind of pressure to switch to "better" extensions,
because all serious registrars already adapted their software to take
into account the unavoidable fact that with each TLD there are
specific procedures and extensions to deal with.

--
Patrick Mevzek
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0SGguve023151 for ; Thu, 28 Jan 2010 17:42:56 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0SGgudq003481 for ietf-provreg-outgoing; Thu, 28 Jan 2010 17:42:56 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0SGgttD006565 for ; Thu, 28 Jan 2010 17:42:55 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 73EA81ECB4F0 for ; Thu, 28 Jan 2010 16:42:54 +0000 (UTC)
Date: Thu, 28 Jan 2010 11:42:49 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] rfc4310bis 03 AD Feedback
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References:
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Thu, Jan 28, 2010 at 04:00:52PM +0000, [email-masked] wrote:
> What's the rationale for giving the child _any_ say in the DS record
> signature lifetimes as presented in the parent zone?

The idea is that the child might want to have some maximum above which
it doesn't go, so that the child can roll keys in a predictable way.
This unfortunately ignores the effects of the RR TTL on the whole
issue, and IMO is a foot-gun loaded for bear, because it makes it
trivially easy to set the RRSIG short enough that an RRSIG expires
while in cache. Without a knob to control TTLs, I don't know why
you'd allow this to be adjusted.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0SG193r010211 for ; Thu, 28 Jan 2010 17:01:09 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0SG197u010872 for ietf-provreg-outgoing; Thu, 28 Jan 2010 17:01:09 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0SG18lK002271 for ; Thu, 28 Jan 2010 17:01:08 +0100 (MET)
DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=kiB2Q7rfiJGonGCNh4lvR4GfX3zbo4o514NKKcelRgV3CwUKpetrv9HN v7AaDETivo4gPFUGzWdNX/RoAzQNfD9VPZXZ8CFV5zd4NC/rlcH0t9sCk 4Cn7G1weCOyqqcv;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=[email-masked]; q=dns/txt; s=main.dkim.nominet.selector; t=1264694469; x=1296230469; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=[email-masked]|Subject:=20Re:=20[ietf -provreg]=20rfc4310bis=2003=20AD=20Feedback|Date:=20Thu, =2028=20Jan=202010=2016:00:52=20+0000|Message-ID:=20|To:=20James=20Gould=20 |Cc:=20EPP=20Provreg=20 |MIME-Version:=201.0|In-Reply-To:=20|References:=20; bh=c0XDG8atrhGU8AjxuNpOXp8pGIgu5xC5xeuxlcfUa+s=; b=F26rJPkW6Ucuo2yCHh/Od+9sJ1gAUzJNkLnJ/0ESMzh6yxylZxLz+uIx Uf+cJbnQ/NK2h37ShUYWjVtiJMFlyzMNPv//2Kg6Awgdnb1aQViGnQafs 2Y8eczlS6lj05Qf;
X-IronPort-AV: E=Sophos;i="4.49,360,1262563200"; d="scan'208";a="15852352"
Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 28 Jan 2010 16:00:55 +0000
In-Reply-To:
References:
To: James Gould
Cc: EPP Provreg
Subject: Re: [ietf-provreg] rfc4310bis 03 AD Feedback
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 8.5 December 05, 2008
Message-ID:
From: [email-masked]
Date: Thu, 28 Jan 2010 16:00:52 +0000
X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 28/01/2010 04:00:54 PM, Serialize complete at 28/01/2010 04:00:54 PM
Content-Type: multipart/alternative; boundary="=_alternative 0057F868802576B9_="
Sender: [email-masked]
Precedence: bulk

This is a multipart message in MIME format.
--=_alternative 0057F868802576B9_=
Content-Type: text/plain; charset="US-ASCII"

> An OPTIONAL element that indicates a child's
> preference for the number of seconds after signature generation
> when the parent's signature on the DS information provided by the
> child will expire. A client SHOULD specify the same maxSigLife> value for all elements associated with
> a domain. If the is not present, or if
> multiple values are requested, the default
> signature expiration policy of the server operator (as determined
> using an out-of-band mechanism) applies

Please forgive my ignorance, as I wasn't around when 4310 was written.

What's the rationale for giving the child _any_ say in the DS record
signature lifetimes as presented in the parent zone?

kind regards,

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

--=_alternative 0057F868802576B9_=
Content-Type: text/html; charset="US-ASCII"

>   An OPTIONAL <secDNS:maxSigLife> element that indicates
a child's

>   preference for the number of seconds after signature generation

>   when the parent's signature on the DS information provided
by the

>   child will expire.  A client SHOULD specify the same <secDNS:

>   maxSigLife> value for all <secDNS:dsData> elements
associated with

>   a domain.  If the <secDNS:maxSigLife> is not present,
or if

>   multiple <secDNS:maxSigLife> values are requested, the
default

>   signature expiration policy of the server operator (as determined

>   using an out-of-band mechanism) applies

Please forgive my ignorance, as I wasn't around when
4310 was written.

What's the rationale for giving the child _any_ say
in the DS record signature lifetimes as presented in the parent zone?

kind regards,

Ray

--

Ray Bellis, MA(Oxon) MIET

Senior Researcher in Advanced Projects, Nominet

e: [email-masked], t: +44 1865 332211

--=_alternative 0057F868802576B9_=--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0SExGVU026033 for ; Thu, 28 Jan 2010 15:59:16 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0SExGx9018983 for ietf-provreg-outgoing; Thu, 28 Jan 2010 15:59:16 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0SExFq9003578 for ; Thu, 28 Jan 2010 15:59:15 +0100 (MET)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o0SEeMEn028360 for ; Thu, 28 Jan 2010 09:40:22 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 09:59:14 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Thu, 28 Jan 2010 14:59:14 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Thu, 28 Jan 2010 09:59:11 -0500
Subject: [ietf-provreg] rfc4310bis 03 AD Feedback
From: James Gould
To: EPP Provreg
Message-ID:
Thread-Topic: rfc4310bis 03 AD Feedback
Thread-Index: AcqgKnLiY3Zn3mkbGEasPi3E9YilUw==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3347517552_9590121"
X-OriginalArrivalTime: 28 Jan 2010 14:59:14.0630 (UTC) FILETIME=[750C6E60:01CAA02A]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3347517552_9590121
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

All,

One of the items for the AD review of rfc4310bis is below. I want to bring
this up to the list for feedback, since this is text from the original RFC.

>> An OPTIONAL element that indicates a child's
>> preference for the number of seconds after signature generation
>> when the parent's signature on the DS information provided by the
>> child will expire. A client SHOULD specify the same > maxSigLife> value for all elements associated with
>> a domain. If the is not present, or if
>> multiple values are requested, the default
>> signature expiration policy of the server operator (as determined
>> using an out-of-band mechanism) applies.
>=20
> I am slightly surprised that the latter is not an error condition.
> But if this what people have implemented, then Ok.

So the question is around specifying different secDNS:maxSigLife values for
the secDNS:dsData (DS Data Interface) or secDNS:keyData (Key Data
Interface). The RFC recommends (SHOULD) that the client use the same
secDNS:maxSigLife value, but does not mandate it. The question is whether
the server signature expiration policy should apply when the client does
specify multiple values for a domain and the server accepts it. It makes
more sense to me that the server should return an error if passing a
different secDNS:maxSigLife will result in the default being applied by the
server. If an error is returned, I would propose returning 2306, since it
would be up to the server policy to have a single signature expiration
across all DS or keys of a domain. If it=B9s not up to server policy, then
the draft should use MUST instead of SHOULD for the client and the server
should return an error like 2305 =B3Object association prohibits operation=B2 o=
r
2004 =B3Parameter value range error=B2. I don=B9t believe either 2305 or 2004
match the error exactly, but I guess I would lean towards 2004. Any
opinions on which error code to use?

Please reply to the list or to me privately related to your preference on
this feedback. =20

Thanks,

--=20

JG=20

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

=20
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior writte=
n
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

--B_3347517552_9590121
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

rfc4310bis 03 AD Feedback

All,

One of the items for the AD review of rfc4310bis is below.  I want to =
bring this up to the list for feedback, since this is text from the original=
RFC.

>>       An OPTIONAL <secDNS:maxSigL=
ife> element that indicates a child's

>>       preference for the number of s=
econds after signature generation

>>       when the parent's signature on=
the DS information provided by the

>>       child will expire.  A cli=
ent SHOULD specify the same <secDNS:

>>       maxSigLife> value for all &=
lt;secDNS:dsData> elements associated with

>>       a domain.  If the <sec=
DNS:maxSigLife> is not present, or if

>>       multiple <secDNS:maxSigLife=
> values are requested, the default

>>       signature expiration policy of=
the server operator (as determined

>>       using an out-of-band mechanism=
) applies.

> I am slightly surprised that the latter is not an error condition.

> But if this what people have implemented, then Ok.

So the question is around specifying different secDNS:maxSigLife values for=
the secDNS:dsData (DS Data Interface) or secDNS:keyData (Key Data Interface=
).  The RFC recommends (SHOULD) that the client use the same secDNS:max=
SigLife value, but does not mandate it.  The question is whether the se=
rver signature expiration policy should apply when the client does specify m=
ultiple values for a domain and the server accepts it.  It makes more s=
ense to me that the server should return an error if passing a different sec=
DNS:maxSigLife will result in the default being applied by the server.  =
;If an error is returned, I would propose returning 2306, since it would be =
up to the server policy to have a single signature expiration across all DS =
or keys of a domain.  If it’s not up to server policy, then the d=
raft should use MUST instead of SHOULD for the client and the server should =
return an error like 2305 “Object association prohibits operation̶=
1; or 2004 “Parameter value range error”.  I don’t be=
lieve either 2305 or 2004 match the error exactly, but I guess I would lean =
towards 2004.  Any opinions on which error code to use?   &nb=
sp;

Please reply to the list or to me privately related to your preference on t=
his feedback.

Thanks,

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

--B_3347517552_9590121--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0SEFB4j016425 for ; Thu, 28 Jan 2010 15:15:11 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0SEFB5c025240 for ietf-provreg-outgoing; Thu, 28 Jan 2010 15:15:11 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0SEFAGt006752 for ; Thu, 28 Jan 2010 15:15:10 +0100 (MET)
Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o0SEAB1R012424; Thu, 28 Jan 2010 09:10:11 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 09:15:09 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Thu, 28 Jan 2010 14:15:08 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Thu, 28 Jan 2010 09:15:00 -0500
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis
From: James Gould
To: Ulrich Wisser
CC: Klaus Malorny , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] XML Schema versioning in 4310bis
Thread-Index: AcqgA9IML8qy9HPMQtO0kjE7nM6N/QAIHS4H
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3347514904_9403232"
X-OriginalArrivalTime: 28 Jan 2010 14:15:09.0658 (UTC) FILETIME=[4C85BBA0:01CAA024]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3347514904_9403232
Content-type: text/plain;
charset="US-ASCII"
Content-transfer-encoding: 7bit

Ulrich,

> How could I miss this? If a client (our own registrar currently does)
> send two DS records per key (SHA-1 and SHA-256), these posts could not
> be deleted with they old style .

That is correct as long as the server does what is recommended (SHOULD) by
the draft. The client should use the secDNS:dsData with a secDNS:rem to
explicitly specify which DS to remove. Does this address your concern?

--

JG

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior written
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

From: Ulrich Wisser
Date: Thu, 28 Jan 2010 05:22:31 -0500
To: James Gould
Cc: Klaus Malorny , EPP Provreg

Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis

Hi James,

[...]
> There was much discussion related to supporting the old style secDNS:rem
> with secDNS:keyTag on the list. The following text in the draft
> directly addresses the issue according to a compromise from this list:
>
> element MUST contain a key tag value as described in
> section 5.1.1 of RFC 4034 *[6]*. Removing all DS information can
> remove the ability of the parent to secure the delegation to the
> child zone. The server SHOULD return an EPP error result code of
> 2305 if more than one DS record matches the .
> should be used by the client if there is more than
> one DS record with the same .
>
>
> I would like to continue with what was compromised in addressing the
> issue of using the non-unique secDNS:keyTag. Is this not an acceptable
> solution?

How could I miss this? If a client (our own registrar currently does)
send two DS records per key (SHA-1 and SHA-256), these posts could not
be deleted with they old style .

/Ulrich

--B_3347514904_9403232
Content-type: text/html;
charset="US-ASCII"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] XML Schema versioning in 4310bis

Ulrich,

> How could I miss this? If a client (our own registrar currently does)<=
BR>
> send two DS records per key (SHA-1 and SHA-256), these posts could not=

> be deleted with they old style <rem/>.

That is correct as long as the server does what is recommended (SHOULD) by =
the draft.  The client should use the secDNS:dsData with a secDNS:rem t=
o explicitly specify which DS to remove.  Does this address your concer=
n?

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

From: Ulrich Wisser <[email-masked]>

Date: Thu, 28 Jan 2010 05:22:31 -0500

To: James Gould <[email-masked]=
m>

Cc: Klaus Malorny <Klaus.Malorny=
@knipp.de>, EPP Provreg <ietf-prov=
[email-masked]>

Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis

Hi James,

[...]

> There was much discussion related to supporting the old style secDNS:r=
em

> with secDNS:keyTag on the list.  The following text in the draft<=
BR>
> directly addresses the issue according to a compromise from this list:=

>     <secDNS:keyTag> element MUST contain a k=
ey tag value as described in

>     section 5.1.1 of RFC 4034 *[6]*. Removing all =
DS information can

>     remove the ability of the parent to secure the=
delegation to the

>     child zone. The server SHOULD return an EPP er=
ror result code of

>     2305 if more than one DS record matches the &l=
t;secDNS:keyTag>.

>     <secDNS:dsData> should be used by the cl=
ient if there is more than

>     one DS record with the same <secDNS:keyTag&=
gt;.

> I would like to continue with what was compromised in addressing the
> issue of using the non-unique secDNS:keyTag.  Is this not an acce=
ptable

> solution?

How could I miss this? If a client (our own registrar currently does)

send two DS records per key (SHA-1 and SHA-256), these posts could not

be deleted with they old style <rem/>.

/Ulrich

--B_3347514904_9403232--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0SAMcVW017736 for ; Thu, 28 Jan 2010 11:22:38 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0SAMc8j028815 for ietf-provreg-outgoing; Thu, 28 Jan 2010 11:22:38 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from lvps87-230-32-221.dedicated.hosteurope.de (mail.publisher.de [87.230.32.221]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0SAMbhL025325 for ; Thu, 28 Jan 2010 11:22:37 +0100 (MET)
Received: (qmail 22462 invoked from network); 28 Jan 2010 10:22:36 +0000
Received: from gw.iis.se (HELO ulrich-wissers-macbook-pro.local) (212.247.14.38) by mail.publisher.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 28 Jan 2010 10:22:36 +0000
Message-ID: <[email-masked]>
Date: Thu, 28 Jan 2010 11:22:31 +0100
From: Ulrich Wisser
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: James Gould
CC: Klaus Malorny , EPP Provreg
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis
References:
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

Hi James,

[...]
> There was much discussion related to supporting the old style secDNS:rem
> with secDNS:keyTag on the list. The following text in the draft
> directly addresses the issue according to a compromise from this list:
>
> element MUST contain a key tag value as described in
> section 5.1.1 of RFC 4034 *[6]*. Removing all DS information can
> remove the ability of the parent to secure the delegation to the
> child zone. The server SHOULD return an EPP error result code of
> 2305 if more than one DS record matches the .
> should be used by the client if there is more than
> one DS record with the same .
>
>
> I would like to continue with what was compromised in addressing the
> issue of using the non-unique secDNS:keyTag. Is this not an acceptable
> solution?

How could I miss this? If a client (our own registrar currently does)
send two DS records per key (SHA-1 and SHA-256), these posts could not
be deleted with they old style .

/Ulrich
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0RNAb46020924 for ; Thu, 28 Jan 2010 00:10:37 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0RNAamr022253 for ietf-provreg-outgoing; Thu, 28 Jan 2010 00:10:36 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [213.154.224.50]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0RNAaa3006354 for ; Thu, 28 Jan 2010 00:10:36 +0100 (MET)
Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id o0RNAXp8047398 for ; Thu, 28 Jan 2010 00:10:33 +0100 (CET) (envelope-from [email-masked])
Message-Id: <[email-masked]>
To: [email-masked]
Subject: [ietf-provreg] Recovered from spamtrap
Date: Thu, 28 Jan 2010 00:10:33 +0100
From: Jaap Akkerhuis
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (bartok.nlnetlabs.nl [127.0.0.1]); Thu, 28 Jan 2010 00:10:33 +0100 (CET)
X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, MISSING_MID autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bartok.nlnetlabs.nl
Sender: [email-masked]
Precedence: bulk

From: Olafur Gudmundsson
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310
Cc: EPP Provreg
In-Reply-To:
References:

Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4

At 17:22 26/01/2010, James Gould wrote:
>Yes, we kind of got into the weeds of DNSSEC specifics.
>
>I believe the request was to add a flag to the draft to allow the
>client to indicate to the server that the DNSKEY is active in the
>child zone. The definition of this needs to be clearly defined, but
>I would assume that it is that the DNSKEY is published in the child
>zone DNSKEY RRset. This is an optional attribute that the server
>can use for additional validation based on server policy. If the
>attribute is supported by the server it should be returned in the
>secDNS:infData of the domain info response. This optional attribute
>would be added to the secDNS:keyData and the secDNS:dsData
>elements. I recommend calling this attribute childKeyActive. I
>also recommend that there are no changes to the secDNS interface to
>optimize changing this attribute in a domain update.

Would Present/Not-Present be a better definition?
Present is implies the corresponding key is in the DNSKEY set at that
moment and can be checked. Not-Present says no check can be performed at
this point. As far as the parent is concerned Active is not important,
and implies that when key changes between Active and Non-Active then the
registry SHOULD be updated, which I do not think is desirable.

>Do registries in general need this and do clients want to add this
>complexity to the draft?
>
>--
>
>
>JG
>
>-------------------------------------------------------
>James F. Gould
>Principal Software Engineer
>VeriSign Naming Services
>[email-masked]
>Direct: 703.948.3271
>Mobile: 703.628.7063
>
>
>21345 Ridgetop Circle
>LS2-2-1
>Dulles, VA 20166
>
>Notice to Recipient: This e-mail contains confidential, proprietary
>and/or Registry Sensitive information intended solely for the
>recipient and, thus may not be retransmitted, reproduced or
>disclosed without the prior written consent of VeriSign Naming and
>Directory Services. If you have received this e-mail message in
>error, please notify the sender immediately by telephone or reply
>e-mail and destroy the original message without making a copy. Thank
you.
>
>
>
>From: Edward Lewis <[email-masked]>
>Date: Tue, 26 Jan 2010 16:24:45 -0500
>To: Andrew Sullivan <[email-masked]>
>Cc: EPP Provreg <[email-masked]>
>Subject: off-list was Re: [ietf-provreg] Revision of 4310
>
>I think this has veered off-topic for EPP. ;)
>
>At 15:37 -0500 1/26/10, Andrew Sullivan wrote:
> >On Tue, Jan 26, 2010 at 03:23:15PM -0500, Edward Lewis wrote:
> >>> I don't think I understand this one. Do you mean that there's no
> >>> RRSIG for that DNSKEY record?
> >>
> >> To clarify - Yes. In this instance, "in-active" would cover
having a DS
> >> appear, the DNSKEY appear, but no RRSIG created by the private
key. That
> >> would make the DS "in-active" in terms of building a chain of
trust.
> >
> >I like this idea better than just not putting the DNSKEY in the
DNSKEY
> >RRset. Is anyone doing their deployment this way?
> >
> >On the other hand, I suppose it doesn't really matter whether one
does
> >it this way or by just not including the DNSKEY on the child side.
In
> >either case, you have to use the old key until the TTL expires
> >(because without an RRSIG, the new key won't be useful either).
>
>If you are doing SEP=KSK and ZSK for all other keys, the best (IMO)
>thing to do is to add the SEP to the DNSKEY set and include the
>signature when you begin the process of changing. After appropriate
>timing, add the new DS and remove the old DS (or swap in one atomic
>transaction). After more appropriate time, revoke and later remove
>the old key.
>
>We plan to always have an emergency key on-line. So, add new key #3
>to the set of #1 and #2. Later swap #1 with #2. Eventually revoke
>#1. One cycle later, add new key #4, swap #2 with #3, retire #2.
>And so on. From add new key to remove there are three KSK
>signatures, two otherwise. There is always just one DS record (per
>key algorithm and DS hash).
>
>If one does not have a KSK/ZSK model, things will be different. I
>haven't thought through that though.
>
> >So why add the key to the DNSKEY RRset at all?
>
>So the validator can get the key. (If it weren't there, it's not
>going to be anywhere.)
a>Put the key at the parent...you're back to RFC 2065...;)
>--
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Edward Lewis
>NeuStar You can leave a voice message at
+1-571-434-5468
>
>As with IPv6, the problem with the deployment of frictionless surfaces
is
>that they're not getting traction.
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>List run by majordomo software. For (Un-)subscription and similar
details
>send "help" to
[email-masked]

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0RN6cX2011547 for ; Thu, 28 Jan 2010 00:06:38 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0RN6cbP004032 for ietf-provreg-outgoing; Thu, 28 Jan 2010 00:06:38 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [213.154.224.50]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0RN6bK2010654 for ; Thu, 28 Jan 2010 00:06:37 +0100 (MET)
Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id o0RN6YNW044027 for ; Thu, 28 Jan 2010 00:06:34 +0100 (CET) (envelope-from [email-masked])
Message-Id: <[email-masked]>
To: [email-masked]
Subject: [ietf-provreg] Recovered from a spam trap:
Date: Thu, 28 Jan 2010 00:06:34 +0100
From: Jaap Akkerhuis
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (bartok.nlnetlabs.nl [127.0.0.1]); Thu, 28 Jan 2010 00:06:34 +0100 (CET)
X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, MISSING_MID autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bartok.nlnetlabs.nl
Sender: [email-masked]
Precedence: bulk

Date: Tue, 26 Jan 2010 14:00:12 -0500
To: EPP Provreg
From: Olafur Gudmundsson
Subject: Re: [ietf-provreg] Revision of 4310
In-Reply-To: <[email-masked]>
References: <[email-masked]>

<[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4

What Andrew is saying below is real important, Key rollover without
parent prepublication is bound by the time it takes to update DNSKEY
RRset (at child)
plus passing the new records to the parent then wait
max(DS TTL, DNSKEY TTL).
With prepublication the onus only is on the child to publish the new
key.
The only participation by the parent is to delete the old DS record(s).

I think the knob that 4310 (and 4310-bis) have allowing children to
affect the
lifetime of signatures is a horrible idea, it probably was my idea in
the first place,
as that sets parents up for Signature regeneration DoS attacks.

It is much better to allow the child to affect the TTL on the DS record.
Reasons:
- In the old days we worried a lot about reuse of old/bad signatures
==> data packet forgery is harder than it was unless the
attacker is on-the-wire
a in which case it can do much more damage.
- If something bad happens it is more important to get the correct
data to the
majority of the world, then protect the small corner case that

may get spoofed with
old/bad data.
Signature Lifetime is about the window of vulnerability, TTL is about
recovery time.

From a parent perspective this is a choice between more frequent
resigning or
more DS queries, the frequency of DS queries is going to be more
affected by the
TTL of the DNSKEY set than the TTL on the DS set.

From a cryptographic point of view it is better to publish a DS for a
the
"hot-standby" key than publishing the key it self. In particular
when generating
a key that matches the fingerprint in the DS record(s), than breaking
the key itself.
The consequence of this is that the parent MUST not store the key or
at least not
make it available.

Each operator should set limits on the minimum and Maximum TTL on the
DS records they
allow and how many DS records each child can have.
It is not unrealistic to assume a child will request DS records for
2-4 different
keys and two or more DS digest algorithms for each.

Olafur

At 11:41 26/01/2010, Andrew Sullivan wrote:
>On Tue, Jan 26, 2010 at 11:13:44AM -0500, James Gould wrote:
>
> > What is the fundamental difference between a deactivate and a
remove? It
> > sounds like exactly the same from a DNS perspective and the TTL.
The
> > emergency key rollover use case that you present will be handled
> exactly the
> > same way if the client were to remove the DS from the Registry as
> opposed to
> > deactivating it and than later removing it. The deactivate from my
> > understanding will not remove it from the zone any faster then the
existing
> > remove. Please explain the difference.
>
>It's the other way around. Having a bad key around that you're not
>using does no harm. But _adding_ a key isn't instant either.
>
>If I validate your key, I look up the DS from the parent. That DS
>RRSet ends up cached in the cacheing resolver in front of me.
>
>If you now add a new DNSKEY in an emergency, and stop using your old
>key, then the DS that is cached is still the one I use when
>validating.
>
>Now, if you have a short TTL on your own DNSKEY record, your old
>DNSKEY will expire from my cache quickly.
>
>But AFAIK, no TLD allows clients to set the TTL on RRs in the parent
>zone.
>
>That means that the fastest you can roll your key is the maximum TTL
>on the DNSKEY or DS records. So if the parent has long TTLs, you're
>stuck with the TTL on the DS record.
>
>Now, if you can add a DS into the parent _before_ you add the DNSKEY
>to your zone, then the DNSKEY need not actually be in your zone when
>the DS is available in the parent.
>
>Now, some zone operators have said they want to validate that the
>DNSKEY is available in the child before publishing the corresponding
>DS in the parent. But if EPP were to offer a mechanism whereby you
>could say, "I want you to have this DS record in the DS RRSet, but
>_don't_ expect a DNSKEY in the child yet," then the parent would know
>not to perform that check when adding the DS record. (By policy, I
>suppose, the "activation" bit could cause the check against the
>child.)
>
>So that's the use case. I don't know how important this is to
>operators, however.
>
>A
>
>--
>Andrew Sullivan
>[email-masked]
>Shinkuro, Inc.
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>List run by majordomo software. For (Un-)subscription and similar
details
>send "help" to [email-masked]

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0RJleX1026899 for ; Wed, 27 Jan 2010 20:47:41 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0RJlea1029607 for ietf-provreg-outgoing; Wed, 27 Jan 2010 20:47:40 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0RJldZh017101 for ; Wed, 27 Jan 2010 20:47:40 +0100 (MET)
Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o0RJgggN026619; Wed, 27 Jan 2010 14:42:42 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 14:47:38 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Wed, 27 Jan 2010 19:47:30 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Wed, 27 Jan 2010 14:47:27 -0500
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310
From: James Gould
To: Eduardo Duarte , EPP Provreg
CC: WG-DNS
Message-ID:
Thread-Topic: off-list was Re: [ietf-provreg] Revision of 4310
Thread-Index: AcqfRO/hQaMBlo3CSg2ZvHh/2SINjAARJ3OP
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3347448448_8526390"
X-OriginalArrivalTime: 27 Jan 2010 19:47:38.0936 (UTC) FILETIME=[94CE3B80:01CA9F89]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3347448448_8526390
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Eduardo,

I=B9m getting a little bit confused with the request. Can you describe the
use case step-by-step on the usage of the active flag? The current RFC and
draft assumes that the server publishes the DS as soon as possible after
receiving it from the client, where it would be considered active (with som=
e
delay to propagate) from a provisioning perspective. Is there additional
server-side logic that I=B9m not aware of?

Thanks,
=20

--=20

JG=20

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

=20
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior writte=
n
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

From: Eduardo Duarte
Date: Wed, 27 Jan 2010 06:08:55 -0500
To: EPP Provreg
Cc: WG-DNS
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310

Hello,

First of all sorry not to have contributed yesterday but I had no time
to read all the emails... :(

Well when I was thinking of this flag I was thinking that it would mean
if the key is publish in the parent zone and I was not thinking to much
on the create/update commands but more on the info... :P
On our work model a domain can have more then one key associated with
domain and they can be in a active or inactive state where active means
publish or unpublished in the parent zone.
When adding a key I dont see the problem of it becoming automatically
publish in the parent zone and the old key to be unpublished as soon at
is expire or remove. But lets say the owner of the domain keep just
adding keys! After a while if in the info command you send back all the
keys associated with the domain you will not have a good hint of wich
ones are publish... Or if a domain change onwer also will be a bit
difficult to understand witch of the keys are publish without consulting
directly the DNS server...
Also you can say for me to send on the info command just the active key,
but then I will be not sending all the associated data with the domain...
So to cover this ground of sending all the data back and the state of
the DS I proposed the active/inactive flag, that I supposed that is
backwards compatible.

I know that some other registries use this model for managing the client
keys and that was why I asked if this was already been discussed...

Best regards,

Eduardo Duarte

Jaap Akkerhuis wrote, On 26-01-2010 22:53:
> Was meant to be off-list. Because I'm diving into the details of
> DNSSEC itself. (And not saying anything new.)
>
> To come back to EPP, I think we need to revisit "active/inactive" an=
d
> the implications it has to a registry.
>
> Well, since Eduardo Duarte from the .PT registry proposed it, maybe
> he should starts to explain what problems he wants to solve with this.
>
> jaap
> -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
=3D-
> List run by majordomo software. For (Un-)subscription and similar detail=
s
> send "help" to [email-masked]
>
> =20
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

--B_3347448448_8526390
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: off-list was Re: [ietf-provreg] Revision of 4310

Eduardo,

I’m getting a little bit confused with the request.  Can you des=
cribe the use case step-by-step on the usage of the active flag?  The c=
urrent RFC and draft assumes that the server publishes the DS as soon as pos=
sible after receiving it from the client, where it would be considered activ=
e (with some delay to propagate) from a provisioning perspective.  Is t=
here additional server-side logic that I’m not aware of?

Thanks,

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

From: Eduardo Duarte <[email-masked]>

Date: Wed, 27 Jan 2010 06:08:55 -0500

To: EPP Provreg <ietf-provreg@caf=
ax.se>

Cc: WG-DNS <[email-masked]>

Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310

Hello,

First of all sorry not to have contributed yesterday but I had no time

to read all the emails... :(

Well when I was thinking of this flag I was thinking that it would mean

if the key is publish in the parent zone and I was not thinking to much

on the create/update commands but more on the info... :P

On our work model a domain can have more then one key associated with

domain and they can be in a active or inactive state where active means

publish or unpublished  in the parent zone.

When adding a key I dont see the problem of it becoming automatically

publish in the parent zone and the old key to be unpublished as soon at

is expire or remove.  But lets say the owner of the domain keep just
adding keys! After a while if in the info command you send back all the

keys associated with the domain you will not have a good hint of wich

ones are publish... Or if a domain change onwer also will be a bit

difficult to understand witch of the keys are publish without consulting
directly the DNS server...

Also you can say for me to send on the info command just the active key,
but then I will be not sending all the associated data with the domain...
So to cover this ground of sending all the data back and the state of

the DS I proposed the active/inactive flag, that I supposed that is

backwards compatible.

I know that some other registries use this model for managing the client
keys and that was why I asked if this was already been discussed...

Best regards,

Eduardo Duarte

Jaap Akkerhuis wrote, On 26-01-2010 22:53:

>      Was meant to be off-list.  Because =
I'm diving into the details of

>      DNSSEC itself.  (And not saying any=
thing new.)

>      To come back to EPP, I think we need to =
revisit "active/inactive" and

>      the implications it has to a registry.
>

> Well, since Eduardo Duarte from the .PT registry proposed it, maybe
> he should starts to explain what problems he wants to solve with this.=

>       jaap

> -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D-=3D-

> List run by majordomo software.  For (Un-)subscription and simila=
r details

> send "help" to ietf-=
[email-masked]

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=

List run by majordomo software.  For (Un-)subscription and similar det=
ails

send "help" to ietf-provr=
[email-masked]

--B_3347448448_8526390--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0RHfLD5028987 for ; Wed, 27 Jan 2010 18:41:21 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0RHfLxN018003 for ietf-provreg-outgoing; Wed, 27 Jan 2010 18:41:21 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0RHfKKc020916 for ; Wed, 27 Jan 2010 18:41:20 +0100 (MET)
Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o0RHaMt4021482; Wed, 27 Jan 2010 12:36:22 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 12:41:18 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Wed, 27 Jan 2010 17:41:18 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Wed, 27 Jan 2010 12:41:14 -0500
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis
From: James Gould
To: Klaus Malorny , Ulrich Wisser
CC: EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] XML Schema versioning in 4310bis
Thread-Index: AcqfZEJqZsE0iwo8Q/WMpD8TYHXyhwAE6lql
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3347440875_8062196"
X-OriginalArrivalTime: 27 Jan 2010 17:41:18.0664 (UTC) FILETIME=[EE9C8480:01CA9F77]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3347440875_8062196
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Klaus,

Thanks for responding to this topic. Below is my feedback to the feedback.

>> when discussing 4310bis we did focus very much on backward
>> compatibility. Which isn't necessarily a bad thing. But by making the
>> old style rem command optional we break exactly the one thing we were
>> aiming for.
>=20
> Hmm. I am quite sure that the current version of 4310bis allows the proce=
ssing
> of all valid 4310 requests.

There was much discussion related to supporting the old style secDNS:rem
with secDNS:keyTag on the list. The following text in the draft directly
addresses the issue according to a compromise from this list:

> element MUST contain a key tag value as described in sect=
ion
> 5.1.1 of RFC 4034 [6]. Removing all DS information can remove the ability=
of
> the parent to secure the delegation to the child zone. The server SHOULD
> return an EPP error result code of 2305 if more than one DS record matche=
s the
> . should be used by the client if there is=
more
> than one DS record with the same .

I would like to continue with what was compromised in addressing the issue
of using the non-unique secDNS:keyTag. Is this not an acceptable solution?

>>=20
>> After some discussions with registrars and my colleagues, we came to the
>> conclusion that a new URI would be a better solution. The server could
>> support both versions of the protocol (and therefor not break old
>> clients) and clients would know which interface to use.
>=20
> Agreed.

Ok, it looks like the feedback is to use a different URI. I can go with
this. If anyone disagrees, please respond to the list or to me privately.
I can go with urn:ietf:params:xml:ns:secDNS-1.1 as proposed by Bernie.

>>=20
>> If we change the URI, I propose to drop backward compatibility and get
>> rid of the old style rem.
>=20
> This is a valid option, but it throws us back nearly to the beginning of =
the
> discussion. But if it's worth...

I don=B9t believe that there is a compelling need to open up pandora=B9s box fo=
r
this item. The goal is to address the main issues with RFC 4310, which the
draft I believe does. I=B9ll drop the URI backward compatibility goal (or I
guess sub-goal). =20

--=20

JG=20

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

=20
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior writte=
n
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

From: Klaus Malorny
Date: Wed, 27 Jan 2010 09:53:18 -0500
To: Ulrich Wisser
Cc: EPP Provreg
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis

On 27/01/10 09:53, Ulrich Wisser wrote:
> Hi,
Hi,

> when discussing 4310bis we did focus very much on backward
> compatibility. Which isn't necessarily a bad thing. But by making the
> old style rem command optional we break exactly the one thing we were
> aiming for.

Hmm. I am quite sure that the current version of 4310bis allows the
processing
of all valid 4310 requests.

>
> After some discussions with registrars and my colleagues, we came to the
> conclusion that a new URI would be a better solution. The server could
> support both versions of the protocol (and therefor not break old
> clients) and clients would know which interface to use.

Agreed.

>
> If we change the URI, I propose to drop backward compatibility and get
> rid of the old style rem.

This is a valid option, but it throws us back nearly to the beginning of th=
e
discussion. But if it's worth...

> /Ulrich

Regards,

Klaus
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

--B_3347440875_8062196
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] XML Schema versioning in 4310bis

Klaus,

Thanks for responding to this topic.  Below is my feedback to the feed=
back.

>> when discussing 4310bis we did focus very much on backward

>> compatibility. Which isn't necessarily a bad thing. But by making =
the

>> old style rem command optional we break exactly the one thing we w=
ere

>> aiming for.

> Hmm. I am quite sure that the current version of 4310bis allows the pr=
ocessing

> of all valid 4310 requests.

There was much discussion related to supporting the old style secDNS:rem wi=
th secDNS:keyTag on the list.  The following text in the draft directly=
addresses the issue according to a compromise from this list:

<secDNS:keyTag> element MUST contain=
a key tag value as described in section 5.1.1 of RFC 4034 [6]. Removing all DS information can remove the ability o=
f the parent to secure the delegation to the child zone. The server SHOULD r=
eturn an EPP error result code of 2305 if more than one DS record matches th=
e <secDNS:keyTag>. <secDNS:dsData> should be used by the client =
if there is more than one DS record with the same <secDNS:keyTag>.

=

I would like to continue with what was compromised in addressing the issue =
of using the non-unique secDNS:keyTag.  Is this not an acceptable solut=
ion?

>> After some discussions with registrars and my colleagues, we came =
to the

>> conclusion that a new URI would be a better solution. The server c=
ould

>> support both versions of the protocol (and therefor not break old<=
BR>
>> clients) and clients would know which interface to use.

> Agreed.

Ok, it looks like the feedback is to use a different URI.  I can go wi=
th this.  If anyone disagrees, please respond to the list or to me priv=
ately.  I can go with urn:ietf:params:xml:ns:secDNS-1.1 as proposed by =
Bernie.

>> If we change the URI, I propose to drop backward compatibility and=
get

>> rid of the old style rem.

> This is a valid option, but it throws us back nearly to the beginning =
of the

> discussion. But if it's worth...

I don’t believe that there is a compelling need to open up pandora=
217;s box for this item.  The goal is to address the main issues with R=
FC 4310, which the draft I believe does.  I’ll drop the URI backw=
ard compatibility goal (or I guess sub-goal).

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

From: Klaus Malorny <[email-masked]>

Date: Wed, 27 Jan 2010 09:53:18 -0500

To: Ulrich Wisser <[email-masked]=
e>

Cc: EPP Provreg <ietf-provreg@caf=
ax.se>

Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis

On 27/01/10 09:53, Ulrich Wisser wrote:

> Hi,

Hi,

> when discussing 4310bis we did focus very much on backward

> compatibility. Which isn't necessarily a bad thing. But by making the<=
BR>
> old style rem command optional we break exactly the one thing we were<=
BR>
> aiming for.

Hmm. I am quite sure that the current version of 4310bis allows the process=
ing

of all valid 4310 requests.

> After some discussions with registrars and my colleagues, we came to t=
he

> conclusion that a new URI would be a better solution. The server could=

> support both versions of the protocol (and therefor not break old

> clients) and clients would know which interface to use.

Agreed.

> If we change the URI, I propose to drop backward compatibility and get=

> rid of the old style rem.

This is a valid option, but it throws us back nearly to the beginning of th=
e

discussion. But if it's worth...

> /Ulrich

Regards,

Klaus

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=

List run by majordomo software.  For (Un-)subscription and similar det=
ails

send "help" to ietf-provr=
[email-masked]

--B_3347440875_8062196--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0RGhcTV027421 for ; Wed, 27 Jan 2010 17:43:38 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0RGhc1P018236 for ietf-provreg-outgoing; Wed, 27 Jan 2010 17:43:38 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0RGhako023710 for ; Wed, 27 Jan 2010 17:43:37 +0100 (MET)
Received: from [10.31.201.16] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0RGhVdQ088378; Wed, 27 Jan 2010 11:43:31 -0500 (EST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Wed, 27 Jan 2010 11:43:21 -0500
To: Eduardo Duarte
From: Edward Lewis
Subject: on-list, was Re: off-list was Re: [ietf-provreg] Revision of 4310
Cc: [email-masked], "'WG-DNS'"
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4
Sender: [email-masked]
Precedence: bulk

(Altered the subj line as we are back on topic. ;))

At 11:08 +0000 1/27/10, Eduardo Duarte wrote:

>Well when I was thinking of this flag I was thinking that it would mean if the
>key is publish in the parent zone and I was not thinking to much on
>the create/
>update commands but more on the info... :P

This was as I suspected. (Read: I'm about to jump on a soap box.)

>On our work model a domain can have more then one key associated with domain
>and they can be in a active or inactive state where active means publish or
>unpublished in the parent zone.

I'm going to argue about registry practice here. I don't mean to
criticize, but I feel compelled to express my opinion.

I think it is a good idea for a registry to ONLY collect information
that is supposed to be in or support the public DNS or WhoIs.

I need to really explain this blanket statement.

"supposed to be in" includes data about suspended/blocked/reserved
domains (those not actively delegated but still being associated to
an entity). So a domain name that that has elapsed is okay - it is
"supposed to be in" except that something else went wrong - and
retaining it's last known NS set is a good idea.

"supports" refers to data that is related to functions like billing
or contacts that are used to make sure the registration is "fresh (as
in active, live, the guys out there are still runnning a server,
etc.)."

"public" besides the usual stuff we think is public, I mean to
included here (quasi-)confidential information that is disclosed to
authorized third parties such as law enforcement. I include this
because not all registries have an Internet accessible, publicly
viewable WhoIs but do have the requirement to identify registrants to
authorities (legal or otherwise).

More to the point, I think it is very unwise for a registry to act as
a data escrow facility for its registrants (unless you want to expand
your mission or business to include that). More precisely what I'm
trying to say is that escrow is not part of provisioning. IMO -
registration should be about the "here and now" the relationship of
entities to objects and vice versa.

Because of that opinion, I wouldn't think to add such a flag - a flag
of "show this, don't show that."

(Again, please don't be offended, this is just a feature I feel adds
complexity and burden to the registration interface and I want to be
clear why I say the rest of the things.)

>When adding a key I dont see the problem of it becoming automatically publish
>in the parent zone and the old key to be unpublished as soon at is expire or
>remove.

The true authority of a domain registered in your domain is the
registrant. Outside of you "granting" them the title to the name,
they call the shots. That is, the registry should do nothing
"automatic" to the domain. (Yes, refreshing DNSSEC signatures is the
parent's job - but that's a statement about the parent's DNS data,
not the child's.) All actions regarding the registrant's domain
should come from the registrant (or their agent, etc., /registrar).

And remember - keys don't expire in DNS, just signatures.

So I don't think you should need this flag. Or anyone should need
this flag. (Not that adding it is a bad idea, and it can be done. I
am cautioning against ever using it.)

>But lets say the owner of the domain keep just adding keys!

And then there is that. If you become an escrow agent, you enter
another level of, well, hell. You have to worry about registrants
DOS'ing you, eating up your disk and memory. What's your data
retention policy, privacy policy, etc? How do you back things up?
How long do you store stuff? When is data deleted? This is more of
a repeat of my "don't escrow while provisioning" message.

>I know that some other registries use this model for managing the client
>keys and that was why I asked if this was already been discussed...

We do not want to touch any keys of our registrants, much less manage
them. That is why we only will take the DS record - the hash of the
key. We are very clear not to even see private keys, not public
keys. That is all the registrant's misery. We just (plan to)
register the hashes of the keys as the registrant submit them.

The registrants are completely in control of their key management.
If they do frequent key changes, so be it. If they never change the
key, so be it. We just report what they tell us to report. Just
like the NS records - we don't mess with them, we don't mess with the
DS records.

(I don't mean to go commercial but to be clear I am writing this
thinking solely as part of the registry team, not the managed DNS
services team.)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0RErOO6010552 for ; Wed, 27 Jan 2010 15:53:24 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0RErOkf009206 for ietf-provreg-outgoing; Wed, 27 Jan 2010 15:53:24 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from kmx10a.knipp.de (clust3a-eth0-0.bbone.knipp.de [195.253.6.83]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0RErO2a025005 for ; Wed, 27 Jan 2010 15:53:24 +0100 (MET)
Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id C284FF5; Wed, 27 Jan 2010 15:53:23 +0100 (MEZ)
X-Knipp-VirusScanned: Yes
Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id taQxCyHxaG+r; Wed, 27 Jan 2010 15:53:18 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 3496EF1; Wed, 27 Jan 2010 15:53:18 +0100 (MEZ)
Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id o0RErHiW009837; Wed, 27 Jan 2010 15:53:17 +0100 (MEZ)
Message-ID: <[email-masked]>
Date: Wed, 27 Jan 2010 15:53:18 +0100
From: Klaus Malorny
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.7) Gecko/20100124 Shredder/3.0.2pre
MIME-Version: 1.0
To: Ulrich Wisser
CC: EPP Provreg
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

On 27/01/10 09:53, Ulrich Wisser wrote:
> Hi,
Hi,

> when discussing 4310bis we did focus very much on backward
> compatibility. Which isn't necessarily a bad thing. But by making the
> old style rem command optional we break exactly the one thing we were
> aiming for.

Hmm. I am quite sure that the current version of 4310bis allows the processing
of all valid 4310 requests.

>
> After some discussions with registrars and my colleagues, we came to the
> conclusion that a new URI would be a better solution. The server could
> support both versions of the protocol (and therefor not break old
> clients) and clients would know which interface to use.

Agreed.

>
> If we change the URI, I propose to drop backward compatibility and get
> rid of the old style rem.

This is a valid option, but it throws us back nearly to the beginning of the
discussion. But if it's worth...

> /Ulrich

Regards,

Klaus
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0REgggl002599 for ; Wed, 27 Jan 2010 15:42:42 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0REgg8F002804 for ietf-provreg-outgoing; Wed, 27 Jan 2010 15:42:42 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from kmx10a.knipp.de (clust3a-eth0-0.bbone.knipp.de [195.253.6.83]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0REgfYJ011428 for ; Wed, 27 Jan 2010 15:42:41 +0100 (MET)
Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 3D32AF1; Wed, 27 Jan 2010 15:42:41 +0100 (MEZ)
X-Knipp-VirusScanned: Yes
Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id 1NdR52vU+rMx; Wed, 27 Jan 2010 15:42:36 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 990BDF0; Wed, 27 Jan 2010 15:42:36 +0100 (MEZ)
Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id o0REgZdC007789; Wed, 27 Jan 2010 15:42:36 +0100 (MEZ)
Message-ID: <[email-masked]>
Date: Wed, 27 Jan 2010 15:42:35 +0100
From: Klaus Malorny
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.7) Gecko/20100124 Shredder/3.0.2pre
MIME-Version: 1.0
To: James Gould
CC: Bernie Hoeneisen , EPP Provreg
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis
References:
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

On 25/01/10 21:05, James Gould wrote:
> Bernie,
>
> I had multiple private messages associated with this, but on the list
> the only message that directly references is from me on December 8th:
>
> http://www.cafax.se/ietf-provreg/maillist/2009-12/msg00000.html
>
> [...]

Hi all,

I am currently trying to catch up (once again), and just want to point out in
this context to my mail from Dec 18th, 2009, and James' answer. Unfortunately, I
can't find James' e-mail on cafax.se, so I am quoting the respective part
instead of providing a link:

>> section 5/section 7:
>>
>> I discovered that the schema uses the same XML namespace as RFC 4310. I am not
>> familiar with the policies of XML namespaces at the IETF, but I wonder whether
>> there is a need to use a different XML namespace, since we considerably
>> changed
>> the schema (despite the fact that it should be backward compatible).
>
> Not according to the Area Director Alexey Melnikov, who replied with the following on the URI:
>
> I think just keeping namespace URIs would be fine. Your document would
> need to list all changes (including additions) since RFC 4310, so that
> would help in verifying that schema changes are backward compatible.
> If your changes end up not being backward compatible, then new namespace
> URIs can be allocated.
>
> Keeping the schema backward compatible is one of the key goals, where changing the URI itself would not make it backward compatible.

I have to admit that I missed the point regarding the greeting message. While I
think that EPP cannot live up to the expectations of an "out-of-the-box"
deployment and automatic negotiations of capabilities, as the policy differences
between the various registries are simply too large and beyond the scope of EPP,
I think it is better to change the URI just to enable the client software to
detect protocol changes and to raise an alarm if need be.

Regards,

Klaus
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0RB8xWI020641 for ; Wed, 27 Jan 2010 12:08:59 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0RB8xRs014559 for ietf-provreg-outgoing; Wed, 27 Jan 2010 12:08:59 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from app02.fccn.pt (app02.fccn.pt [193.137.198.37]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0RB8wEs021227 for ; Wed, 27 Jan 2010 12:08:59 +0100 (MET)
Received: from mx.anubis.local (ste [10.1.2.2]) by outbound.anubis.local (Postfix) with ESMTP id B3D74C2F14 for ; Wed, 27 Jan 2010 11:08:58 +0000 (WET)
Received: from [193.136.44.92] (gaea.corp.fccn.pt [193.136.44.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: [email-masked]) by mx.anubis.local (Postfix) with ESMTP id AA907C2F11; Wed, 27 Jan 2010 11:08:58 +0000 (WET)
Message-ID: <[email-masked]>
Date: Wed, 27 Jan 2010 11:08:55 +0000
From: Eduardo Duarte
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: [email-masked]
CC: "'WG-DNS'"
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

Hello,

First of all sorry not to have contributed yesterday but I had no time
to read all the emails... :(

Well when I was thinking of this flag I was thinking that it would mean
if the key is publish in the parent zone and I was not thinking to much
on the create/update commands but more on the info... :P
On our work model a domain can have more then one key associated with
domain and they can be in a active or inactive state where active means
publish or unpublished in the parent zone.
When adding a key I dont see the problem of it becoming automatically
publish in the parent zone and the old key to be unpublished as soon at
is expire or remove. But lets say the owner of the domain keep just
adding keys! After a while if in the info command you send back all the
keys associated with the domain you will not have a good hint of wich
ones are publish... Or if a domain change onwer also will be a bit
difficult to understand witch of the keys are publish without consulting
directly the DNS server...
Also you can say for me to send on the info command just the active key,
but then I will be not sending all the associated data with the domain...
So to cover this ground of sending all the data back and the state of
the DS I proposed the active/inactive flag, that I supposed that is
backwards compatible.

I know that some other registries use this model for managing the client
keys and that was why I asked if this was already been discussed...

Best regards,

Eduardo Duarte

Jaap Akkerhuis wrote, On 26-01-2010 22:53:
> Was meant to be off-list. Because I'm diving into the details of
> DNSSEC itself. (And not saying anything new.)
>
> To come back to EPP, I think we need to revisit "active/inactive" and
> the implications it has to a registry.
>
> Well, since Eduardo Duarte from the .PT registry proposed it, maybe
> he should starts to explain what problems he wants to solve with this.
>
> jaap
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> List run by majordomo software. For (Un-)subscription and similar details
> send "help" to [email-masked]
>
>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0R8xI5R000646 for ; Wed, 27 Jan 2010 09:59:18 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0R8xIg4013841 for ietf-provreg-outgoing; Wed, 27 Jan 2010 09:59:18 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from lvps87-230-32-221.dedicated.hosteurope.de (mail.publisher.de [87.230.32.221]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0R8xHGY002727 for ; Wed, 27 Jan 2010 09:59:17 +0100 (MET)
Received: (qmail 15675 invoked from network); 27 Jan 2010 08:59:16 +0000
Received: from gw.iis.se (HELO ulrich-wissers-macbook-pro.local) (212.247.14.38) by mail.publisher.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Jan 2010 08:59:16 +0000
Message-ID: <[email-masked]>
Date: Wed, 27 Jan 2010 09:59:13 +0100
From: Ulrich Wisser
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: [email-masked]
Subject: Re: [ietf-provreg] a question for the list
References:
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

Hi,

at .SE we would be interested in a new wg for epp. There are definitely
blips to solve and extensions to standardize.

We did our own extension for sending messages to registrars in case the
registry updates any objects. I've seen several registries having such
an extension. So it seems there is aneed for that.

/Ulrich

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0R8rNcN028095 for ; Wed, 27 Jan 2010 09:53:23 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0R8rNS7029102 for ietf-provreg-outgoing; Wed, 27 Jan 2010 09:53:23 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from lvps87-230-32-221.dedicated.hosteurope.de (mail.publisher.de [87.230.32.221]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0R8rN5j010548 for ; Wed, 27 Jan 2010 09:53:23 +0100 (MET)
Received: (qmail 13713 invoked from network); 27 Jan 2010 08:53:22 +0000
Received: from gw.iis.se (HELO ulrich-wissers-macbook-pro.local) (212.247.14.38) by mail.publisher.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Jan 2010 08:53:22 +0000
Message-ID: <[email-masked]>
Date: Wed, 27 Jan 2010 09:53:18 +0100
From: Ulrich Wisser
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: EPP Provreg
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis
References:
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

Hi,

when discussing 4310bis we did focus very much on backward
compatibility. Which isn't necessarily a bad thing. But by making the
old style rem command optional we break exactly the one thing we were
aiming for.

After some discussions with registrars and my colleagues, we came to the
conclusion that a new URI would be a better solution. The server could
support both versions of the protocol (and therefor not break old
clients) and clients would know which interface to use.

If we change the URI, I propose to drop backward compatibility and get
rid of the old style rem.

/Ulrich
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QMriIf023194 for ; Tue, 26 Jan 2010 23:53:44 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QMri1l015163 for ietf-provreg-outgoing; Tue, 26 Jan 2010 23:53:44 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [213.154.224.50]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QMrhfR026003 for ; Tue, 26 Jan 2010 23:53:43 +0100 (MET)
Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id o0QMresf016269 for ; Tue, 26 Jan 2010 23:53:40 +0100 (CET) (envelope-from [email-masked])
Message-Id: <[email-masked]>
To: [email-masked]
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310
In-reply-to:
References: <[email-masked]> <[email-masked]> <[email-masked]>
Comments: In-reply-to Edward Lewis message dated "Tue, 26 Jan 2010 17:00:43 -0500."
Date: Tue, 26 Jan 2010 23:53:40 +0100
From: Jaap Akkerhuis
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (bartok.nlnetlabs.nl [127.0.0.1]); Tue, 26 Jan 2010 23:53:40 +0100 (CET)
X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, MISSING_MID autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bartok.nlnetlabs.nl
Sender: [email-masked]
Precedence: bulk

Was meant to be off-list. Because I'm diving into the details of
DNSSEC itself. (And not saying anything new.)

To come back to EPP, I think we need to revisit "active/inactive" and
the implications it has to a registry.

Well, since Eduardo Duarte from the .PT registry proposed it, maybe
he should starts to explain what problems he wants to solve with this.

jaap
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QMXj8Q007220 for ; Tue, 26 Jan 2010 23:33:45 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QMXjSu007776 for ietf-provreg-outgoing; Tue, 26 Jan 2010 23:33:45 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QMXiqF014711 for ; Tue, 26 Jan 2010 23:33:44 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id BDA1F1ECB534 for ; Tue, 26 Jan 2010 22:33:41 +0000 (UTC)
Date: Tue, 26 Jan 2010 17:33:39 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References:
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Tue, Jan 26, 2010 at 05:22:06PM -0500, James Gould wrote:
> Yes, we kind of got into the weeds of DNSSEC specifics.

In my view, if we're making software to support DNSSEC, we need to
understand how it's going to be used. For all I (or anyone else,
AFAICS) knows, this proposed feature is a bad idea, because nobody
will use it. We need to understand whether there's a compelling use
case for communicating the status of a DNSKEY or it RRSIG across the
zone cut. If not, then the feature is a bad idea & we should argue
against it. If it is likely to be used, that's a different story.

> I believe the request was to add a flag to the draft to allow the client to
> indicate to the server that the DNSKEY is active in the child zone.

That's one idea of three. See Ed's initial message. What I'm trying
to see is whether, of the two actually useful ideas we've discussed,
whether any of them are really useful and whether one is to be
preferred to the other. For sure, the suggestions that "inactive"
means "don't publish DS" is silly, for the reasons you already
suggested.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QMMEfB004146 for ; Tue, 26 Jan 2010 23:22:14 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QMMEUD003662 for ietf-provreg-outgoing; Tue, 26 Jan 2010 23:22:14 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QMMDiI004082 for ; Tue, 26 Jan 2010 23:22:13 +0100 (MET)
Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o0QMHI0x003406; Tue, 26 Jan 2010 17:17:18 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 17:22:13 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Tue, 26 Jan 2010 22:22:12 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Tue, 26 Jan 2010 17:22:06 -0500
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310
From: James Gould
To: Edward Lewis , Andrew Sullivan
CC: EPP Provreg
Message-ID:
Thread-Topic: off-list was Re: [ietf-provreg] Revision of 4310
Thread-Index: Acqe0RfUnuhrB1jNRBCLeAa+LTW3VQABOYrc
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3347371330_7086541"
X-OriginalArrivalTime: 26 Jan 2010 22:22:13.0037 (UTC) FILETIME=[022FFDD0:01CA9ED6]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3347371330_7086541
Content-type: text/plain;
charset="US-ASCII"
Content-transfer-encoding: 7bit

Yes, we kind of got into the weeds of DNSSEC specifics.

I believe the request was to add a flag to the draft to allow the client to
indicate to the server that the DNSKEY is active in the child zone. The
definition of this needs to be clearly defined, but I would assume that it
is that the DNSKEY is published in the child zone DNSKEY RRset. This is an
optional attribute that the server can use for additional validation based
on server policy. If the attribute is supported by the server it should be
returned in the secDNS:infData of the domain info response. This optional
attribute would be added to the secDNS:keyData and the secDNS:dsData
elements. I recommend calling this attribute childKeyActive. I also
recommend that there are no changes to the secDNS interface to optimize
changing this attribute in a domain update.

Do registries in general need this and do clients want to add this
complexity to the draft?

--

JG

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior written
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

From: Edward Lewis
Date: Tue, 26 Jan 2010 16:24:45 -0500
To: Andrew Sullivan
Cc: EPP Provreg
Subject: off-list was Re: [ietf-provreg] Revision of 4310

I think this has veered off-topic for EPP. ;)

At 15:37 -0500 1/26/10, Andrew Sullivan wrote:
>On Tue, Jan 26, 2010 at 03:23:15PM -0500, Edward Lewis wrote:
>>> I don't think I understand this one. Do you mean that there's no
>>> RRSIG for that DNSKEY record?
>>
>> To clarify - Yes. In this instance, "in-active" would cover having a DS
>> appear, the DNSKEY appear, but no RRSIG created by the private key. That
>> would make the DS "in-active" in terms of building a chain of trust.
>
>I like this idea better than just not putting the DNSKEY in the DNSKEY
>RRset. Is anyone doing their deployment this way?
>
>On the other hand, I suppose it doesn't really matter whether one does
>it this way or by just not including the DNSKEY on the child side. In
>either case, you have to use the old key until the TTL expires
>(because without an RRSIG, the new key won't be useful either).

If you are doing SEP=KSK and ZSK for all other keys, the best (IMO)
thing to do is to add the SEP to the DNSKEY set and include the
signature when you begin the process of changing. After appropriate
timing, add the new DS and remove the old DS (or swap in one atomic
transaction). After more appropriate time, revoke and later remove
the old key.

We plan to always have an emergency key on-line. So, add new key #3
to the set of #1 and #2. Later swap #1 with #2. Eventually revoke
#1. One cycle later, add new key #4, swap #2 with #3, retire #2.
And so on. From add new key to remove there are three KSK
signatures, two otherwise. There is always just one DS record (per
key algorithm and DS hash).

If one does not have a KSK/ZSK model, things will be different. I
haven't thought through that though.

>So why add the key to the DNSKEY RRset at all?

So the validator can get the key. (If it weren't there, it's not
going to be anywhere.)

Put the key at the parent...you're back to RFC 2065...;)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

--B_3347371330_7086541
Content-type: text/html;
charset="US-ASCII"
Content-transfer-encoding: quoted-printable

Re: off-list was Re: [ietf-provreg] Revision of 4310

Yes, we kind of got into the weeds of DNSSEC specifics.

I believe the request was to add a flag to the draft to allow the client to=
indicate to the server that the DNSKEY is active in the child zone.  T=
he definition of this needs to be clearly defined, but I would assume that i=
t is that the DNSKEY is published in the child zone DNSKEY RRset.  This=
is an optional attribute that the server can use for additional validation =
based on server policy.  If the attribute is supported by the server it=
should be returned in the secDNS:infData of the domain info response.  =
;This optional attribute would be added to the secDNS:keyData and the secDNS=
:dsData elements.  I recommend calling this attribute childKeyActive. &=
nbsp;I also recommend that there are no changes to the secDNS interface to o=
ptimize changing this attribute in a domain update.

Do registries in general need this and do clients want to add this complexi=
ty to the draft?

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

From: Edward Lewis <[email-masked]>

Date: Tue, 26 Jan 2010 16:24:45 -0500

To: Andrew Sullivan <[email-masked]<=
/a>>

Cc: EPP Provreg <ietf-provreg@caf=
ax.se>

Subject: off-list was Re: [ietf-provreg] Revision of 4310

I think this has veered off-topic for EPP. ;)

At 15:37 -0500 1/26/10, Andrew Sullivan wrote:

>On Tue, Jan 26, 2010 at 03:23:15PM -0500, Edward Lewis wrote:

>>>  I don't think I understand this one.  Do you mean t=
hat there's no

>>>  RRSIG for that DNSKEY record?

>>  To clarify - Yes.  In this instance, "in-active&qu=
ot; would cover having a DS

>>  appear, the DNSKEY appear, but no RRSIG created by the priva=
te key.  That

>>  would make the DS "in-active" in terms of building=
a chain of trust.

>I like this idea better than just not putting the DNSKEY in the DNSKEY<=
BR>
>RRset.  Is anyone doing their deployment this way?

>On the other hand, I suppose it doesn't really matter whether one does<=
BR>
>it this way or by just not including the DNSKEY on the child side. &nbs=
p;In

>either case, you have to use the old key until the TTL expires

>(because without an RRSIG, the new key won't be useful either).

If you are doing SEP=3DKSK and ZSK for all other keys, the best (IMO)

thing to do is to add the SEP to the DNSKEY set and include the

signature when you begin the process of changing.  After appropriate
timing, add the new DS and remove the old DS (or swap in one atomic

transaction).  After more appropriate time, revoke and later remove
the old key.

We plan to always have an emergency key on-line.  So, add new key #3
to the set of #1 and #2.  Later swap #1 with #2.  Eventually revo=
ke

#1.  One cycle later, add new key #4, swap #2 with #3, retire #2.

And so on.  From add new key to remove there are three KSK

signatures, two otherwise.  There is always just one DS record (per
key algorithm and DS hash).

If one does not have a KSK/ZSK model, things will be different.  I

haven't thought through that though.

>So why add the key to the DNSKEY RRset at all?

So the validator can get the key.  (If it weren't there, it's not

going to be anywhere.)

Put the key at the parent...you're back to RFC 2065...;)

--

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=

Edward Lewis

NeuStar            &=
nbsp;       You can leave a voice message=
at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=

List run by majordomo software.  For (Un-)subscription and similar det=
ails

send "help" to ietf-provr=
[email-masked]

--B_3347371330_7086541--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QMCAmL004000 for ; Tue, 26 Jan 2010 23:12:10 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QMCAx6010766 for ietf-provreg-outgoing; Tue, 26 Jan 2010 23:12:10 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QMCA5a021117 for ; Tue, 26 Jan 2010 23:12:10 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3D96E1ECB528 for ; Tue, 26 Jan 2010 22:12:07 +0000 (UTC)
Date: Tue, 26 Jan 2010 17:12:06 -0500
From: Andrew Sullivan
To: [email-masked]
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , [email-masked]
References: <[email-masked]> <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Tue, Jan 26, 2010 at 05:00:43PM -0500, Edward Lewis wrote:
> To come back to EPP, I think we need to revisit "active/inactive" and
> the implications it has to a registry.

Agreed. It seemed to me we needed the DNSSEC details for that,
though, but I'm happy if we say we don't.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QM0oiM022682 for ; Tue, 26 Jan 2010 23:00:50 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QM0ooc018525 for ietf-provreg-outgoing; Tue, 26 Jan 2010 23:00:50 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QM0mQs000409 for ; Tue, 26 Jan 2010 23:00:49 +0100 (MET)
Received: from [10.31.200.236] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0QM0iQ3081349; Tue, 26 Jan 2010 17:00:45 -0500 (EST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <[email-masked]> <[email-masked]> <[email-masked]>
Date: Tue, 26 Jan 2010 17:00:43 -0500
To: Edward Lewis
From: Edward Lewis
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310
Cc: Andrew Sullivan , [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4
Sender: [email-masked]
Precedence: bulk

Was meant to be off-list. Because I'm diving into the details of
DNSSEC itself. (And not saying anything new.)

To come back to EPP, I think we need to revisit "active/inactive" and
the implications it has to a registry.

At 16:24 -0500 1/26/10, Edward Lewis wrote:
>I think this has veered off-topic for EPP. ;)
>
>At 15:37 -0500 1/26/10, Andrew Sullivan wrote:
>>On Tue, Jan 26, 2010 at 03:23:15PM -0500, Edward Lewis wrote:
>>>> I don't think I understand this one. Do you mean that there's no
>>>> RRSIG for that DNSKEY record?
>>>
>>> To clarify - Yes. In this instance, "in-active" would cover having a DS
>>> appear, the DNSKEY appear, but no RRSIG created by the private key. That
>>> would make the DS "in-active" in terms of building a chain of trust.
>>
>>I like this idea better than just not putting the DNSKEY in the DNSKEY
>>RRset. Is anyone doing their deployment this way?
>>
>>On the other hand, I suppose it doesn't really matter whether one does
>>it this way or by just not including the DNSKEY on the child side. In
>>either case, you have to use the old key until the TTL expires
>>(because without an RRSIG, the new key won't be useful either).
>
>If you are doing SEP=KSK and ZSK for all other keys, the best (IMO)
>thing to do is to add the SEP to the DNSKEY set and include the
>signature when you begin the process of changing. After appropriate
>timing, add the new DS and remove the old DS (or swap in one atomic
>transaction). After more appropriate time, revoke and later remove
>the old key.
>
>We plan to always have an emergency key on-line. So, add new key #3
>to the set of #1 and #2. Later swap #1 with #2. Eventually revoke
>#1. One cycle later, add new key #4, swap #2 with #3, retire #2.
>And so on. From add new key to remove there are three KSK
>signatures, two otherwise. There is always just one DS record (per
>key algorithm and DS hash).
>
>If one does not have a KSK/ZSK model, things will be different. I
>haven't thought through that though.
>
>>So why add the key to the DNSKEY RRset at all?
>
>So the validator can get the key. (If it weren't there, it's not
>going to be anywhere.)
>
>Put the key at the parent...you're back to RFC 2065...;)
>--
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Edward Lewis
>NeuStar You can leave a voice message at +1-571-434-5468
>
>As with IPv6, the problem with the deployment of frictionless surfaces is
>that they're not getting traction.
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>List run by majordomo software. For (Un-)subscription and similar details
>send "help" to [email-masked]

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QLOqe1002170 for ; Tue, 26 Jan 2010 22:24:52 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QLOqr0020398 for ietf-provreg-outgoing; Tue, 26 Jan 2010 22:24:52 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QLOmBY020988 for ; Tue, 26 Jan 2010 22:24:49 +0100 (MET)
Received: from [10.31.200.236] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0QLOkxN081017; Tue, 26 Jan 2010 16:24:47 -0500 (EST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Date: Tue, 26 Jan 2010 16:24:45 -0500
To: Andrew Sullivan
From: Edward Lewis
Subject: off-list was Re: [ietf-provreg] Revision of 4310
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4
Sender: [email-masked]
Precedence: bulk

I think this has veered off-topic for EPP. ;)

At 15:37 -0500 1/26/10, Andrew Sullivan wrote:
>On Tue, Jan 26, 2010 at 03:23:15PM -0500, Edward Lewis wrote:
>>> I don't think I understand this one. Do you mean that there's no
>>> RRSIG for that DNSKEY record?
>>
>> To clarify - Yes. In this instance, "in-active" would cover having a DS
>> appear, the DNSKEY appear, but no RRSIG created by the private key. That
>> would make the DS "in-active" in terms of building a chain of trust.
>
>I like this idea better than just not putting the DNSKEY in the DNSKEY
>RRset. Is anyone doing their deployment this way?
>
>On the other hand, I suppose it doesn't really matter whether one does
>it this way or by just not including the DNSKEY on the child side. In
>either case, you have to use the old key until the TTL expires
>(because without an RRSIG, the new key won't be useful either).

If you are doing SEP=KSK and ZSK for all other keys, the best (IMO)
thing to do is to add the SEP to the DNSKEY set and include the
signature when you begin the process of changing. After appropriate
timing, add the new DS and remove the old DS (or swap in one atomic
transaction). After more appropriate time, revoke and later remove
the old key.

We plan to always have an emergency key on-line. So, add new key #3
to the set of #1 and #2. Later swap #1 with #2. Eventually revoke
#1. One cycle later, add new key #4, swap #2 with #3, retire #2.
And so on. From add new key to remove there are three KSK
signatures, two otherwise. There is always just one DS record (per
key algorithm and DS hash).

If one does not have a KSK/ZSK model, things will be different. I
haven't thought through that though.

>So why add the key to the DNSKEY RRset at all?

So the validator can get the key. (If it weren't there, it's not
going to be anywhere.)

Put the key at the parent...you're back to RFC 2065...;)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QKbe05011977 for ; Tue, 26 Jan 2010 21:37:40 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QKbeDe023803 for ietf-provreg-outgoing; Tue, 26 Jan 2010 21:37:40 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QKbefg016648 for ; Tue, 26 Jan 2010 21:37:40 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C6CCC1ECB4EE for ; Tue, 26 Jan 2010 20:37:38 +0000 (UTC)
Date: Tue, 26 Jan 2010 15:37:36 -0500
From: Andrew Sullivan
To: [email-masked]
Subject: Re: [ietf-provreg] Revision of 4310
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , [email-masked]
References: <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Tue, Jan 26, 2010 at 03:23:15PM -0500, Edward Lewis wrote:
>> I don't think I understand this one. Do you mean that there's no
>> RRSIG for that DNSKEY record?
>
> To clarify - Yes. In this instance, "in-active" would cover having a DS
> appear, the DNSKEY appear, but no RRSIG created by the private key. That
> would make the DS "in-active" in terms of building a chain of trust.

I like this idea better than just not putting the DNSKEY in the DNSKEY
RRset. Is anyone doing their deployment this way?

On the other hand, I suppose it doesn't really matter whether one does
it this way or by just not including the DNSKEY on the child side. In
either case, you have to use the old key until the TTL expires
(because without an RRSIG, the new key won't be useful either). So
why add the key to the DNSKEY RRset at all?

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QKNOrA025959 for ; Tue, 26 Jan 2010 21:23:24 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QKNOLH029814 for ietf-provreg-outgoing; Tue, 26 Jan 2010 21:23:24 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QKNKvE006219 for ; Tue, 26 Jan 2010 21:23:22 +0100 (MET)
Received: from [10.31.200.236] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0QKNJ8L080548; Tue, 26 Jan 2010 15:23:19 -0500 (EST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Tue, 26 Jan 2010 15:23:15 -0500
To: Andrew Sullivan
From: Edward Lewis
Subject: Re: [ietf-provreg] Revision of 4310
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4
Sender: [email-masked]
Precedence: bulk

At 14:31 -0500 1/26/10, Andrew Sullivan wrote:
>On Tue, Jan 26, 2010 at 01:56:12PM -0500, Edward Lewis wrote:
>> I am not sure what active/inactive means.
>
>Yeah, I don't know if this is the best term. Before we go fine-tuning
>the terminology, however, we prolly oughta figure out whether this is
>worth doing.

I think my message was unclear. I wasn't trying to fine tune the
terminology. I was trying to offer possible interpretations of the
words in an attempt to understand the requirement. (Note I went back
to the first message in the thread.)

>> 3) that the DNSKEY set in the child zone is signed/not-signed by the
>> corresponding private key.
>
>I don't think I understand this one. Do you mean that there's no
>RRSIG for that DNSKEY record?

To clarify - Yes. In this instance, "in-active" would cover having a
DS appear, the DNSKEY appear, but no RRSIG created by the private
key. That would make the DS "in-active" in terms of building a chain
of trust.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QJX4s5008268 for ; Tue, 26 Jan 2010 20:33:04 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QJX4Ep005387 for ietf-provreg-outgoing; Tue, 26 Jan 2010 20:33:04 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QJX3DY015003 for ; Tue, 26 Jan 2010 20:33:03 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 2DEA71ECB5DA for ; Tue, 26 Jan 2010 19:33:00 +0000 (UTC)
Date: Tue, 26 Jan 2010 14:32:58 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] Revision of 4310
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To:
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Tue, Jan 26, 2010 at 02:25:51PM -0500, James Gould wrote:
> setting or using the secDNS:chg to replace all). I donâ€™t want to rework the
> interface to add this optional attribute, so will the existing interface
> work for this additional attribute?

See my other note in response to Ed: I think we need to figure out
whether anyone might really want this feature before we start making
it work :-)

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QJVu3S022718 for ; Tue, 26 Jan 2010 20:31:56 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QJVuCG005216 for ietf-provreg-outgoing; Tue, 26 Jan 2010 20:31:56 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QJVtxE006753 for ; Tue, 26 Jan 2010 20:31:56 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 9586F1ECB5DA for ; Tue, 26 Jan 2010 19:31:54 +0000 (UTC)
Date: Tue, 26 Jan 2010 14:31:52 -0500
From: Andrew Sullivan
To: [email-masked]
Subject: Re: [ietf-provreg] Revision of 4310
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , [email-masked]
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Tue, Jan 26, 2010 at 01:56:12PM -0500, Edward Lewis wrote:
> I am not sure what active/inactive means.

Yeah, I don't know if this is the best term. Before we go fine-tuning
the terminology, however, we prolly oughta figure out whether this is
worth doing.

> 1) published/not-published in the parent zone

Like James, I can see no reason to have two ways to do this.

> 2) tthe corresponding DNSKEY is published/not-published in the child zone

I can see a reason to do this.

> 3) that the DNSKEY set in the child zone is signed/not-signed by the
> corresponding private key.

I don't think I understand this one. Do you mean that there's no
RRSIG for that DNSKEY record?

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QJPvln025260 for ; Tue, 26 Jan 2010 20:25:57 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QJPvom006559 for ietf-provreg-outgoing; Tue, 26 Jan 2010 20:25:57 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QJPuUY005191 for ; Tue, 26 Jan 2010 20:25:56 +0100 (MET)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o0QJL0x1027942; Tue, 26 Jan 2010 14:21:00 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 14:25:55 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Tue, 26 Jan 2010 19:25:54 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Tue, 26 Jan 2010 14:25:51 -0500
Subject: Re: [ietf-provreg] Revision of 4310
From: James Gould
To: Andrew Sullivan , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] Revision of 4310
Thread-Index: AcqeuSBSJf0tcZfwRIO4Gjv3i3iZtgABD55g
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3347360752_6432068"
X-OriginalArrivalTime: 26 Jan 2010 19:25:55.0319 (UTC) FILETIME=[61605070:01CA9EBD]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3347360752_6432068
Content-type: text/plain;
charset="EUC-KR"
Content-transfer-encoding: quoted-printable

Andrew,

You not saying that the DS is active or not active, but that the associate=
d
DNSKEY in the child zone exists. The term active is really misleading and
certainly should not be used in this case. Your proposing that the client
tell the server whether they=A1=AFve published their DNSKEY for validation base=
d
on server policy? I guess based on this something like childKeyActive is
more appropriate since this is not an attribute of the DS. I still have a
concern about the interface that needs to be used to change the attribute (
secDNS:add and secDNS:rem the same DS or key with a new childKeyActive
setting or using the secDNS:chg to replace all). I don=A1=AFt want to rework t=
he
interface to add this optional attribute, so will the existing interface
work for this additional attribute?

--=20

JG=20

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

=20
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior writte=
n
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

From: Andrew Sullivan
Date: Tue, 26 Jan 2010 13:30:59 -0500
To: EPP Provreg
Subject: Re: [ietf-provreg] Revision of 4310

On Tue, Jan 26, 2010 at 12:19:06PM -0500, James Gould wrote:

> Ok, so you=A9=F6re saying the difference is that the active flag only drives =
the
> server validation of the DNSKEY but the server would still publish
> it.=20

The idea that I had was that this was a way for the client to signal
to the parent what role the key is going to play, yes. I don't
actually care what we call it, no.

> The
> term active and inactive is sort of misleading in this case. An =A9=F8inacti=
ve=A9=F7
> DS (or key) does not exclude the DS from being published in the zone, but
> simply removes the validation.

Maybe. I figured the "active" meant "actively in use", and is
strictly speaking a property of the DNSKEY and not the DS. The DS
happens to correspond to a DNSKEY that is in active use, or not.

A different name (with maybe a different meaning) is "published".
This one corresponds more exactly with the kind of use I'm thinking
of, because it tells the parent whether the DNSKEY appears in a public
zone.

> So why would the client ever =A9=F8activate=A9=F7 a DS, if the validation is
> being done as part of a server policy and the active flag controls
> the application of the policy? The client would most likely want
> the server to do what they want and always set the flag to false.

Could be. There's an advantage to the sponsor telling the repository
which keys are _supposed_ to be available, however, because that gives
the two parties responsible at the zone cut a mechanism for properly
co-ordinating their actions. I haven't thought it through completely,
but it strikes me that this might also make life easier at domain
transfer time, also, because the target DNSKEY could be sent to the
parent and made available as a DS without actually being published.
(What bugs me about this is the potential for hijacking, so I'm not
yet convinced it's a good idea.)

> In either case would a better name of the attribute be =A9=F8validate=A9=F7
> instead of =A9=F8active=A9=F7?

Whatever we use, not "validate", please. That word's already
meaningful in a DNSSEC context, and I don't want to overload it.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

--B_3347360752_6432068
Content-type: text/html;
charset="EUC-KR"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] Revision of 4310

Andrew,

You not saying  that the DS is active or not active, but that the asso=
ciated DNSKEY in the child zone exists.  The term active is really misl=
eading and certainly should not be used in this case.  Your proposing t=
hat the client tell the server whether they’ve published their DNSKEY =
for validation based on server policy?  I guess based on this something=
like childKeyActive is more appropriate since this is not an attribute of t=
he DS.  I still have a concern about the interface that needs to be use=
d to change the attribute ( secDNS:add and secDNS:rem the same DS or key wit=
h a new childKeyActive setting or using the secDNS:chg to replace all). &nbs=
p;I don’t want to rework the interface to add this optional attribute,=
so will the existing interface work for this additional attribute?

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

From: Andrew Sullivan <[email-masked]>

Date: Tue, 26 Jan 2010 13:30:59 -0500

To: EPP Provreg <ietf-provreg@caf=
ax.se>

Subject: Re: [ietf-provreg] Revision of 4310

On Tue, Jan 26, 2010 at 12:19:06PM -0500, James Gould wrote:

> Ok, so you¹re saying the difference is that the active flag only =
drives the

> server validation of the DNSKEY but the server would still publish

> it.

The idea that I had was that this was a way for the client to signal

to the parent what role the key is going to play, yes.  I don't

actually care what we call it, no.

> The

> term active and inactive is sort of misleading in this case.  An =
³inactive²

> DS (or key) does not exclude the DS from being published in the zone, =
but

> simply removes the validation.

Maybe.  I figured the "active" meant "actively in use&q=
uot;, and is

strictly speaking a property of the DNSKEY and not the DS.  The DS

happens to correspond to a DNSKEY that is in active use, or not.

A different name (with maybe a different meaning) is "published".=

This one corresponds more exactly with the kind of use I'm thinking

of, because it tells the parent whether the DNSKEY appears in a public

zone.

> So why would the client ever ³activate² a DS, if the validat=
ion is

> being done as part of a server policy and the active flag controls

> the application of the policy?  The client would most likely want=

> the server to do what they want and always set the flag to false.

Could be.  There's an advantage to the sponsor telling the repository<=
BR>
which keys are _supposed_ to be available, however, because that gives

the two parties responsible at the zone cut a mechanism for properly

co-ordinating their actions.  I haven't thought it through completely,=

but it strikes me that this might also make life easier at domain

transfer time, also, because the target DNSKEY could be sent to the

parent and made available as a DS without actually being published.

(What bugs me about this is the potential for hijacking, so I'm not

yet convinced it's a good idea.)

> In either case would a better name of the attribute be ³validate&=
sup2;

> instead of ³active²?

Whatever we use, not "validate", please.  That word's alread=
y

meaningful in a DNSSEC context, and I don't want to overload it.

A

--

Andrew Sullivan

[email-masked]

Shinkuro, Inc.

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=

List run by majordomo software.  For (Un-)subscription and similar det=
ails

send "help" to ietf-provr=
[email-masked]

--B_3347360752_6432068--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QJ4okh020915 for ; Tue, 26 Jan 2010 20:04:50 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QJ4omt017385 for ietf-provreg-outgoing; Tue, 26 Jan 2010 20:04:50 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QJ4m2X029172 for ; Tue, 26 Jan 2010 20:04:48 +0100 (MET)
Received: from [10.31.200.236] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0QJ4kI2079938; Tue, 26 Jan 2010 14:04:47 -0500 (EST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <1264525413.22998.91.camel@localhost> <[email-masked]>
Date: Tue, 26 Jan 2010 14:04:40 -0500
To: Andrew Sullivan
From: Edward Lewis
Subject: [ietf-provreg] extensions to EPP was Re: Setting TTLs (was ...
Cc: EPP Provreg
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4
Sender: [email-masked]
Precedence: bulk

At 12:09 -0500 1/26/10, Andrew Sullivan wrote:

>Nevertheless, I find this interesting (and I'd sure like to see this
>be one of the extensions that gets documented by any new provreg2 WG).

When you consider extensions in individual, it's not compulsory
(required) that all extensions to EPP be put through a standards
process. There's probably some subjective benchmark at which a
standard definition is a good idea.

But looking at the population of such extensions, I become concerned
that the protocol could become an architectural nightmare. This has
happened before, extensions in DNS spurred BIND 8 to replace BIND 4,
in operating systems this happened too about 15-20 years ago.

I'm not singling out this extension, but throwing another thought out
there regarding whether we want to request a BoF this summer and rev
up a provisioning protocol wg.

(I'm certainly not trying to rope in innovations out there - such as
4310bis - progress shouldn't be stopped.)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QIuLLW000465 for ; Tue, 26 Jan 2010 19:56:21 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QIuLfI016888 for ietf-provreg-outgoing; Tue, 26 Jan 2010 19:56:21 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QIuIDO001138 for ; Tue, 26 Jan 2010 19:56:20 +0100 (MET)
Received: from [10.31.200.236] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0QIuDmH079812; Tue, 26 Jan 2010 13:56:14 -0500 (EST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Tue, 26 Jan 2010 13:56:12 -0500
To: Eduardo Duarte
From: Edward Lewis
Subject: Re: [ietf-provreg] Revision of 4310
Cc: [email-masked], "'WG-DNS'"
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4
Sender: [email-masked]
Precedence: bulk

At 14:56 +0000 1/25/10, Eduardo Duarte wrote:

>On our implementation of DNSSEC a domain can have multiple DS keys
>associated were some are active and other are in an inactive state.

I am not sure what active/inactive means.

Does an inactive DS record appear in the parent zone?

In my view - active/inactive could mean

1) published/not-published in the parent zone
2) tthe corresponding DNSKEY is published/not-published in the child zone
3) that the DNSKEY set in the child zone is signed/not-signed by the
corresponding private key.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QIV4If008664 for ; Tue, 26 Jan 2010 19:31:04 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QIV4xn022424 for ietf-provreg-outgoing; Tue, 26 Jan 2010 19:31:04 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QIV3fc004694 for ; Tue, 26 Jan 2010 19:31:03 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 508791ECB4FD for ; Tue, 26 Jan 2010 18:31:02 +0000 (UTC)
Date: Tue, 26 Jan 2010 13:30:59 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] Revision of 4310
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To:
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Tue, Jan 26, 2010 at 12:19:06PM -0500, James Gould wrote:

> Ok, so youÂ¹re saying the difference is that the active flag only drives the
> server validation of the DNSKEY but the server would still publish
> it.

The idea that I had was that this was a way for the client to signal
to the parent what role the key is going to play, yes. I don't
actually care what we call it, no.

> The
> term active and inactive is sort of misleading in this case. An Â³inactiveÂ²
> DS (or key) does not exclude the DS from being published in the zone, but
> simply removes the validation.

Maybe. I figured the "active" meant "actively in use", and is
strictly speaking a property of the DNSKEY and not the DS. The DS
happens to correspond to a DNSKEY that is in active use, or not.

A different name (with maybe a different meaning) is "published".
This one corresponds more exactly with the kind of use I'm thinking
of, because it tells the parent whether the DNSKEY appears in a public
zone.

> So why would the client ever Â³activateÂ² a DS, if the validation is
> being done as part of a server policy and the active flag controls
> the application of the policy? The client would most likely want
> the server to do what they want and always set the flag to false.

Could be. There's an advantage to the sponsor telling the repository
which keys are _supposed_ to be available, however, because that gives
the two parties responsible at the zone cut a mechanism for properly
co-ordinating their actions. I haven't thought it through completely,
but it strikes me that this might also make life easier at domain
transfer time, also, because the target DNSKEY could be sent to the
parent and made available as a DS without actually being published.
(What bugs me about this is the potential for hijacking, so I'm not
yet convinced it's a good idea.)

> In either case would a better name of the attribute be Â³validateÂ²
> instead of Â³activeÂ²?

Whatever we use, not "validate", please. That word's already
meaningful in a DNSSEC context, and I don't want to overload it.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QHJC05023437 for ; Tue, 26 Jan 2010 18:19:12 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QHJClT008555 for ietf-provreg-outgoing; Tue, 26 Jan 2010 18:19:12 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QHJBNk024136 for ; Tue, 26 Jan 2010 18:19:11 +0100 (MET)
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o0QH0M07029957; Tue, 26 Jan 2010 12:00:22 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 12:19:10 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Tue, 26 Jan 2010 17:19:09 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Tue, 26 Jan 2010 12:19:06 -0500
Subject: Re: [ietf-provreg] Revision of 4310
From: James Gould
To: Andrew Sullivan , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] Revision of 4310
Thread-Index: Acqeqa/LPPaG98AZRkyIUQy1XkIbIwAAfoTc
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3347353147_5944875"
X-OriginalArrivalTime: 26 Jan 2010 17:19:10.0839 (UTC) FILETIME=[ACC0C070:01CA9EAB]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3347353147_5944875
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Andrew,

Ok, so you=B9re saying the difference is that the active flag only drives the
server validation of the DNSKEY but the server would still publish it. The
term active and inactive is sort of misleading in this case. An =B3inactive=B2
DS (or key) does not exclude the DS from being published in the zone, but
simply removes the validation. So why would the client ever =B3activate=B2 a
DS, if the validation is being done as part of a server policy and the
active flag controls the application of the policy? The client would most
likely want the server to do what they want and always set the flag to
false. In either case would a better name of the attribute be =B3validate=B2
instead of =B3active=B2?

--=20

JG=20

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

=20
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior writte=
n
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

From: Andrew Sullivan
Date: Tue, 26 Jan 2010 11:41:21 -0500
To: EPP Provreg
Subject: Re: [ietf-provreg] Revision of 4310

On Tue, Jan 26, 2010 at 11:13:44AM -0500, James Gould wrote:

> What is the fundamental difference between a deactivate and a remove? It
> sounds like exactly the same from a DNS perspective and the TTL. The
> emergency key rollover use case that you present will be handled exactly =
the
> same way if the client were to remove the DS from the Registry as opposed=
to
> deactivating it and than later removing it. The deactivate from my
> understanding will not remove it from the zone any faster then the existi=
ng
> remove. Please explain the difference.

It's the other way around. Having a bad key around that you're not
using does no harm. But _adding_ a key isn't instant either.

If I validate your key, I look up the DS from the parent. That DS
RRSet ends up cached in the cacheing resolver in front of me.

If you now add a new DNSKEY in an emergency, and stop using your old
key, then the DS that is cached is still the one I use when
validating.

Now, if you have a short TTL on your own DNSKEY record, your old
DNSKEY will expire from my cache quickly.

But AFAIK, no TLD allows clients to set the TTL on RRs in the parent
zone.

That means that the fastest you can roll your key is the maximum TTL
on the DNSKEY or DS records. So if the parent has long TTLs, you're
stuck with the TTL on the DS record.

Now, if you can add a DS into the parent _before_ you add the DNSKEY
to your zone, then the DNSKEY need not actually be in your zone when
the DS is available in the parent.

Now, some zone operators have said they want to validate that the
DNSKEY is available in the child before publishing the corresponding
DS in the parent. But if EPP were to offer a mechanism whereby you
could say, "I want you to have this DS record in the DS RRSet, but
_don't_ expect a DNSKEY in the child yet," then the parent would know
not to perform that check when adding the DS record. (By policy, I
suppose, the "activation" bit could cause the check against the
child.)

So that's the use case. I don't know how important this is to
operators, however.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

--B_3347353147_5944875
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] Revision of 4310

Andrew,

Ok, so you’re saying the difference is that the active flag only driv=
es the server validation of the DNSKEY but the server would still publish it=
.  The term active and inactive is sort of misleading in this case. &nb=
sp;An “inactive” DS (or key) does not exclude the DS from being =
published in the zone, but simply removes the validation.  So why would=
the client ever “activate” a DS, if the validation is being don=
e as part of a server policy and the active flag controls the application of=
the policy?  The client would most likely want the server to do what t=
hey want and always set the flag to false.  In either case would a bett=
er name of the attribute be “validate” instead of “active&=
#8221;?

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

From: Andrew Sullivan <[email-masked]>

Date: Tue, 26 Jan 2010 11:41:21 -0500

To: EPP Provreg <ietf-provreg@caf=
ax.se>

Subject: Re: [ietf-provreg] Revision of 4310

On Tue, Jan 26, 2010 at 11:13:44AM -0500, James Gould wrote:

> What is the fundamental difference between a deactivate and a remove? =
It

> sounds like exactly the same from a DNS perspective and the TTL.  =
;The

> emergency key rollover use case that you present will be handled exact=
ly the

> same way if the client were to remove the DS from the Registry as oppo=
sed to

> deactivating it and than later removing it.  The deactivate from =
my

> understanding will not remove it from the zone any faster then the exi=
sting

> remove.  Please explain the difference.

It's the other way around.  Having a bad key around that you're not
using does no harm.  But _adding_ a key isn't instant either.

If I validate your key, I look up the DS from the parent.  That DS

RRSet ends up cached in the cacheing resolver in front of me.

If you now add a new DNSKEY in an emergency, and stop using your old

key, then the DS that is cached is still the one I use when

validating.

Now, if you have a short TTL on your own DNSKEY record, your old

DNSKEY will expire from my cache quickly.

But AFAIK, no TLD allows clients to set the TTL on RRs in the parent

zone.

That means that the fastest you can roll your key is the maximum TTL

on the DNSKEY or DS records.  So if the parent has long TTLs, you're
stuck with the TTL on the DS record.

Now, if you can add a DS into the parent _before_ you add the DNSKEY

to your zone, then the DNSKEY need not actually be in your zone when

the DS is available in the parent.

Now, some zone operators have said they want to validate that the

DNSKEY is available in the child before publishing the corresponding

DS in the parent.  But if EPP were to offer a mechanism whereby you
could say, "I want you to have this DS record in the DS RRSet, but

_don't_ expect a DNSKEY in the child yet," then the parent would know<=
BR>
not to perform that check when adding the DS record.  (By policy, I
suppose, the "activation" bit could cause the check against the
child.)

So that's the use case.  I don't know how important this is to

operators, however.

A

--

Andrew Sullivan

[email-masked]

Shinkuro, Inc.

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=

List run by majordomo software.  For (Un-)subscription and similar det=
ails

send "help" to ietf-provr=
[email-masked]

--B_3347353147_5944875--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QH9cqp005200 for ; Tue, 26 Jan 2010 18:09:39 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QH9cxH003146 for ietf-provreg-outgoing; Tue, 26 Jan 2010 18:09:38 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QH9cRX026544 for ; Tue, 26 Jan 2010 18:09:38 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 73E131ECB4FE for ; Tue, 26 Jan 2010 17:09:37 +0000 (UTC)
Date: Tue, 26 Jan 2010 12:09:35 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: Setting TTLs (was Re: [ietf-provreg] Revision of 4310)
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References: <[email-masked]> <[email-masked]> <1264525413.22998.91.camel@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1264525413.22998.91.camel@localhost>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Tue, Jan 26, 2010 at 05:03:33PM +0000, Gavin Brown wrote:

> is something we are thinking of doing if there is interest in it, at the
> moment it is little used by our registrars, and when they do use it,
> they do it wrong).

Heh. This is one of the things I'd worry about. There's a potential
load issue, too, of course: if some huge registrar sets all the TTLs
to 5 seconds, your DNS servers are going to be swamped.

Nevertheless, I find this interesting (and I'd sure like to see this
be one of the extensions that gets documented by any new provreg2 WG).

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QH3eDb017226 for ; Tue, 26 Jan 2010 18:03:40 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QH3eDR017708 for ietf-provreg-outgoing; Tue, 26 Jan 2010 18:03:40 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from smtp.centralnic.com (smtp.centralnic.com [213.146.149.131]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QH3eFE025995 for ; Tue, 26 Jan 2010 18:03:40 +0100 (MET)
Received: from [192.168.1.130] (unknown [82.68.174.118]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTP id 6EF65712BE9; Tue, 26 Jan 2010 17:03:39 +0000 (UTC)
Subject: Setting TTLs (was Re: [ietf-provreg] Revision of 4310)
From: Gavin Brown
To: Andrew Sullivan
Cc: EPP Provreg
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Organization: CentralNic Ltd
Date: Tue, 26 Jan 2010 17:03:33 +0000
Message-ID: <1264525413.22998.91.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.2 (2.28.2-1.fc12)
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

On Tue, 2010-01-26 at 11:41 -0500, Andrew Sullivan wrote:
> But AFAIK, no TLD allows clients to set the TTL on RRs in the parent
> zone.

This is something that CentralNic allows. We created an EPP extension
for it but haven't produced a schema document or an internet draft (this
is something we are thinking of doing if there is interest in it, at the
moment it is little used by our registrars, and when they do use it,
they do it wrong).

The documentation we have for this is here:

https://www.centralnic.com/company/labs/epp/ext/ttl

Regards,

--
Gavin Brown
Chief Technology Officer
CentralNic Global Registry Services
Innovative Registry Services for ccTLD and gTLD registries
https://www.centralnic.com/grs

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QH1FK2005510 for ; Tue, 26 Jan 2010 18:01:15 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QH1FNq029262 for ietf-provreg-outgoing; Tue, 26 Jan 2010 18:01:15 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QH1E2E029560 for ; Tue, 26 Jan 2010 18:01:15 +0100 (MET)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o0QGuJvw021620; Tue, 26 Jan 2010 11:56:19 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 12:01:13 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Tue, 26 Jan 2010 17:01:13 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Tue, 26 Jan 2010 12:01:07 -0500
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis
From: James Gould
To: Andrew Sullivan , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] XML Schema versioning in 4310bis
Thread-Index: AcqelYr/TYUOZJ0uS/iETkmJVM8GnwAE5u/Q
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3347352067_5926726"
X-OriginalArrivalTime: 26 Jan 2010 17:01:13.0923 (UTC) FILETIME=[2ADC6930:01CA9EA9]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3347352067_5926726
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

All,

The way I view this is considering what is done from an Object Oriented
perspective. If I have a defined interface that is being used, to add
features but with maintaining backward compatibility I would create an
extended interface without touching the existing interface. I=B9m assuming
that some sort of factory is being used here to return the appropriate
object, where clients of the old interface would continue using the old
interface and clients of the new interface would type cast to use the new
interface. As far as 4310bis goes, changing the URI is like changing the
package of the existing interface which will not allow the client to use th=
e
existing interface. I do see the issue of a client that wants to use the
new interface not being aware that it=B9s supported. In programming
languages, the client would use reflection to determine if the new interfac=
e
is supported. =20

I have always been an advocate for backward compatibility, where a change t=
o
the URI will break compatibility. How about looking for a compromise on
this? What if we reused urn:ietf:params:xml:ns:secDNS-1.0 for the protocol
messages but add the requirement that the server publish the new URI
urn:ietf:params:xml:ns:secDNS-1.1 in addition to
urn:ietf:params:xml:ns:secDNS-1.0 in the greeting if 4310bis is supported?
We could register the new URI namespace (not the schema) and use it strictl=
y
for publishing the support for the later draft. Clients are not forced to
deal with different versions across the servers, servers can support a
single version (either old or backward compatible new), and servers
explicitly publish support for the new specification in the greeting.

--=20

JG=20

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

=20
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior writte=
n
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

From: Andrew Sullivan
Date: Tue, 26 Jan 2010 09:15:08 -0500
To: EPP Provreg
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis

On Tue, Jan 26, 2010 at 09:01:47AM +0100, Ulrich Wisser wrote:
> Hi,
>
> in this case I have to agree with James. We discussed changing the URI
> and came to the conclusion that changing the URI will break old clients
> without any need to do so.

That argument is circular. What is up for debate is whether there is
in fact a need to do this.

> But let's have a look on the alternatives:
>
> 1. Server supports only the "old" 1.0
> - no changes on client or server
> 2. Server supports only the "new" 1.0
> - only changes on the server side needed
> 3. Server supports both
> - only changes on the server side needed

But in (2) and (3), the client _can't tell_ what support is in the
server. The whole point of the handshake in the protocol is to make
it possible for people to tell.

> Which registry is going to support 1.0 after 1.1 has been released for
> any time longer then needed?

Who knows? This is the Internet. We have parts of the DNS
infrastructure (including several MSFT APIs) that don't support the
DNS Unknown type, even though that was specified over 10 years ago and
is terribly useful.

> Another question comes to mind: Why should 1.1 be backwards compatible?
> If we break the URI there is no need to keep the broken , is it?

Right.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

--B_3347352067_5926726
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] XML Schema versioning in 4310bis

All,

The way I view this is considering what is done from an Object Oriented per=
spective.  If I have a defined interface that is being used, to add fea=
tures but with maintaining backward compatibility I would create an extended=
interface without touching the existing interface.  I’m assuming=
that some sort of factory is being used here to return the appropriate obje=
ct, where clients of the old interface would continue using the old interfac=
e and clients of the new interface would type cast to use the new interface.=
As far as 4310bis goes, changing the URI is like changing the package=
of the existing interface which will not allow the client to use the existi=
ng interface.  I do see the issue of a client that wants to use the new=
interface not being aware that it’s supported.  In programming l=
anguages, the client would use reflection to determine if the new interface =
is supported.

I have always been an advocate for backward compatibility, where a change t=
o the URI will break compatibility.  How about looking for a compromise=
on this?  What if we reused urn:ietf:params:xml:ns:secDNS-1.0 for the =
protocol messages but add the requirement that the server publish the new UR=
I  urn:ietf:params:xml:ns:secDNS-1.1 in addition to urn:ietf:params:xml=
:ns:secDNS-1.0 in the greeting if 4310bis is supported?  We could regis=
ter the new URI namespace (not the schema) and use it strictly for publishin=
g the support for the later draft.  Clients are not forced to deal with=
different versions across the servers, servers can support a single version=
(either old or backward compatible new), and servers explicitly publish sup=
port for the new specification in the greeting.

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

From: Andrew Sullivan <[email-masked]>

Date: Tue, 26 Jan 2010 09:15:08 -0500

To: EPP Provreg <ietf-provreg@caf=
ax.se>

Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis

On Tue, Jan 26, 2010 at 09:01:47AM +0100, Ulrich Wisser wrote:

> Hi,

> in this case I have to agree with James. We discussed changing the URI=

> and came to the conclusion that changing the URI will break old client=
s

> without any need to do so.

That argument is circular.  What is up for debate is whether there is<=
BR>
in fact a need to do this.

> But let's have a look on the alternatives:

> 1. Server supports only the "old" 1.0

>    - no changes on client or server

> 2. Server supports only the "new" 1.0

>    - only changes on the server side needed

> 3. Server supports both

>    - only changes on the server side needed

But in (2) and (3), the client _can't tell_ what support is in the

server.  The whole point of the handshake in the protocol is to make
it possible for people to tell.

> Which registry is going to support 1.0 after 1.1 has been released for=

> any time longer then needed?

Who knows?  This is the Internet.  We have parts of the DNS

infrastructure (including several MSFT APIs) that don't support the

DNS Unknown type, even though that was specified over 10 years ago and

is terribly useful.

> Another question comes to mind: Why should 1.1 be backwards compatible=
?

> If we break the URI there is no need to keep the broken <rem/>, =
is it?

Right.

A

--

Andrew Sullivan

[email-masked]

Shinkuro, Inc.

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=

List run by majordomo software.  For (Un-)subscription and similar det=
ails

send "help" to ietf-provr=
[email-masked]

--B_3347352067_5926726--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QGfQYN020888 for ; Tue, 26 Jan 2010 17:41:26 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QGfQmT025497 for ietf-provreg-outgoing; Tue, 26 Jan 2010 17:41:26 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QGfQZH007128 for ; Tue, 26 Jan 2010 17:41:26 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 244F21ECB4F9 for ; Tue, 26 Jan 2010 16:41:25 +0000 (UTC)
Date: Tue, 26 Jan 2010 11:41:21 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] Revision of 4310
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Tue, Jan 26, 2010 at 11:13:44AM -0500, James Gould wrote:

> What is the fundamental difference between a deactivate and a remove? It
> sounds like exactly the same from a DNS perspective and the TTL. The
> emergency key rollover use case that you present will be handled exactly the
> same way if the client were to remove the DS from the Registry as opposed to
> deactivating it and than later removing it. The deactivate from my
> understanding will not remove it from the zone any faster then the existing
> remove. Please explain the difference.

It's the other way around. Having a bad key around that you're not
using does no harm. But _adding_ a key isn't instant either.

If I validate your key, I look up the DS from the parent. That DS
RRSet ends up cached in the cacheing resolver in front of me.

If you now add a new DNSKEY in an emergency, and stop using your old
key, then the DS that is cached is still the one I use when
validating.

Now, if you have a short TTL on your own DNSKEY record, your old
DNSKEY will expire from my cache quickly.

But AFAIK, no TLD allows clients to set the TTL on RRs in the parent
zone.

That means that the fastest you can roll your key is the maximum TTL
on the DNSKEY or DS records. So if the parent has long TTLs, you're
stuck with the TTL on the DS record.

Now, if you can add a DS into the parent _before_ you add the DNSKEY
to your zone, then the DNSKEY need not actually be in your zone when
the DS is available in the parent.

Now, some zone operators have said they want to validate that the
DNSKEY is available in the child before publishing the corresponding
DS in the parent. But if EPP were to offer a mechanism whereby you
could say, "I want you to have this DS record in the DS RRSet, but
_don't_ expect a DNSKEY in the child yet," then the parent would know
not to perform that check when adding the DS record. (By policy, I
suppose, the "activation" bit could cause the check against the
child.)

So that's the use case. I don't know how important this is to
operators, however.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QGDoHI019205 for ; Tue, 26 Jan 2010 17:13:50 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QGDoLn027577 for ietf-provreg-outgoing; Tue, 26 Jan 2010 17:13:50 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QGDnxh015587 for ; Tue, 26 Jan 2010 17:13:49 +0100 (MET)
Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o0QFsxHf027221; Tue, 26 Jan 2010 10:55:00 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 11:13:48 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Tue, 26 Jan 2010 16:13:47 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Tue, 26 Jan 2010 11:13:44 -0500
Subject: Re: [ietf-provreg] Revision of 4310
From: James Gould
To: Andrew Sullivan , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] Revision of 4310
Thread-Index: AcqempgDcLLfLh3jTPqMC4i1a5+mnQAB/AqI
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3347349225_5721379"
X-OriginalArrivalTime: 26 Jan 2010 16:13:48.0578 (UTC) FILETIME=[8AE73820:01CA9EA2]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3347349225_5721379
Content-type: text/plain;
charset="EUC-KR"
Content-transfer-encoding: quoted-printable

Andrew,

What is the fundamental difference between a deactivate and a remove? It
sounds like exactly the same from a DNS perspective and the TTL. The
emergency key rollover use case that you present will be handled exactly th=
e
same way if the client were to remove the DS from the Registry as opposed t=
o
deactivating it and than later removing it. The deactivate from my
understanding will not remove it from the zone any faster then the existing
remove. Please explain the difference.

Thanks,

--=20

JG=20

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

=20
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior writte=
n
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

From: Andrew Sullivan
Date: Tue, 26 Jan 2010 09:51:23 -0500
To: EPP Provreg
Subject: Re: [ietf-provreg] Revision of 4310

On Tue, Jan 26, 2010 at 09:44:40AM -0500, James Gould wrote:
> Andrew,
>
> I don=A9=F6t understand why the client wouldn=A9=F6t just add the DS when it beco=
mes
> active to the server instead of pre-publishing and activating. Adding an

Because of caches, and the TTL on the parent zone which is not
controllable by the client.

If you have to do an emergency key rollover, you _can't_ stop using
your old key until the longest TTL in the system without your zone
validating bogus. If the parent at the start only has the old DS, and
you've yanked the corresponding DNSKEY because you know it to be
compromised, then anyone who hits a cache containing the old DS will
get it until it has expired.

If the parent-held DS RRSet contains a DS corresponding to a new
DNSKEY, then you can cycle that DNSKEY in immediately. You might not
have been using it, or even publishing it in the DNSKEY RRSet because
you might have wanted to keep your response size reasonably small.

The EPP extension as it stands just doesn't support this option.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

--B_3347349225_5721379
Content-type: text/html;
charset="EUC-KR"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] Revision of 4310

Andrew,

What is the fundamental difference between a deactivate and a remove?  =
;It sounds like exactly the same from a DNS perspective and the TTL.  T=
he emergency key rollover use case that you present will be handled exactly =
the same way if the client were to remove the DS from the Registry as oppose=
d to deactivating it and than later removing it.  The deactivate from m=
y understanding will not remove it from the zone any faster then the existin=
g remove.  Please explain the difference.

Thanks,

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

From: Andrew Sullivan <[email-masked]>

Date: Tue, 26 Jan 2010 09:51:23 -0500

To: EPP Provreg <ietf-provreg@caf=
ax.se>

Subject: Re: [ietf-provreg] Revision of 4310

On Tue, Jan 26, 2010 at 09:44:40AM -0500, James Gould wrote:

> Andrew,

> I don¹t understand why the client wouldn¹t just add the DS w=
hen it becomes

> active to the server instead of pre-publishing and activating.  A=
dding an

Because of caches, and the TTL on the parent zone which is not

controllable by the client.

If you have to do an emergency key rollover, you _can't_ stop using

your old key until the longest TTL in the system without your zone

validating bogus.  If the parent at the start only has the old DS, and=

you've yanked the corresponding DNSKEY because you know it to be

compromised, then anyone who hits a cache containing the old DS will

get it until it has expired.

If the parent-held DS RRSet contains a DS corresponding to a new

DNSKEY, then you can cycle that DNSKEY in immediately.  You might not<=
BR>
have been using it, or even publishing it in the DNSKEY RRSet because

you might have wanted to keep your response size reasonably small.

The EPP extension as it stands just doesn't support this option.

A

--

Andrew Sullivan

[email-masked]

Shinkuro, Inc.

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=

List run by majordomo software.  For (Un-)subscription and similar det=
ails

send "help" to ietf-provr=
[email-masked]

--B_3347349225_5721379--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QEpRPD023439 for ; Tue, 26 Jan 2010 15:51:27 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QEpRHE001622 for ietf-provreg-outgoing; Tue, 26 Jan 2010 15:51:27 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QEpQu7012756 for ; Tue, 26 Jan 2010 15:51:26 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7E87B1ECC359 for ; Tue, 26 Jan 2010 14:51:25 +0000 (UTC)
Date: Tue, 26 Jan 2010 09:51:23 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] Revision of 4310
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To:
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Tue, Jan 26, 2010 at 09:44:40AM -0500, James Gould wrote:
> Andrew,
>
> I donÂ¹t understand why the client wouldnÂ¹t just add the DS when it becomes
> active to the server instead of pre-publishing and activating. Adding an

Because of caches, and the TTL on the parent zone which is not
controllable by the client.

If you have to do an emergency key rollover, you _can't_ stop using
your old key until the longest TTL in the system without your zone
validating bogus. If the parent at the start only has the old DS, and
you've yanked the corresponding DNSKEY because you know it to be
compromised, then anyone who hits a cache containing the old DS will
get it until it has expired.

If the parent-held DS RRSet contains a DS corresponding to a new
DNSKEY, then you can cycle that DNSKEY in immediately. You might not
have been using it, or even publishing it in the DNSKEY RRSet because
you might have wanted to keep your response size reasonably small.

The EPP extension as it stands just doesn't support this option.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QEikdS007125 for ; Tue, 26 Jan 2010 15:44:46 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QEikX2017592 for ietf-provreg-outgoing; Tue, 26 Jan 2010 15:44:46 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QEijwA004348 for ; Tue, 26 Jan 2010 15:44:45 +0100 (MET)
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o0QEdnGE015499; Tue, 26 Jan 2010 09:39:49 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 09:44:44 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Tue, 26 Jan 2010 14:44:43 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Tue, 26 Jan 2010 09:44:40 -0500
Subject: Re: [ietf-provreg] Revision of 4310
From: James Gould
To: Andrew Sullivan , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] Revision of 4310
Thread-Index: Acqek2/G+tNsYL4KScGmojWWXU3Z7QAAqcgC
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3347343881_5422626"
X-OriginalArrivalTime: 26 Jan 2010 14:44:44.0046 (UTC) FILETIME=[19505AE0:01CA9E96]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3347343881_5422626
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Andrew,

I don=B9t understand why the client wouldn=B9t just add the DS when it becomes
active to the server instead of pre-publishing and activating. Adding an
active attribute adds a new model that could cause confusion for the client=
s
interfacing with different servers and it doesn=B9t really add anything that
can=B9t be handled today by the client. Adding another attribute that could
change frequently like an active flag could pose an issue of support with
the secDNS:add, secDNS:rem, and secDNS:chg, where the only way to change th=
e
attribute is to use a secDNS:add and secDNS:rem of the same DS (or key), or
use the secDNS:chg to replace all DS (or key) data. I believe this
interface is acceptable for the optional maxSigLife attribute, but would
become onerous for a more frequently used attribute like an active flag.

--=20

JG=20

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

=20
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior writte=
n
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

From: Andrew Sullivan
Date: Tue, 26 Jan 2010 09:06:17 -0500
To: EPP Provreg
Subject: Re: [ietf-provreg] Revision of 4310

On Tue, Jan 26, 2010 at 06:56:24AM +0100, Patrik F=E4ltstr=F6m wrote:

> I think it is much better the way it is now, that all DS the
> registry know about are active. To turn the active/not active flag
> on and off epp transactions are needed anyways, so the client can as
> well remove/add the keys instead.
>
> I.e. I do not see any need for the registry to keep track of
> active/not active keys, and need to get much more explanation why
> this is needed to be convinced we should change what we have today.

Actually, I can think of a use for this, or something like it. If you
wanted to pre-publish keys in the parent, and the parent is checking
for the corresponding key in the child zone, then you can't do that
with the bits available in the protocol now. But if we had a way to
say, "Put this key in, but it's not active now," that would be a way
to pre-publish the DS without the corresponding DNSKEY in the child
zone, even if the parent had a policy to check the child zone (because
with the "not active" the parent could tell that the key just won't be
there).

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

--B_3347343881_5422626
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] Revision of 4310

Andrew,

I don’t understand why the client wouldn’t just add the DS when=
it becomes active to the server instead of pre-publishing and activating. &=
nbsp;Adding an active attribute adds a new model that could cause confusion =
for the clients interfacing with different servers and it doesn’t real=
ly add anything that can’t be handled today by the client.  Addin=
g another attribute that could change frequently like an active flag could p=
ose an issue of support with the secDNS:add, secDNS:rem, and secDNS:chg, whe=
re the only way to change the attribute is to use a secDNS:add and secDNS:re=
m of the same DS (or key), or use the secDNS:chg to replace all DS (or key) =
data.  I believe this interface is acceptable for the optional maxSigLi=
fe attribute, but would become onerous for a more frequently used attribute =
like an active flag.

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

From: Andrew Sullivan <[email-masked]>

Date: Tue, 26 Jan 2010 09:06:17 -0500

To: EPP Provreg <ietf-provreg@caf=
ax.se>

Subject: Re: [ietf-provreg] Revision of 4310

On Tue, Jan 26, 2010 at 06:56:24AM +0100, Patrik Fältström wrote:=

> I think it is much better the way it is now, that all DS the

> registry know about are active. To turn the active/not active flag

> on and off epp transactions are needed anyways, so the client can as
> well remove/add the keys instead.

> I.e. I do not see any need for the registry to keep track of

> active/not active keys, and need to get much more explanation why

> this is needed to be convinced we should change what we have today.

Actually, I can think of a use for this, or something like it.  If you=

wanted to pre-publish keys in the parent, and the parent is checking

for the corresponding key in the child zone, then you can't do that

with the bits available in the protocol now.  But if we had a way to
say, "Put this key in, but it's not active now," that would be a =
way

to pre-publish the DS without the corresponding DNSKEY in the child

zone, even if the parent had a policy to check the child zone (because

with the "not active" the parent could tell that the key just won=
't be

there).

A

--

Andrew Sullivan

[email-masked]

Shinkuro, Inc.

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=

List run by majordomo software.  For (Un-)subscription and similar det=
ails

send "help" to ietf-provr=
[email-masked]

--B_3347343881_5422626--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QEFBtP014626 for ; Tue, 26 Jan 2010 15:15:11 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QEFBpO012858 for ietf-provreg-outgoing; Tue, 26 Jan 2010 15:15:11 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QEFAqU014910 for ; Tue, 26 Jan 2010 15:15:11 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 5817F1ECC346 for ; Tue, 26 Jan 2010 14:15:10 +0000 (UTC)
Date: Tue, 26 Jan 2010 09:15:08 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Tue, Jan 26, 2010 at 09:01:47AM +0100, Ulrich Wisser wrote:
> Hi,
>
> in this case I have to agree with James. We discussed changing the URI
> and came to the conclusion that changing the URI will break old clients
> without any need to do so.

That argument is circular. What is up for debate is whether there is
in fact a need to do this.

> But let's have a look on the alternatives:
>
> 1. Server supports only the "old" 1.0
> - no changes on client or server
> 2. Server supports only the "new" 1.0
> - only changes on the server side needed
> 3. Server supports both
> - only changes on the server side needed

But in (2) and (3), the client _can't tell_ what support is in the
server. The whole point of the handshake in the protocol is to make
it possible for people to tell.

> Which registry is going to support 1.0 after 1.1 has been released for
> any time longer then needed?

Who knows? This is the Internet. We have parts of the DNS
infrastructure (including several MSFT APIs) that don't support the
DNS Unknown type, even though that was specified over 10 years ago and
is terribly useful.

> Another question comes to mind: Why should 1.1 be backwards compatible?
> If we break the URI there is no need to keep the broken , is it?

Right.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QE6OCp002640 for ; Tue, 26 Jan 2010 15:06:24 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QE6OwO023773 for ietf-provreg-outgoing; Tue, 26 Jan 2010 15:06:24 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QE6NFt029371 for ; Tue, 26 Jan 2010 15:06:23 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 5E4241ECC346 for ; Tue, 26 Jan 2010 14:06:22 +0000 (UTC)
Date: Tue, 26 Jan 2010 09:06:17 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] Revision of 4310
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <[email-masked]>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Tue, Jan 26, 2010 at 06:56:24AM +0100, Patrik FÃ¤ltstrÃ¶m wrote:

> I think it is much better the way it is now, that all DS the
> registry know about are active. To turn the active/not active flag
> on and off epp transactions are needed anyways, so the client can as
> well remove/add the keys instead.
>
> I.e. I do not see any need for the registry to keep track of
> active/not active keys, and need to get much more explanation why
> this is needed to be convinced we should change what we have today.

Actually, I can think of a use for this, or something like it. If you
wanted to pre-publish keys in the parent, and the parent is checking
for the corresponding key in the child zone, then you can't do that
with the bits available in the protocol now. But if we had a way to
say, "Put this key in, but it's not active now," that would be a way
to pre-publish the DS without the corresponding DNSKEY in the child
zone, even if the parent had a policy to check the child zone (because
with the "not active" the parent could tell that the key just won't be
there).

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QBt22v008573 for ; Tue, 26 Jan 2010 12:55:02 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0QBt2BK012159 for ietf-provreg-outgoing; Tue, 26 Jan 2010 12:55:02 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0QBsx3P029971; Tue, 26 Jan 2010 12:54:59 +0100 (MET)
DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:Subject:To: X-Mailer:Message-ID:From:Date:X-MIMETrack:MIME-Version: Content-type; b=XrgG+vDMAI7rQnksWxWuLAWyAAXjWEdcjL6t05yJwzXeppk/DTypQQdX whzYqYxIDWGmb423yttda3M1In4id7xUxiLdSDV2nlsmtqJAcbttpDn6a 9ZYB9KsGWldYsH1;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=[email-masked]; q=dns/txt; s=main.dkim.nominet.selector; t=1264506899; x=1296042899; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=[email-masked]|Subject:=20Re:=20[i etf-provreg]=20XML=20Schema=20versioning=20in=204310bis |Date:=20Tue,=2026=20Jan=202010=2011:54:57=20+0000 |Message-ID:=20|To:=20EPP=20Provreg=20,=0D=0A=[email-masked] e|MIME-Version:=201.0|In-Reply-To:=20<4B5EA16B.9090402@pu blisher.de>|References:=20=20<[email-masked]>; bh=5/TMf0M3AoYz2/tryt/pvX87GwcVkWfMJofbYpZ9ar0=; b=3UuHoVMP8k7Yt75aSLH2XWWicrkOq6UOx0aJQSsh3UI5kKLSgyvDb2Hx JnUOz/MIxzQfDKvTQ0Bdpsvu2RcLhGEkKZUfHYgzmGXJyoiISZmUk4zxS n5TcphXYw9UWosV;
X-IronPort-AV: E=Sophos;i="4.49,346,1262563200"; d="scan'208";a="15805400"
Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 26 Jan 2010 11:54:58 +0000
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis
To: EPP Provreg , [email-masked]
X-Mailer: Lotus Notes Release 8.0.1 February 07, 2008
Message-ID:
From: [email-masked]
Date: Tue, 26 Jan 2010 11:54:57 +0000
X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 26/01/2010 11:54:58 AM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: [email-masked]
Precedence: bulk

> Ulrich Wisser wrote on 26/01/2010 08:01:47:
> Re: [ietf-provreg] XML Schema versioning in 4310bis
>
> in this case I have to agree with James. We discussed changing the URI
> and came to the conclusion that changing the URI will break old clients
> without any need to do so.
>
> But let's have a look on the alternatives:
>
> 1. Server supports only the "old" 1.0
> - no changes on client or server
> 2. Server supports only the "new" 1.0
> - only changes on the server side needed
> 3. Server supports both
> - only changes on the server side needed

That's OK for the server, but thinking about it from the client's point of
view: How does a client know whether it should use the "old" or "new"
format?
Having the server advertise the protocol version in the makes it
possible to write a client that can handle both.

Anthony Kirby

--
Nominet UK - http://www.nominet.org.uk

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0Q81qId022964 for ; Tue, 26 Jan 2010 09:01:52 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0Q81q9A026255 for ietf-provreg-outgoing; Tue, 26 Jan 2010 09:01:52 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from lvps87-230-32-221.dedicated.hosteurope.de (mail.publisher.de [87.230.32.221]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0Q81paX011423 for ; Tue, 26 Jan 2010 09:01:51 +0100 (MET)
Received: (qmail 3891 invoked from network); 26 Jan 2010 08:01:51 +0000
Received: from gw.iis.se (HELO ulrich-wissers-macbook-pro.local) (212.247.14.38) by mail.publisher.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Jan 2010 08:01:51 +0000
Message-ID: <[email-masked]>
Date: Tue, 26 Jan 2010 09:01:47 +0100
From: Ulrich Wisser
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: EPP Provreg
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis
References:
In-Reply-To:
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

Hi,

in this case I have to agree with James. We discussed changing the URI
and came to the conclusion that changing the URI will break old clients
without any need to do so.

But let's have a look on the alternatives:

1. Server supports only the "old" 1.0
- no changes on client or server
2. Server supports only the "new" 1.0
- only changes on the server side needed
3. Server supports both
- only changes on the server side needed

If we change to 1.1:
1. Server supports only 1.0
- client needs to support 1.0 and 1.1 dependingon the registry
2. Server supports only 1.1
- client needs to support 1.0 and 1.1 dependingon the registry
3. Server supports 1.0 and 1.1
- only changes on server side needed

Which registry is going to support 1.0 after 1.1 has been released for
any time longer then needed? Changing the URI will generate the need to
update clients.

Another question comes to mind: Why should 1.1 be backwards compatible?
If we break the URI there is no need to keep the broken , is it?

But maybe we could take another approach? We define a new 1.0 backward
compatible and a new 1.1 not backward compatible. If the registry will
not support the old syntax it could choose to advertise 1.1 if the
registry stays backward compatible but gradually wants to move to the
new syntax it will advertise the new 1.0. Could that be a solution?

/Ulrich
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0Q5uYHU005036 for ; Tue, 26 Jan 2010 06:56:34 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0Q5uY6r017495 for ietf-provreg-outgoing; Tue, 26 Jan 2010 06:56:34 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0Q5uWng028494 for ; Tue, 26 Jan 2010 06:56:33 +0100 (MET)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjYFAEETXkurRN+J/2dsb2JhbACBRpkdgQymTYlcCY0agiQQFYFwBI4L
X-IronPort-AV: E=Sophos;i="4.49,344,1262563200"; d="scan'208";a="79023676"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 26 Jan 2010 05:56:31 +0000
Received: from 109.58.29.120.bredband.tre.se (rtp-vpn3-1245.cisco.com [10.82.220.226]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o0Q5uPNL007115; Tue, 26 Jan 2010 05:56:27 GMT
Subject: Re: [ietf-provreg] Revision of 4310
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=
In-Reply-To:
Date: Tue, 26 Jan 2010 06:56:24 +0100
Cc: Eduardo Duarte , EPP Provreg , "'WG-DNS'"
Message-Id: <[email-masked]>
References:
To: James Gould
X-Mailer: Apple Mail (2.1077)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o0Q5uXng027724
Sender: [email-masked]
Precedence: bulk

I think it is much better the way it is now, that all DS the registry know about are active. To turn the active/not active flag on and off epp transactions are needed anyways, so the client can as well remove/add the keys instead.

I.e. I do not see any need for the registry to keep track of active/not active keys, and need to get much more explanation why this is needed to be convinced we should change what we have today.

Patrik

On 26 jan 2010, at 00.03, James Gould wrote:

> Eduardo,
>
> I don't believe this was discussed, but what is the expected behavior of the
> server? Is the use case that the clients would pre-publish the DS as active
> / inactive to the server, and the server would in turn only publish the
> active DS data? The current draft has the server publish all passed DS
> information, so the client would add / remove DS data instead of
> pre-publishing and activating / deactivating them. Now all records are
> considered active. Adding an additional attribute would be somewhat
> challenging, since it would require the client to add and remove the same
> DS, but with the activity flag set to a different value on the add. This is
> a corner case that came up with changing the maxSigLife.
>
> --
>
>
> JG
>
> -------------------------------------------------------
> James F. Gould
> Principal Software Engineer
> VeriSign Naming Services
> [email-masked]
> Direct: 703.948.3271
> Mobile: 703.628.7063
>
>
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>
> Notice to Recipient: This e-mail contains confidential, proprietary and/or
> Registry Sensitive information intended solely for the recipient and, thus
> may not be retransmitted, reproduced or disclosed without the prior written
> consent of VeriSign Naming and Directory Services. If you have received
> this e-mail message in error, please notify the sender immediately by
> telephone or reply e-mail and destroy the original message without making a
> copy. Thank you.
>
>
>> From: Eduardo Duarte
>> Date: Mon, 25 Jan 2010 14:56:53 +0000
>> To: EPP Provreg
>> Cc: 'WG-DNS'
>> Subject: [ietf-provreg] Revision of 4310
>>
>> Hello,
>>
>> I work for the .PT ccTLD and I'm starting to add the DNSSEC extension
>> under our EPP implementation.
>> For doing this I'm following the the new revision of the 4310 RFC and I
>> was wondering something after reading it...
>>
>> On our implementation of DNSSEC a domain can have multiple DS keys
>> associated were some are active and other are in an inactive state.
>> On the secDNS.xsd I didn't see any way to have multiple keys send in the
>> info command and have a way to show if they are active or not.
>>
>> Was this matter discuss on the list already!?
>>
>> If no can I propose a small change in XSD (I know that is probably to
>> late for that....). My suggestion is to add a Active/Non-Active field on
>> the DSdataType so the definition changes to the following:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Thanks and best regards,
>>
>> Eduardo Duarte
>>
>>
>>
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>> List run by majordomo software. For (Un-)subscription and similar details
>> send "help" to [email-masked]
>>
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> List run by majordomo software. For (Un-)subscription and similar details
> send "help" to [email-masked]
>

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PN3lX1014703 for ; Tue, 26 Jan 2010 00:03:47 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0PN3llu009976 for ietf-provreg-outgoing; Tue, 26 Jan 2010 00:03:47 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PN3k0g013818 for ; Tue, 26 Jan 2010 00:03:47 +0100 (MET)
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o0PMwqMG032216; Mon, 25 Jan 2010 17:58:53 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 18:03:45 -0500
Received: from 10.169.80.17 ([10.169.80.17]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Mon, 25 Jan 2010 23:03:45 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Mon, 25 Jan 2010 18:03:42 -0500
Subject: Re: [ietf-provreg] Revision of 4310
From: James Gould
To: Eduardo Duarte , EPP Provreg
CC: "'WG-DNS'"
Message-ID:
Thread-Topic: [ietf-provreg] Revision of 4310
Thread-Index: AcqeEqNPoVgDLE2IyE6DzAC4GwJ7wg==
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 25 Jan 2010 23:03:45.0904 (UTC) FILETIME=[A5A38F00:01CA9E12]
Sender: [email-masked]
Precedence: bulk

Eduardo,

I don't believe this was discussed, but what is the expected behavior of the
server? Is the use case that the clients would pre-publish the DS as active
/ inactive to the server, and the server would in turn only publish the
active DS data? The current draft has the server publish all passed DS
information, so the client would add / remove DS data instead of
pre-publishing and activating / deactivating them. Now all records are
considered active. Adding an additional attribute would be somewhat
challenging, since it would require the client to add and remove the same
DS, but with the activity flag set to a different value on the add. This is
a corner case that came up with changing the maxSigLife.

--

JG

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior written
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

> From: Eduardo Duarte
> Date: Mon, 25 Jan 2010 14:56:53 +0000
> To: EPP Provreg
> Cc: 'WG-DNS'
> Subject: [ietf-provreg] Revision of 4310
>
> Hello,
>
> I work for the .PT ccTLD and I'm starting to add the DNSSEC extension
> under our EPP implementation.
> For doing this I'm following the the new revision of the 4310 RFC and I
> was wondering something after reading it...
>
> On our implementation of DNSSEC a domain can have multiple DS keys
> associated were some are active and other are in an inactive state.
> On the secDNS.xsd I didn't see any way to have multiple keys send in the
> info command and have a way to show if they are active or not.
>
> Was this matter discuss on the list already!?
>
> If no can I propose a small change in XSD (I know that is probably to
> late for that....). My suggestion is to add a Active/Non-Active field on
> the DSdataType so the definition changes to the following:
>
>
>
>
>
>
>
>
>
>
>
>
> Thanks and best regards,
>
> Eduardo Duarte
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> List run by majordomo software. For (Un-)subscription and similar details
> send "help" to [email-masked]
>

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PMp80n024938 for ; Mon, 25 Jan 2010 23:51:08 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0PMp8rQ027842 for ietf-provreg-outgoing; Mon, 25 Jan 2010 23:51:08 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PMp6x7017370 for ; Mon, 25 Jan 2010 23:51:07 +0100 (MET)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o0PMkCF1031738; Mon, 25 Jan 2010 17:46:12 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 17:51:05 -0500
Received: from 10.169.80.17 ([10.169.80.17]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Mon, 25 Jan 2010 22:51:05 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Mon, 25 Jan 2010 17:51:02 -0500
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis
From: James Gould
To: Bernie Hoeneisen
CC: EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] XML Schema versioning in 4310bis
Thread-Index: AcqeAiSt4WqjWSunTOeKZPPSGlo2bAADrmkA
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3347286662_2217274"
X-OriginalArrivalTime: 25 Jan 2010 22:51:05.0726 (UTC) FILETIME=[E08999E0:01CA9E10]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3347286662_2217274
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Bernie,

> Sorry, but in this case you can not declare it "consensus", as there was
> not even a sufficient public disussion to reach a consensus.

Maybe the word =B3consensus=B2 from a WG perspective is not correct, but based
on the work done on this list for the past few months I believe I can fairl=
y
claim that no one on the list had a major concern using the existing URI an=
d
maintaining backward compatibility. Andrew looks like he now has a
different view and sees this as a =B3serious problem=B2, which was not
previously expressed on the list or in private messages. Scott Hollenbeck
was the one that brought the potential need to change the URI to my
attention, and that=B9s when I went to the AD to find out what the options
are. The AD said that the same URI can be used as long as the schema is
backward compatible. That is when I sent the message out to the list with
the goals along with the results of my communication with the AD. There is
no way for me to define =B3consensus=B2 from a mailing list, but I have done th=
e
best I can with an individual submission.

> I don't think the burden should be on the clients. Servers will have to
> implement both versions during a transition period, and Clients will
> gradually upgrade to the new version.
=20
The burden is certainly going to be on the clients, who will most likely
have to use different implementations across different servers. The server=
s
don=B9t have to implement both versions and most likely will not. We will
most likely look to implement one version of the extension, which would be
1.1. Clients can=B9t gradually incorporate the new features of the new draft
since the new URI is a syntax change and is therefore not backward
compatible. =20

> I don't think that it is a good idea to make a standard that expects such
> a behavior. Servers and clients might run into (unexpected) error cases,
> which are difficult to catch due to ambiguity in the standards, which is
> to be avoided

I don=B9t believe that there is much ambiguity in this case. The new draft i=
s
additive to RFC 4310, so the only confusion is the ability to do more with
the new draft. A server can support the old model and the new model withou=
t
the URI change, since the new draft supports the old syntax.

> Another thought: Have you considered to make a complete new XML Schema fo=
r
> the new functionality, leaving the existing XML Schema untouched?
> [Note: I have not studied in detail whether or not such an approach is
> at all feasible.]

No, the changes are cross cutting and would not work in a separate XML
schema. =20

My goal in this effort was to address the main issues with RFC 4310, while
having the least amount of impact to existing implementations, and
maximizing the adoption of DNSSEC by supporting new usability features.
Creating a different URI for the new draft is not a large effort on my part=
,
but I believe is fundamentally against the goals of the work.

--=20

JG=20

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

=20
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior writte=
n
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

From: Bernie Hoeneisen
Date: Mon, 25 Jan 2010 16:05:30 -0500
To: James Gould
Cc: EPP Provreg
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis

Hi James

On Mon, 25 Jan 2010, James Gould wrote:

> I had multiple private messages associated with this, but on the list
> the only message that directly references is from me on December 8th:
>
> http://www.cafax.se/ietf-provreg/maillist/2009-12/msg00000.html

Thanks for the pointer.

Sorry, but in this case you can not declare it "consensus", as there was
not even a sufficient public disussion to reach a consensus.

> The other indirect item is the goal of =B3XML schema is backward
> compatible=B2, which is included in multiple messages on the list. =A0

Well, I'd say many people are just not aware of this work going on. e.g. I
only spotted it accidently today, which leads to the other discussion
about making EPP work in the IETF official...

> Changing the URI (version number) would break this goal, since clients
> would be required to upgrade their clients to use the new URI, assuming
> that a server only supports the new draft. =A0The servers could support
> two URI=B9s, which is technically feasible but not simple. =A0

I don't think the burden should be on the clients. Servers will have to
implement both versions during a transition period, and Clients will
gradually upgrade to the new version.

> > What are the disadvantages if the XML schema version number was changed=
to
> > urn:ietf:params:xml:ns:secDNS-1.1 ?
>
> 1. Clients that support 1.0 would be required to upgrade to 1.1 for serv=
ers
that support 1.1. =A0Backward
> compatibility does not provide a huge benefit if the URI changes. =A0Cl=
ient
EPP SDK=B9s need to be
> upgraded to support this, where if backward compatibility is maintain=
ed
the clients don=B9t need to do
> anything.

If servers are implementing both versions, clients do not need to
implement both versions during a transition period. If you keep the schema
backward compatible (as you intend to), there is little complexity added
to the server.

> 2. Servers might have to support more then one version at a time to migr=
ate
users to the new draft. =A0I
> don=B9t know of any servers supporting multiple versions of anything no=
w, so
adding this requirement
> for a backward compatible scheme seems kind of overkill.

Well, I implemented such a scenario with two XML schema versions on a
productive EPP server with extension RFC 5076, which had a change in the
XML schema during the standardization process. It worked just fine.

> I don=B9t see a huge advantage of changing the URI, other then clarity in
> the EPP greeting. =A0Clients can start exercising the new features of the
> new draft when the servers supports it as an option instead of as a
> requirement. =A0

I don't think that it is a good idea to make a standard that expects such
a behavior. Servers and clients might run into (unexpected) error cases,
which are difficult to catch due to ambiguity in the standards, which is
to be avoided

Another thought: Have you considered to make a complete new XML Schema for
the new functionality, leaving the existing XML Schema untouched?
[Note: I have not studied in detail whether or not such an approach is
at all feasible.]

cheers,
Bernie

--B_3347286662_2217274
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] XML Schema versioning in 4310bis

Bernie,

> Sorry, but in this case you can not declare it "consensus", =
as there was

> not even a sufficient public disussion to reach a consensus.

Maybe the word “consensus” from a WG perspective is not correct=
, but based on the work done on this list for the past few months I believe =
I can fairly claim that no one on the list had a major concern using the exi=
sting URI and maintaining backward compatibility.  Andrew looks like he=
now has a different view and sees this as a “serious problem”, =
which was not previously expressed on the list or in private messages.  =
;Scott Hollenbeck was the one that brought the potential need to change the =
URI to my attention, and that’s when I went to the AD to find out what=
the options are.  The AD said that the same URI can be used as long as=
the schema is backward compatible. That is when I sent the message out to t=
he list with the goals along with the results of my communication with the A=
D.  There is no way for me to define “consensus” from a mai=
ling list, but I have done the best I can with an individual submission. &nb=
sp;

> I don't think the burden should be on the clients. Servers will have t=
o

> implement both versions during a transition period, and Clients will
> gradually upgrade to the new version.

The burden is certainly going to be on the clients, who will most likely ha=
ve to use different implementations across different servers.  The serv=
ers don’t have to implement both versions and most likely will not. &n=
bsp;We will most likely look to implement one version of the extension, whic=
h would be 1.1.  Clients can’t gradually incorporate the new feat=
ures of the new draft since the new URI is a syntax change and is therefore =
not backward compatible.

> I don't think that it is a good idea to make a standard that expects s=
uch

> a behavior. Servers and clients might run into (unexpected) error case=
s,

> which are difficult to catch due to ambiguity in the standards, which =
is

> to be avoided

I don’t believe that there is much ambiguity in this case.  The =
new draft is additive to RFC 4310, so the only confusion is the ability to d=
o more with the new draft.  A server can support the old model and the =
new model without the URI change, since the new draft supports the old synta=
x.

> Another thought: Have you considered to make a complete new XML Schema=
for

> the new functionality, leaving the existing XML Schema untouched?

> [Note: I have not studied in detail whether or not such an approach is=

> at all feasible.]

No, the changes are cross cutting and would not work in a separate XML sche=
ma.

My goal in this effort was to address the main issues with RFC 4310, while =
having the least amount of impact to existing implementations, and maximizin=
g the adoption of DNSSEC by supporting new usability features.  Creatin=
g a different URI for the new draft is not a large effort on my part, but I =
believe is fundamentally against the goals of the work.

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

From: Bernie Hoeneisen <[email-masked]>

Date: Mon, 25 Jan 2010 16:05:30 -0500

To: James Gould <[email-masked]=
m>

Cc: EPP Provreg <ietf-provreg@caf=
ax.se>

Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis

Hi James

On Mon, 25 Jan 2010, James Gould wrote:

> I had multiple private messages associated with this, but on the list<=
BR>
> the only message that directly references is from me on December 8th:<=
BR>

> http://www.cafax.se/ietf-provreg/maillist/2009-12/msg00000.html

Thanks for the pointer.

Sorry, but in this case you can not declare it "consensus", as th=
ere was

not even a sufficient public disussion to reach a consensus.

> The other indirect item is the goal of “XML schema is backward
> compatible”, which is included in multiple messages on the list.=
=A0

Well, I'd say many people are just not aware of this work going on. e.g. I<=
BR>
only spotted it accidently today, which leads to the other discussion

about making EPP work in the IETF official...

> Changing the URI (version number) would break this goal, since clients=

> would be required to upgrade their clients to use the new URI, assumin=
g

> that a server only supports the new draft. =A0The servers could support<=
BR>
> two URI’s, which is technically feasible but not simple. =A0

I don't think the burden should be on the clients. Servers will have to

implement both versions during a transition period, and Clients will

gradually upgrade to the new version.

> > What are the disadvantages if the XML schema version number was c=
hanged to

> > urn:ietf:params:xml:ns:secDNS-1.1 ?

>  1. Clients that support 1.0 would be required to upgrade to 1.1 =
for servers that support 1.1. =A0Backward

>     compatibility does not provide a huge benefit =
if the URI changes. =A0Client EPP SDK’s need to be

>     upgraded to support this, where if backward co=
mpatibility is maintained the clients don’t need to do

>     anything.

If servers are implementing both versions, clients do not need to

implement both versions during a transition period. If you keep the schema<=
BR>
backward compatible (as you intend to), there is little complexity added
to the server.

>  2. Servers might have to support more then one version at a time=
to migrate users to the new draft. =A0I

>     don’t know of any servers supporting mul=
tiple versions of anything now, so adding this requirement

>     for a backward compatible scheme seems kind of=
overkill.

Well, I implemented such a scenario with two XML schema versions on a

productive EPP server with extension RFC 5076, which had a change in the
XML schema during the standardization process. It worked just fine.

> I don’t see a huge advantage of changing the URI, other then cla=
rity in

> the EPP greeting. =A0Clients can start exercising the new features of th=
e

> new draft when the servers supports it as an option instead of as a
> requirement. =A0

I don't think that it is a good idea to make a standard that expects such
a behavior. Servers and clients might run into (unexpected) error cases,
which are difficult to catch due to ambiguity in the standards, which is
to be avoided

Another thought: Have you considered to make a complete new XML Schema for<=
BR>
the new functionality, leaving the existing XML Schema untouched?

[Note: I have not studied in detail whether or not such an approach is

at all feasible.]

cheers,

Bernie

--B_3347286662_2217274--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PL5YwI026839 for ; Mon, 25 Jan 2010 22:05:34 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0PL5YBe027291 for ietf-provreg-outgoing; Mon, 25 Jan 2010 22:05:34 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PL5Y82010327 for ; Mon, 25 Jan 2010 22:05:34 +0100 (MET)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NZW7m-0007F4-OI; Mon, 25 Jan 2010 22:05:30 +0100
Date: Mon, 25 Jan 2010 22:05:30 +0100 (CET)
From: Bernie Hoeneisen
X-X-Sender: [email-masked]
To: James Gould
cc: EPP Provreg
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis
In-Reply-To:
Message-ID:
References:
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="37663318-672621210-1264453530=:27647"
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: [email-masked]
X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false
Sender: [email-masked]
Precedence: bulk

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--37663318-672621210-1264453530=:27647
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi James

On Mon, 25 Jan 2010, James Gould wrote:

> I had multiple private messages associated with this, but on the list=20
> the only message that directly references is from me on December 8th:
>=20
> http://www.cafax.se/ietf-provreg/maillist/2009-12/msg00000.html

Thanks for the pointer.

Sorry, but in this case you can not declare it "consensus", as there was=20
not even a sufficient public disussion to reach a consensus.

> The other indirect item is the goal of =E2=80=9CXML schema is backward=20
> compatible=E2=80=9D, which is included in multiple messages on the list. =
=C2=A0

Well, I'd say many people are just not aware of this work going on. e.g. I=
=20
only spotted it accidently today, which leads to the other discussion=20
about making EPP work in the IETF official...

> Changing the URI (version number) would break this goal, since clients=20
> would be required to upgrade their clients to use the new URI, assuming=
=20
> that a server only supports the new draft. =C2=A0The servers could suppor=
t=20
> two URI=E2=80=99s, which is technically feasible but not simple. =C2=A0

I don't think the burden should be on the clients. Servers will have to=20
implement both versions during a transition period, and Clients will=20
gradually upgrade to the new version.

> > What are the disadvantages if the XML schema version number was changed=
to
> > urn:ietf:params:xml:ns:secDNS-1.1 ?
>
> 1. Clients that support 1.0 would be required to upgrade to 1.1 for serv=
ers that support 1.1. =C2=A0Backward
> compatibility does not provide a huge benefit if the URI changes. =C2=
=A0Client EPP SDK=E2=80=99s need to be
> upgraded to support this, where if backward compatibility is maintain=
ed the clients don=E2=80=99t need to do
> anything.

If servers are implementing both versions, clients do not need to=20
implement both versions during a transition period. If you keep the schema=
=20
backward compatible (as you intend to), there is little complexity added=20
to the server.

> 2. Servers might have to support more then one version at a time to migr=
ate users to the new draft. =C2=A0I
> don=E2=80=99t know of any servers supporting multiple versions of any=
thing now, so adding this requirement
> for a backward compatible scheme seems kind of overkill.

Well, I implemented such a scenario with two XML schema versions on a
productive EPP server with extension RFC 5076, which had a change in the=20
XML schema during the standardization process. It worked just fine.

> I don=E2=80=99t see a huge advantage of changing the URI, other then clar=
ity in=20
> the EPP greeting. =C2=A0Clients can start exercising the new features of =
the=20
> new draft when the servers supports it as an option instead of as a=20
> requirement. =C2=A0

I don't think that it is a good idea to make a standard that expects such=
=20
a behavior. Servers and clients might run into (unexpected) error cases,=20
which are difficult to catch due to ambiguity in the standards, which is=20
to be avoided

Another thought: Have you considered to make a complete new XML Schema for=
=20
the new functionality, leaving the existing XML Schema untouched?
[Note: I have not studied in detail whether or not such an approach is=20
at all feasible.]

cheers,
Bernie

--37663318-672621210-1264453530=:27647--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PK5q6X021586 for ; Mon, 25 Jan 2010 21:05:52 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0PK5qDV022274 for ietf-provreg-outgoing; Mon, 25 Jan 2010 21:05:52 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PK5pvx003751 for ; Mon, 25 Jan 2010 21:05:51 +0100 (MET)
Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o0PJl31j010989; Mon, 25 Jan 2010 14:47:03 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 15:05:50 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Mon, 25 Jan 2010 20:05:49 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Mon, 25 Jan 2010 15:05:46 -0500
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis
From: James Gould
To: Bernie Hoeneisen
CC: EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] XML Schema versioning in 4310bis
Thread-Index: Acqd8G2vpdkeqiwiQuS/hHYQ5F9BzwACVo9W
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3347276747_2063863"
X-OriginalArrivalTime: 25 Jan 2010 20:05:50.0453 (UTC) FILETIME=[CA930250:01CA9DF9]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3347276747_2063863
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Bernie,

I had multiple private messages associated with this, but on the list the
only message that directly references is from me on December 8th:

http://www.cafax.se/ietf-provreg/maillist/2009-12/msg00000.html

The other indirect item is the goal of =B3XML schema is backward compatible=B2,
which is included in multiple messages on the list. Changing the URI
(version number) would break this goal, since clients would be required to
upgrade their clients to use the new URI, assuming that a server only
supports the new draft. The servers could support two URI=B9s, which is
technically feasible but not simple.

There were also four versions of the draft created and sent out to the list
that did not change the URI (version number), with no negative feedback.

> What are the disadvantages if the XML schema version number was changed t=
o
> urn:ietf:params:xml:ns:secDNS-1.1 ?

1. Clients that support 1.0 would be required to upgrade to 1.1 for servers
that support 1.1. Backward compatibility does not provide a huge benefit i=
f
the URI changes. Client EPP SDK=B9s need to be upgraded to support this,
where if backward compatibility is maintained the clients don=B9t need to do
anything.=20
2. Servers might have to support more then one version at a time to migrate
users to the new draft. I don=B9t know of any servers supporting multiple
versions of anything now, so adding this requirement for a backward
compatible scheme seems kind of overkill.

I don=B9t see a huge advantage of changing the URI, other then clarity in the
EPP greeting. Clients can start exercising the new features of the new
draft when the servers supports it as an option instead of as a requirement=
.

--=20

JG=20

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

=20
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior writte=
n
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

From: Bernie Hoeneisen
Date: Mon, 25 Jan 2010 13:58:42 -0500
To: James Gould
Cc: EPP Provreg
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis

Hi James

Thanks for this information.

Could you please send me the pointers to the archive where this has been
discussed? I was unable to locate the relevant posts concerning this
discussion.

I still believe this is a bad idea from implementors point of view. The
EPP client needs the means to discover the capabilities of the EPP Server
which in EPP is done with the hello command and xml schema (incl. version
number) in the response.

What are the disadvantages if the XML schema version number was changed to
urn:ietf:params:xml:ns:secDNS-1.1 ?

cheers,
Bernie

On Mon, 25 Jan 2010, James Gould wrote:

> Bernie,
>
> We have considered this in prior discussions on the list. =A0The consensus =
was
to keep backward
> compatibility by keeping the version number the same. =A0The updated draft =
is
additive to the original
> RFC, so according to the AD this was an acceptable approach. =A0
>
> --
>
>
> JG
>
> -------------------------------------------------------
> James F. Gould
> Principal Software Engineer
> VeriSign Naming Services
> [email-masked]
> Direct: 703.948.3271
> Mobile: 703.628.7063
>
> =A0
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>
> Notice to Recipient: =A0This e-mail contains confidential, proprietary and/=
or
Registry =A0Sensitive
> information intended solely for the recipient and, thus may not be
=A0retransmitted, reproduced or
> disclosed without the prior written consent of =A0VeriSign Naming and Direc=
tory
Services. =A0If you have
> received =A0this e-mail message in error, please notify the sender immediat=
ely
by =A0telephone or reply
> e-mail and destroy the original message without making a =A0copy. =A0Thank yo=
u.
> =20
___________________________________________________________________________=
_____
_________________
> From: Bernie Hoeneisen
> Date: Mon, 25 Jan 2010 11:09:12 -0500
> To: EPP Provreg
> Subject: [ietf-provreg] XML Schema versioning in 4310bis
>
> Hi
>
> As already pointed out to the authors of draft-gould-rfc4310bis, I see an
> issue with the version numbering of the XML Schema. Although rfc4310bis
> changes the XML schema defined in RFC 4310, it intends to reuse the
> version number.
>
> >From implementor point of view this is a very bad idea. It leads to
> confusion and inconsistencies, in particular in the transition phasis. Ho=
w
> should an EPP Client figure out the capabilities of the EPP Server? The
> repsonse to hello won't be useful to distiguish which schema applies.
>
> I run into a similar problem while implementing RFC 5076. As there was a
> change in the schema during the standardization process, I even needed to
> distinguish between early I-D implementions and the final version of the
> XML schema. I solved it by incrementing the sub-version of the XML schema=
.
> See: http://tools.ietf.org/html/rfc5076#section-7
>
> Therefore I strongly recommend to increment the (sub-)version number of
> the XML Schema for 4310bis to 1.1
>
> During transition period, the server can announce both versions and the
> client knows what it is up to.
>
> cheers,
> =A0=A0Bernie
> -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
=3D-
> List run by majordomo software. =A0For (Un-)subscription and similar detail=
s
> send "help" to [email-masked]
>
>
>
>

--B_3347276747_2063863
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] XML Schema versioning in 4310bis

Bernie,

I had multiple private messages associated with this, but on the list the o=
nly message that directly references is from me on December 8th:

h=
ttp://www.cafax.se/ietf-provreg/maillist/2009-12/msg00000.html

The other indirect item is the goal of “XML schema is backward compat=
ible”, which is included in multiple messages on the list.  Chang=
ing the URI (version number) would break this goal, since clients would be r=
equired to upgrade their clients to use the new URI, assuming that a server =
only supports the new draft.  The servers could support two URI’s=
, which is technically feasible but not simple.

There were also four versions of the draft created and sent out to the list=
that did not change the URI (version number), with no negative feedback.

> What are the disadvantages if the XML schema version number was change=
d to

> urn:ietf:params:xml:ns:secDNS-1.1 ?

Clients that support 1.0 would be required to upgrad=
e to 1.1 for servers that support 1.1.  Backward compatibility does not=
provide a huge benefit if the URI changes.  Client EPP SDK’s nee=
d to be upgraded to support this, where if backward compatibility is maintai=
ned the clients don’t need to do anything.

Servers might have to support more then one version at a=
time to migrate users to the new draft.  I don’t know of any ser=
vers supporting multiple versions of anything now, so adding this requiremen=
t for a backward compatible scheme seems kind of overkill.

I don’t see a huge advantage of changing the URI, other then clarity =
in the EPP greeting.  Clients can start exercising the new features of =
the new draft when the servers supports it as an option instead of as a requ=
irement.

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

From: Bernie Hoeneisen <[email-masked]>

Date: Mon, 25 Jan 2010 13:58:42 -0500

To: James Gould <[email-masked]=
m>

Cc: EPP Provreg <ietf-provreg@caf=
ax.se>

Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis

Hi James

Thanks for this information.

Could you please send me the pointers to the archive where this has been
discussed? I was unable to locate the relevant posts concerning this

discussion.

I still believe this is a bad idea from implementors point of view. The

EPP client needs the means to discover the capabilities of the EPP Server
which in EPP is done with the hello command and xml schema (incl. version
number) in the response.

What are the disadvantages if the XML schema version number was changed to<=
BR>
urn:ietf:params:xml:ns:secDNS-1.1 ?

cheers,

Bernie

On Mon, 25 Jan 2010, James Gould wrote:

> Bernie,

> We have considered this in prior discussions on the list. =A0The consens=
us was to keep backward

> compatibility by keeping the version number the same. =A0The updated dra=
ft is additive to the original

> RFC, so according to the AD this was an acceptable approach. =A0

> --

> JG

> -------------------------------------------------------

> James F. Gould

> Principal Software Engineer

> VeriSign Naming Services

> [email-masked]

> Direct: 703.948.3271

> Mobile: 703.628.7063

> =A0

> 21345 Ridgetop Circle

> LS2-2-1

> Dulles, VA 20166

> Notice to Recipient: =A0This e-mail contains confidential, proprietary a=
nd/or Registry =A0Sensitive

> information intended solely for the recipient and, thus may not be =A0re=
transmitted, reproduced or

> disclosed without the prior written consent of =A0VeriSign Naming and Di=
rectory Services. =A0If you have

> received =A0this e-mail message in error, please notify the sender immed=
iately by =A0telephone or reply

> e-mail and destroy the original message without making a =A0copy. =A0Thank=
you.

>    ____________________________________________________=
_____________________________________________

> From: Bernie Hoeneisen <bernie@i=
etf.hoeneisen.ch>

> Date: Mon, 25 Jan 2010 11:09:12 -0500

> To: EPP Provreg <ietf-provreg@cafax=
.se>

> Subject: [ietf-provreg] XML Schema versioning in 4310bis

> Hi

> As already pointed out to the authors of draft-gould-rfc4310bis, I see=
an

> issue with the version numbering of the XML Schema. Although rfc4310bi=
s

> changes the XML schema defined in RFC 4310, it intends to reuse the
> version number.

> >From implementor point of view this is a very bad idea. It leads t=
o

> confusion and inconsistencies, in particular in the transition phasis.=
How

> should an EPP Client figure out the capabilities of the EPP Server? Th=
e

> repsonse to hello won't be useful to distiguish which schema applies.<=
BR>

> I run into a similar problem while implementing RFC 5076. As there was=
a

> change in the schema during the standardization process, I even needed=
to

> distinguish between early I-D implementions and the final version of t=
he

> XML schema. I solved it by incrementing the sub-version of the XML sch=
ema.

> See: http://too=
ls.ietf.org/html/rfc5076#section-7

> Therefore I strongly recommend to increment the (sub-)version number o=
f

> the XML Schema for 4310bis to 1.1

> During transition period, the server can announce both versions and th=
e

> client knows what it is up to.

> cheers,

> =A0=A0Bernie

> -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D-=3D-

> List run by majordomo software. =A0For (Un-)subscription and similar det=
ails

> send "help" to ietf-=
[email-masked]

--B_3347276747_2063863--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PIwj8P018855 for ; Mon, 25 Jan 2010 19:58:45 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0PIwjhD013290 for ietf-provreg-outgoing; Mon, 25 Jan 2010 19:58:45 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PIwiNm016126 for ; Mon, 25 Jan 2010 19:58:44 +0100 (MET)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NZU94-0006W7-5A; Mon, 25 Jan 2010 19:58:42 +0100
Date: Mon, 25 Jan 2010 19:58:42 +0100 (CET)
From: Bernie Hoeneisen
X-X-Sender: [email-masked]
To: James Gould
cc: EPP Provreg
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis
In-Reply-To:
Message-ID:
References:
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="37663318-371853050-1264445563=:16349"
Content-ID:
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: [email-masked]
X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false
Sender: [email-masked]
Precedence: bulk

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--37663318-371853050-1264445563=:16349
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; FORMAT=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID:

Hi James

Thanks for this information.

Could you please send me the pointers to the archive where this has been=20
discussed? I was unable to locate the relevant posts concerning this=20
discussion.

I still believe this is a bad idea from implementors point of view. The=20
EPP client needs the means to discover the capabilities of the EPP Server=
=20
which in EPP is done with the hello command and xml schema (incl. version=
=20
number) in the response.

What are the disadvantages if the XML schema version number was changed to=
=20
urn:ietf:params:xml:ns:secDNS-1.1 ?

cheers,
Bernie

On Mon, 25 Jan 2010, James Gould wrote:

> Bernie,
>=20
> We have considered this in prior discussions on the list. =A0The consensu=
s was to keep backward
> compatibility by keeping the version number the same. =A0The updated draf=
t is additive to the original
> RFC, so according to the AD this was an acceptable approach. =A0
>=20
> --
>=20
>=20
> JG
>=20
> -------------------------------------------------------
> James F. Gould
> Principal Software Engineer
> VeriSign Naming Services
> [email-masked]
> Direct: 703.948.3271
> Mobile: 703.628.7063
>=20
> =A0
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>=20
> Notice to Recipient: =A0This e-mail contains confidential, proprietary an=
d/or Registry =A0Sensitive
> information intended solely for the recipient and, thus may not be =A0ret=
ransmitted, reproduced or
> disclosed without the prior written consent of =A0VeriSign Naming and Dir=
ectory Services. =A0If you have
> received =A0this e-mail message in error, please notify the sender immedi=
ately by =A0telephone or reply
> e-mail and destroy the original message without making a =A0copy. =A0Than=
k you.
>=20
>
> ______________________________________________________________________=
___________________________
> From: Bernie Hoeneisen
> Date: Mon, 25 Jan 2010 11:09:12 -0500
> To: EPP Provreg
> Subject: [ietf-provreg] XML Schema versioning in 4310bis
>=20
> Hi
>=20
> As already pointed out to the authors of draft-gould-rfc4310bis, I see an
> issue with the version numbering of the XML Schema. Although rfc4310bis
> changes the XML schema defined in RFC 4310, it intends to reuse the
> version number.
>=20
> >From implementor point of view this is a very bad idea. It leads to
> confusion and inconsistencies, in particular in the transition phasis. Ho=
w
> should an EPP Client figure out the capabilities of the EPP Server? The
> repsonse to hello won't be useful to distiguish which schema applies.
>=20
> I run into a similar problem while implementing RFC 5076. As there was a
> change in the schema during the standardization process, I even needed to
> distinguish between early I-D implementions and the final version of the
> XML schema. I solved it by incrementing the sub-version of the XML schema=
=2E
> See: http://tools.ietf.org/html/rfc5076#section-7
>=20
> Therefore I strongly recommend to increment the (sub-)version number of
> the XML Schema for 4310bis to 1.1
>=20
> During transition period, the server can announce both versions and the
> client knows what it is up to.
>=20
> cheers,
> =A0=A0Bernie
> -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-
> List run by majordomo software. =A0For (Un-)subscription and similar deta=
ils
> send "help" to [email-masked]
>=20
>=20
>=20
>
--37663318-371853050-1264445563=:16349--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PIE72c029859 for ; Mon, 25 Jan 2010 19:14:07 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0PIE7ra011247 for ietf-provreg-outgoing; Mon, 25 Jan 2010 19:14:07 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PIE6F6018958 for ; Mon, 25 Jan 2010 19:14:06 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 814051ECC0C6 for ; Mon, 25 Jan 2010 18:14:05 +0000 (UTC)
Date: Mon, 25 Jan 2010 13:14:03 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References:
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Mon, Jan 25, 2010 at 12:29:40PM -0500, James Gould wrote:
> Bernie,
>
> We have considered this in prior discussions on the list. The consensus was
> to keep backward compatibility by keeping the version number the same. The
> updated draft is additive to the original RFC, so according to the AD this
> was an acceptable approach.

As a matter of procedure, I think it's important to be careful with
that word "consensus". There's no working group here, and no chair to
declare consensus. I'm not at all sure there was consensus: that was
my objection, too, but I said that as a party who didn't have to live
with the results I wouldn't press to hard on this issue. I still
think it's a serious problem: if we're not going to use the version
number to be the indicator of the version of the specification, what's
it for?

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PHTkK2006453 for ; Mon, 25 Jan 2010 18:29:46 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0PHTk0D004011 for ietf-provreg-outgoing; Mon, 25 Jan 2010 18:29:46 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PHTjNO024601 for ; Mon, 25 Jan 2010 18:29:45 +0100 (MET)
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o0PHAvCT003940; Mon, 25 Jan 2010 12:10:57 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 12:29:43 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Mon, 25 Jan 2010 17:29:41 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Mon, 25 Jan 2010 12:29:40 -0500
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis
From: James Gould
To: Bernie Hoeneisen , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] XML Schema versioning in 4310bis
Thread-Index: Acqd3IlyiDeROv9MSnqjmA0Zb04V+QAB2/kt
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3347267381_1502030"
X-OriginalArrivalTime: 25 Jan 2010 17:29:43.0877 (UTC) FILETIME=[FBA8EF50:01CA9DE3]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3347267381_1502030
Content-type: text/plain;
charset="US-ASCII"
Content-transfer-encoding: 7bit

Bernie,

We have considered this in prior discussions on the list. The consensus was
to keep backward compatibility by keeping the version number the same. The
updated draft is additive to the original RFC, so according to the AD this
was an acceptable approach.

--

JG

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior written
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

From: Bernie Hoeneisen
Date: Mon, 25 Jan 2010 11:09:12 -0500
To: EPP Provreg
Subject: [ietf-provreg] XML Schema versioning in 4310bis

Hi

As already pointed out to the authors of draft-gould-rfc4310bis, I see an
issue with the version numbering of the XML Schema. Although rfc4310bis
changes the XML schema defined in RFC 4310, it intends to reuse the
version number.

>From implementor point of view this is a very bad idea. It leads to
confusion and inconsistencies, in particular in the transition phasis. How
should an EPP Client figure out the capabilities of the EPP Server? The
repsonse to hello won't be useful to distiguish which schema applies.

I run into a similar problem while implementing RFC 5076. As there was a
change in the schema during the standardization process, I even needed to
distinguish between early I-D implementions and the final version of the
XML schema. I solved it by incrementing the sub-version of the XML schema.
See: http://tools.ietf.org/html/rfc5076#section-7

Therefore I strongly recommend to increment the (sub-)version number of
the XML Schema for 4310bis to 1.1

During transition period, the server can announce both versions and the
client knows what it is up to.

cheers,
Bernie
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

--B_3347267381_1502030
Content-type: text/html;
charset="US-ASCII"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] XML Schema versioning in 4310bis

Bernie,

We have considered this in prior discussions on the list.  The consens=
us was to keep backward compatibility by keeping the version number the same=
.  The updated draft is additive to the original RFC, so according to t=
he AD this was an acceptable approach.

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

From: Bernie Hoeneisen <[email-masked]>

Date: Mon, 25 Jan 2010 11:09:12 -0500

To: EPP Provreg <ietf-provreg@caf=
ax.se>

Subject: [ietf-provreg] XML Schema versioning in 4310bis

Hi

As already pointed out to the authors of draft-gould-rfc4310bis, I see an
issue with the version numbering of the XML Schema. Although rfc4310bis

changes the XML schema defined in RFC 4310, it intends to reuse the

version number.

>From implementor point of view this is a very bad idea. It leads to

confusion and inconsistencies, in particular in the transition phasis. How<=
BR>
should an EPP Client figure out the capabilities of the EPP Server? The

repsonse to hello won't be useful to distiguish which schema applies.

I run into a similar problem while implementing RFC 5076. As there was a
change in the schema during the standardization process, I even needed to
distinguish between early I-D implementions and the final version of the
XML schema. I solved it by incrementing the sub-version of the XML schema.<=
BR>
See: http://tools.ie=
tf.org/html/rfc5076#section-7

Therefore I strongly recommend to increment the (sub-)version number of

the XML Schema for 4310bis to 1.1

During transition period, the server can announce both versions and the

client knows what it is up to.

cheers,

Bernie

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=

List run by majordomo software.  For (Un-)subscription and similar det=
ails

send "help" to ietf-provr=
[email-masked]

--B_3347267381_1502030--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PH3vsI029458 for ; Mon, 25 Jan 2010 18:03:57 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0PH3v33017270 for ietf-provreg-outgoing; Mon, 25 Jan 2010 18:03:57 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PH3uPS004496 for ; Mon, 25 Jan 2010 18:03:56 +0100 (MET)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NZSLx-0006II-RW; Mon, 25 Jan 2010 18:03:53 +0100
Date: Mon, 25 Jan 2010 18:03:53 +0100 (CET)
From: Bernie Hoeneisen
X-X-Sender: [email-masked]
To: Edward Lewis
cc: [email-masked]
Subject: Re: [ietf-provreg] Proposal for new work
In-Reply-To:
Message-ID:
References:
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: [email-masked]
X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false
Sender: [email-masked]
Precedence: bulk

Hi Ed et al.

In the times I was still working with Switch I made a study about
different implementation variants of the Transfer command. The conclusion
was that almost every Registry had implemented the Tranfer in a different
way.

This study might help to englighten some of the shortcomings of EPP.
Unfortunately I only found a Draft Version of that study made in 2006:

http://ucom.ch/presentations/EPP_Transfer_Variants_20060920.pdf

[Please note, that the information in that document is most likely
outdated (2006). As it is a draft version, it also contains inaccuracies.]

At some CENTR Tech meeting I presented the results of that study.
If you have a CENTR login, you can find those slides at:

https://www.centr.org/main/lib/g1/3278-CTR.html

Hope this helps to better understand the problem space.

Have fun!

cheers,
Bernie

---

http://ucom.ch/
Tech Consulting for Internet Standardization

On Mon, 25 Jan 2010, Edward Lewis wrote:

> Two weeks ago I floated an idea for an effort to look at updating EPP in a
> new IETF WG. Last week I was occupied with other things including trying to
> prepare "IRE" for a BoF application.
>
> I think the following areas have promising work items:
>
> 1. Moving EPP-related RFCs along the standards track.
>
> I looked back at the published RFCs documenting extensions to EPP and found
> these:
>
> 5706 - ENUM Validation Information
> 4310 - DNSSEC
> 4114 - E.164 Number Mapping
> 3915 - Domain Registry Grace Period
>
> All of these are sitting at proposed standard.
>
> 2. Documenting more of the extensions on the standards track.
>
> I have heard of (but haven't been able to compile a list of) extensions done
> by registries that have not been documented in RFCs. This is not criminal
> (;)) but one of the desires voiced within PROVREG WG (in the early days) was
> to have a "unified" registration protocol.
>
> One beneficiary of this are the commercial registrars who can then work with
> more registries to "sell" more names, with the benefit to registries too.
> Said just for example.
>
> 3. Review of DNSSEC extensions.
>
> This item may not wait for WG formation, but if it is still hanging around it
> would be a "good one." (BoF application deadline is in about 12 hours, so
> it's tight to try to organize this in a day.)
>
> 4. A discussion of the shortcomings of EPP for new registry environments.
>
> This is more or less a EPPbis requirements document, if one at all. Between
> this and the next item, the work isn't necessarily EPP but registration
> improvements in general.
>
> Back to this, I am including this based on comments I heard in the CENTR Tech
> meetings, as well as some registries opting not to use EPP - or using EPP
> "under duress." I'm not saying anything is the matter - it would be good to
> give these discussions a place to be held.
>
> 5. How do we get DNSSEC information (DS RR; DNSKEY RR) into a registry in a
> generalized environment? EPP has RFC 4310 and the 4310bis draft, but what
> about situations in which EPP is not the conduit? Such as non-registrar DNS
> operators and registries that do not have registrars in the architecture?
>
> I'd appreciate commentary on this list of work items. Perhaps the next step
> is to set up a mail list for this and target having a BoF at the summer IETF
> (in SE Holland - some town whose name I can't spell "M-something" without
> looking at a map).
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis
> NeuStar You can leave a voice message at +1-571-434-5468
>
> As with IPv6, the problem with the deployment of frictionless surfaces is
> that they're not getting traction.
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> List run by majordomo software. For (Un-)subscription and similar details
> send "help" to [email-masked]
>
>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PGxP1c018926 for ; Mon, 25 Jan 2010 17:59:25 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0PGxPkA022475 for ietf-provreg-outgoing; Mon, 25 Jan 2010 17:59:25 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.130]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PGxOvi027016 for ; Mon, 25 Jan 2010 17:59:24 +0100 (MET)
Received: from limpet.local (cpe-67-241-43-7.twcny.res.rr.com [67.241.43.7]) by abenaki.wabanaki.net (8.14.3/8.14.3) with ESMTP id o0PGp15Q067477; Mon, 25 Jan 2010 11:51:02 -0500 (EST) (envelope-from [email-masked])
Message-ID: <[email-masked]>
Date: Mon, 25 Jan 2010 11:59:18 -0500
From: Eric Brunner-Williams
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: Edward Lewis
CC: [email-masked]
Subject: Re: [ietf-provreg] Proposal for new work
References:
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

Ed,

The "I have an extention" bits are fine, but each are a registry's
dork on the common case. We also need to fake, or figure out, or get
registrars (and I don't simply mean the 100+ actual registrars in the
900+ list of ICANN accredited registrars, but ccTLD registrars too)
into the mix, as they have a many-to-many view absent from registries.

The last time the world was 6 and 60, and the ccTLDs used a bunch of
stuff, and VGRS used RRP.

Now the world is 60 and 600 (caveat as above for the bogus shell
registrars, and also above for the ccTLD and their registrars now
using XML as the syntax and something EPP-esque as the protocol.

Last time we could (and did) submarine the thing into the IETF as a
small clique of (immanently) prospective and one actual gTLD registry
operators, within a very ICANN-market specific set of constraints.

This time we should recognized, like escrow, that zone provisioning is
not restricted to registries with contracts with ICANN, or which have
agreements with ICANN, but is generalized. The registry for
a.b.c.d.example could use EPP as could the registrars for a.b.c.d.example.

I'm fine with a mid-year BOF, I don't think there is any compelling
reason to hurry, as I read the EOI thing as "no delegations till
2013", and we're not as tightly constrained, by VGRS, by ICANN, by our
rush for gold and glory (or nominal utility) as we were the last time.

Eric
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PGGwAK028094 for ; Mon, 25 Jan 2010 17:16:58 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0PGGwJY011715 for ietf-provreg-outgoing; Mon, 25 Jan 2010 17:16:58 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PGGtXg020387 for ; Mon, 25 Jan 2010 17:16:57 +0100 (MET)
Received: from [10.31.200.251] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0PGGqC4068720; Mon, 25 Jan 2010 11:16:53 -0500 (EST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
Date: Mon, 25 Jan 2010 11:15:04 -0500
To: [email-masked]
From: Edward Lewis
Subject: [ietf-provreg] Proposal for new work
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4
Sender: [email-masked]
Precedence: bulk

Two weeks ago I floated an idea for an effort to look at updating EPP
in a new IETF WG. Last week I was occupied with other things
including trying to prepare "IRE" for a BoF application.

I think the following areas have promising work items:

1. Moving EPP-related RFCs along the standards track.

I looked back at the published RFCs documenting extensions to EPP and
found these:

5706 - ENUM Validation Information
4310 - DNSSEC
4114 - E.164 Number Mapping
3915 - Domain Registry Grace Period

All of these are sitting at proposed standard.

2. Documenting more of the extensions on the standards track.

I have heard of (but haven't been able to compile a list of)
extensions done by registries that have not been documented in RFCs.
This is not criminal (;)) but one of the desires voiced within
PROVREG WG (in the early days) was to have a "unified" registration
protocol.

One beneficiary of this are the commercial registrars who can then
work with more registries to "sell" more names, with the benefit to
registries too. Said just for example.

3. Review of DNSSEC extensions.

This item may not wait for WG formation, but if it is still hanging
around it would be a "good one." (BoF application deadline is in
about 12 hours, so it's tight to try to organize this in a day.)

4. A discussion of the shortcomings of EPP for new registry environments.

This is more or less a EPPbis requirements document, if one at all.
Between this and the next item, the work isn't necessarily EPP but
registration improvements in general.

Back to this, I am including this based on comments I heard in the
CENTR Tech meetings, as well as some registries opting not to use EPP
- or using EPP "under duress." I'm not saying anything is the matter
- it would be good to give these discussions a place to be held.

5. How do we get DNSSEC information (DS RR; DNSKEY RR) into a
registry in a generalized environment? EPP has RFC 4310 and the
4310bis draft, but what about situations in which EPP is not the
conduit? Such as non-registrar DNS operators and registries that do
not have registrars in the architecture?

I'd appreciate commentary on this list of work items. Perhaps the
next step is to set up a mail list for this and target having a BoF
at the summer IETF (in SE Holland - some town whose name I can't
spell "M-something" without looking at a map).
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PG9Fok015398 for ; Mon, 25 Jan 2010 17:09:15 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0PG9F76025109 for ietf-provreg-outgoing; Mon, 25 Jan 2010 17:09:15 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PG9Ehg013889 for ; Mon, 25 Jan 2010 17:09:14 +0100 (MET)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NZRV2-00060w-Ee for [email-masked]; Mon, 25 Jan 2010 17:09:12 +0100
Date: Mon, 25 Jan 2010 17:09:12 +0100 (CET)
From: Bernie Hoeneisen
X-X-Sender: [email-masked]
To: [email-masked]
Subject: [ietf-provreg] XML Schema versioning in 4310bis
Message-ID:
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: [email-masked]
X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false
Sender: [email-masked]
Precedence: bulk

Hi

As already pointed out to the authors of draft-gould-rfc4310bis, I see an
issue with the version numbering of the XML Schema. Although rfc4310bis
changes the XML schema defined in RFC 4310, it intends to reuse the
version number.

>From implementor point of view this is a very bad idea. It leads to
confusion and inconsistencies, in particular in the transition phasis. How
should an EPP Client figure out the capabilities of the EPP Server? The
repsonse to hello won't be useful to distiguish which schema applies.

I run into a similar problem while implementing RFC 5076. As there was a
change in the schema during the standardization process, I even needed to
distinguish between early I-D implementions and the final version of the
XML schema. I solved it by incrementing the sub-version of the XML schema.
See: http://tools.ietf.org/html/rfc5076#section-7

Therefore I strongly recommend to increment the (sub-)version number of
the XML Schema for 4310bis to 1.1

During transition period, the server can announce both versions and the
client knows what it is up to.

cheers,
Bernie
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PFSVpN012434 for ; Mon, 25 Jan 2010 16:28:31 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0PFSVkq007466 for ietf-provreg-outgoing; Mon, 25 Jan 2010 16:28:31 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PFSUap013288 for ; Mon, 25 Jan 2010 16:28:31 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id E4B571ECBFF0 for ; Mon, 25 Jan 2010 15:28:29 +0000 (UTC)
Date: Mon, 25 Jan 2010 10:28:28 -0500
From: Andrew Sullivan
To: [email-masked]
Subject: Re: [ietf-provreg] Revision of 4310
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , [email-masked]
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Mon, Jan 25, 2010 at 02:56:53PM +0000, Eduardo Duarte wrote:
>
> If no can I propose a small change in XSD (I know that is probably to
> late for that....). My suggestion is to add a Active/Non-Active field on

It's certainly not too late. The document has been submitted, but
there's ample time for revision still.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PEu8AP002448 for ; Mon, 25 Jan 2010 15:56:08 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0PEu8H4028230 for ietf-provreg-outgoing; Mon, 25 Jan 2010 15:56:08 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from app01.fccn.pt (app01.fccn.pt [193.137.198.36]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0PEu7tW029596 for ; Mon, 25 Jan 2010 15:56:07 +0100 (MET)
Received: from mx.anubis.local (ste [10.1.2.2]) by outbound.anubis.local (Postfix) with ESMTP id BF5DD320CA for ; Mon, 25 Jan 2010 14:56:06 +0000 (WET)
Received: from [193.136.44.92] (gaea.corp.fccn.pt [193.136.44.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: [email-masked]) by mx.anubis.local (Postfix) with ESMTP id B6BA8320AF; Mon, 25 Jan 2010 14:56:06 +0000 (WET)
Message-ID: <[email-masked]>
Date: Mon, 25 Jan 2010 14:56:53 +0000
From: Eduardo Duarte
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: [email-masked]
CC: "'WG-DNS'"
Subject: [ietf-provreg] Revision of 4310
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

Hello,

I work for the .PT ccTLD and I'm starting to add the DNSSEC extension
under our EPP implementation.
For doing this I'm following the the new revision of the 4310 RFC and I
was wondering something after reading it...

On our implementation of DNSSEC a domain can have multiple DS keys
associated were some are active and other are in an inactive state.
On the secDNS.xsd I didn't see any way to have multiple keys send in the
info command and have a way to show if they are active or not.

Was this matter discuss on the list already!?

If no can I propose a small change in XSD (I know that is probably to
late for that....). My suggestion is to add a Active/Non-Active field on
the DSdataType so the definition changes to the following:

Thanks and best regards,

Eduardo Duarte

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0LL4bfR011119 for ; Thu, 21 Jan 2010 22:04:37 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0LL4bwr011809 for ietf-provreg-outgoing; Thu, 21 Jan 2010 22:04:37 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0LL4Z6F007258 for ; Thu, 21 Jan 2010 22:04:36 +0100 (MET)
Received: from [10.31.200.228] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0LL4StK011663 for ; Thu, 21 Jan 2010 16:04:34 -0500 (EST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
Date: Thu, 21 Jan 2010 16:02:23 -0500
To: [email-masked]
From: Edward Lewis
Subject: [ietf-provreg] Internet Registration Escrow
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4
Sender: [email-masked]
Precedence: bulk

A new, non-EPP, effort is underway to discuss a topic germane to
registries and possibly registrars - escrow of the registration data.
A new mailing list has been set up for this discussion, [email-masked].
General information about the list is at:

https://www.ietf.org/mailman/listinfo/ire

Real soon now a BoF charter will be posted to that list and
discussion on that can begin. There will also be a draft sent out
soon. Currently the list is silent and empty, this message to
ietf-provreg is an invitation to join now in advance of the
discussions we hope to have.

We hope to have a BoF on the IETF 77 schedule, in March at Anaheim.
If there is sufficient work and audience we hope to charter an IETF
WG.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0KIUv6S006121 for ; Wed, 20 Jan 2010 19:30:57 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0KIUveO023604 for ietf-provreg-outgoing; Wed, 20 Jan 2010 19:30:57 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0KIUsMo027002 for ; Wed, 20 Jan 2010 19:30:56 +0100 (MET)
Received: from [0.0.0.0] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0KIUp5a085430; Wed, 20 Jan 2010 13:30:52 -0500 (EST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Wed, 20 Jan 2010 13:22:03 -0500
To:
From: Edward Lewis
Subject: Re: [ietf-provreg] new epp commands?
Cc: [email-masked]
Content-Type: multipart/alternative; boundary="============_-948110244==_ma============"
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4
Sender: [email-masked]
Precedence: bulk

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

5-10 years ago...EPP was for the input, IRIS was for the output.

The idea was that EPP would cover the add/delete/mods to the database
(and yes, limited info) but "bulk" retrievals would be left to
another protocol. IRIS came along for that, essentially a
replacement for WhoIs (and RWhoIs). After IRIS was mostly developed,
"domain checking" came along - the desire to see if a domain name was
available - and there was a lightweight (UDP) addition made to IRIS
to cover that.

What's important to keep in mind in "understanding" this is that this
happened during a time when domain name registries were still in
their infancy as well as the entire business of registering domains.
And yes, most of the thinking then was based what became ICANN's
shared registry model.

At 7:34 -0500 1/19/10, Gould, James wrote:
Jaap,

I believe that this was by design. We use reports for providing this
kind of information. Using the provisioning protocol as a query
protocol for what could be lists of millions of objects is not a good
use of the protocol.

JG

----- Original Message -----
From: [email-masked]
To: Ulrich Wisser
Cc: EPP Provreg
Sent: Tue Jan 19 07:08:39 2010
Subject: Re: [ietf-provreg] new epp commands?

My two cents in-line

here at .SE many registrars asked for lists of their
domains/hosts/contacts. Obviously there are no commands in the standard
to extract lists of objects from the epp server.

These registrars don't have an administration on there own?

Before proposing new commands I'd like to ask why there aren't any such
commands? Has it been a deliberate decision or didn't just nobody ask
for it?

It has been deliberate not to turn EPP into yet another whois
protocol. Also, not all registries do have this data because not
all are "thick registries".

jaap
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
--============_-948110244==_ma============
Content-Type: text/html; charset="us-ascii"

Re: [ietf-provreg] new epp
commands?

5-10 years ago...EPP was for the input, IRIS was for the
output.

The idea was that EPP would cover the add/delete/mods to the
database (and yes, limited info) but "bulk" retrievals would
be left to another protocol.  IRIS came along for that,
essentially a replacement for WhoIs (and RWhoIs).  After IRIS was
mostly developed, "domain checking" came along - the desire
to see if a domain name was available - and there was a lightweight
(UDP) addition made to IRIS to cover that.

What's important to keep in mind in "understanding"
this is that this happened during a time when domain name registries
were still in their infancy as well as the entire business of
registering domains.  And yes, most of the thinking then was
based what became ICANN's shared registry model.

At 7:34 -0500 1/19/10, Gould, James wrote:

Jaap,

I believe that this was by design.  We use reports for providing
this kind of information.  Using the provisioning protocol as a
query protocol for what could be lists of millions of objects is not a
good use of the protocol.

JG

----- Original Message -----

From: [email-masked]
<[email-masked]>

To: Ulrich Wisser <[email-masked]>

Cc: EPP Provreg <[email-masked]>

Sent: Tue Jan 19 07:08:39 2010

Subject: Re: [ietf-provreg] new epp commands?

My two cents in-line

here at .SE many registrars asked for lists of
their

domains/hosts/contacts. Obviously there are no
commands in the standard

to extract lists of objects from the epp
server.

These registrars don't have an administration on there own?

Before proposing new commands I'd like to ask why
there aren't any such

commands? Has it been a deliberate decision or
didn't just nobody ask

for it?

It has been deliberate not to turn EPP into yet another whois

protocol. Also, not all registries do have this data because not

all are "thick registries".

jaap

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

List run by majordomo software.  For (Un-)subscription and
similar details

send "help" to [email-masked]

--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Edward
Lewis

NeuStar                    You can
leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless
surfaces is

that they're not getting traction.

--============_-948110244==_ma============--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0KI99jU018740 for ; Wed, 20 Jan 2010 19:09:09 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0KI99LF014169 for ietf-provreg-outgoing; Wed, 20 Jan 2010 19:09:09 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0KI98AZ004042 for ; Wed, 20 Jan 2010 19:09:08 +0100 (MET)
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o0KI4Mmj012171; Wed, 20 Jan 2010 13:04:22 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 13:09:06 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Wed, 20 Jan 2010 18:09:05 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Wed, 20 Jan 2010 13:09:02 -0500
Subject: Re: [ietf-provreg] a question for the list
From: James Gould
To: Michael Young , Andrew Sullivan , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] a question for the list
Thread-Index: AcqZ456KynA/hSlaTzWtdKVfj4ZjXwABHycAAATif4U=
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3346837744_4303423"
X-OriginalArrivalTime: 20 Jan 2010 18:09:06.0660 (UTC) FILETIME=[A7EC4240:01CA99FB]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3346837744_4303423
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

I second Michael. The sponsorship query service could be defined using a
new EPP Mapping and the info command (filters defined in the command
supporting sponsorship information across multiple entity types). This is
just one example of a use case that could go up the standards track if ther=
e
was enough cross-cutting need. I don=B9t personally see a need for this but
others might. I wouldn=B9t touch the base protocol unless it was absolutely
necessary, but to focus on the set of custom mappings and extensions that
have been created and are being created to see if there is more general
interest of moving them up the standards track. We have many custom
mappings and extensions that might be of interest as well. Collaboration b=
y
an EPP Working Group would help address the issue of the growing set of
custom EPP mappings and extensions.

--=20

JG=20

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

=20
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior writte=
n
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

From: Michael Young
Date: Wed, 20 Jan 2010 10:58:26 -0500
To: Andrew Sullivan , EPP Provreg
Subject: RE: [ietf-provreg] a question for the list

I hear your arguments Andrew and I don't disagree. However I just haven't
seen any issues raised here that says we MUST or even SHOULD change the cor=
e
protocol. The listed issues thus far could all be dealt with using
extensions AND I do agree with forming a concentrated effort around managin=
g
extensions.

To my mind, any changes with the core protocol involves risk and cost to
registrars and registries. This is why a lot of consideration was given to
the extensions in the first place - to avoid having to jump immediately int=
o
core protocol revision work whenever a new use case comes up. The real
problem I am hearing here is that we (by "we" I mean the EPP community)
haven't done a good job managing extension work. We need to fix that.

Best Regards,

Michael Young

-----Original Message-----
From: Andrew Sullivan [mailto:[email-masked]]
Sent: January-19-10 9:05 AM
To: 'EPP Provreg'
Subject: Re: [ietf-provreg] a question for the list

On Tue, Jan 19, 2010 at 07:54:10AM -0500, Michael Young wrote:
> can't help but think that if we were talking about this level of change
with
> DNS, more than a few operators would get very concerned.

While I am obviously sympathetic to your argument, using DNS as an
analogue won't work: it's too different. The DNS is involved in just
about every interaction on the Internet, and it has to be deployed on
nearly every Internet node. Moreover, most DNS deployments (stub
resolvers) are on the machines of people we have no way of reaching
out and talking to. Finally, the DNS is an old protocol in Internet
terms, and therefore there is a lot of opportunity for small
carbuncles to have grown on it and become part of the _de facto_
standard, even though said growths are not actually found in any RFC.

None of those is true of EPP: the community is still relatively small,
and because EPP is a two-way protocol with a handshake step and so on,
it is possible to warn clients of an impending change to the protocol.
While provisioning in the DNS is pretty important, it's not core
infrastructure the way resolution in the DNS is, because it's not
directly invoked for every Internet transaction. And finally, since
the protocol isn't that old, the opportunities for it to have grown
significant differences from the RFCs are fewer (and such cases can,
in any case, be called errors without causing half the installed base
to qualify thereby as "broken").

So, the risk in changing EPP is obviously one of cost and some
disruption; but not "time to reformat the Internet", which is what
major changes to the DNS might entail if not done just right. In the
DNS, there are some pretty big rewards we'd like to go after, but the
risk is too great so we don't make the changes. Similar rewards, if
they were available in EPP, might be worth the risk.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

--B_3346837744_4303423
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] a question for the list

I second Michael.  The sponsorship query service could be defined usi=
ng a new EPP Mapping and the info command (filters defined in the command su=
pporting sponsorship information across multiple entity types).  This i=
s just one example of a use case that could go up the standards track if the=
re was enough cross-cutting need.  I don’t personally see a need =
for this but others might.  I wouldn’t touch the base protocol un=
less it was absolutely necessary, but to focus on the set of custom mappings=
and extensions that have been created and are being created to see if there=
is more general interest of moving them up the standards track.  We ha=
ve many custom mappings and extensions that might be of interest as well. &n=
bsp;Collaboration by an EPP Working Group would help address the issue of th=
e growing set of custom EPP mappings and extensions.

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

From: Michael Young <[email-masked]>

Date: Wed, 20 Jan 2010 10:58:26 -0500

To: Andrew Sullivan <[email-masked]<=
/a>>, EPP Provreg <ietf-provreg@cafax.=
se>

Subject: RE: [ietf-provreg] a question for the list

I hear your arguments Andrew and I don't disagree. However I just haven't
seen any issues raised here that says we MUST or even SHOULD change the cor=
e

protocol.  The listed issues thus far could all be dealt with using
extensions AND I do agree with forming a concentrated effort around managin=
g

extensions.

To my mind, any changes with the core protocol involves risk and cost to
registrars and registries.  This is why a lot of consideration was giv=
en to

the extensions in the first place - to avoid having to jump immediately int=
o

core protocol revision work whenever a new use case comes up.  The rea=
l

problem I am hearing here is that we (by "we" I mean the EPP comm=
unity)

haven't done a good job managing extension work. We need to fix that.

Best Regards,

Michael Young

-----Original Message-----

From: Andrew Sullivan [mailto:ajs@shinkur=
o.com]

Sent: January-19-10 9:05 AM

To: 'EPP Provreg'

Subject: Re: [ietf-provreg] a question for the list

On Tue, Jan 19, 2010 at 07:54:10AM -0500, Michael Young wrote:

> can't help but think that if we were talking about this level of chang=
e

with

> DNS, more than a few operators would get very concerned.

While I am obviously sympathetic to your argument, using DNS as an

analogue won't work: it's too different.  The DNS is involved in just<=
BR>
about every interaction on the Internet, and it has to be deployed on

nearly every Internet node.  Moreover, most DNS deployments (stub

resolvers) are on the machines of people we have no way of reaching

out and talking to.  Finally, the DNS is an old protocol in Internet
terms, and therefore there is a lot of opportunity for small

carbuncles to have grown on it and become part of the _de facto_

standard, even though said growths are not actually found in any RFC.

None of those is true of EPP: the community is still relatively small,

and because EPP is a two-way protocol with a handshake step and so on,

it is possible to warn clients of an impending change to the protocol.

While provisioning in the DNS is pretty important, it's not core

infrastructure the way resolution in the DNS is, because it's not

directly invoked for every Internet transaction.  And finally, since
the protocol isn't that old, the opportunities for it to have grown

significant differences from the RFCs are fewer (and such cases can,

in any case, be called errors without causing half the installed base

to qualify thereby as "broken").

So, the risk in changing EPP is obviously one of cost and some

disruption; but not "time to reformat the Internet", which is wha=
t

major changes to the DNS might entail if not done just right.  In the<=
BR>
DNS, there are some pretty big rewards we'd like to go after, but the

risk is too great so we don't make the changes.  Similar rewards, if
they were available in EPP, might be worth the risk.

A

--

Andrew Sullivan

[email-masked]

Shinkuro, Inc.

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=

List run by majordomo software.  For (Un-)subscription and similar det=
ails

send "help" to ietf-provr=
[email-masked]

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=

List run by majordomo software.  For (Un-)subscription and similar det=
ails

send "help" to ietf-provr=
[email-masked]

--B_3346837744_4303423--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0KFwkLI010814 for ; Wed, 20 Jan 2010 16:58:46 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0KFwk7g021022 for ietf-provreg-outgoing; Wed, 20 Jan 2010 16:58:46 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0KFwjgZ009490 for ; Wed, 20 Jan 2010 16:58:45 +0100 (MET)
Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1NXcxA-0003Wx-4G; Wed, 20 Jan 2010 15:58:44 +0000
Received: from tor-gateway.afilias.info ([199.15.87.4] helo=DUN345) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1NXcxA-0003Gt-3k; Wed, 20 Jan 2010 15:58:44 +0000
From: "Michael Young"
To: "'Andrew Sullivan'" , "'EPP Provreg'"
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Subject: RE: [ietf-provreg] a question for the list
Date: Wed, 20 Jan 2010 10:58:26 -0500
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcqZ456KynA/hSlaTzWtdKVfj4ZjXwABHycA
Content-Language: en-ca
Sender: [email-masked]
Precedence: bulk

I hear your arguments Andrew and I don't disagree. However I just haven't
seen any issues raised here that says we MUST or even SHOULD change the core
protocol. The listed issues thus far could all be dealt with using
extensions AND I do agree with forming a concentrated effort around managing
extensions.

To my mind, any changes with the core protocol involves risk and cost to
registrars and registries. This is why a lot of consideration was given to
the extensions in the first place - to avoid having to jump immediately into
core protocol revision work whenever a new use case comes up. The real
problem I am hearing here is that we (by "we" I mean the EPP community)
haven't done a good job managing extension work. We need to fix that.

Best Regards,

Michael Young

-----Original Message-----
From: Andrew Sullivan [mailto:[email-masked]]
Sent: January-19-10 9:05 AM
To: 'EPP Provreg'
Subject: Re: [ietf-provreg] a question for the list

On Tue, Jan 19, 2010 at 07:54:10AM -0500, Michael Young wrote:
> can't help but think that if we were talking about this level of change
with
> DNS, more than a few operators would get very concerned.

While I am obviously sympathetic to your argument, using DNS as an
analogue won't work: it's too different. The DNS is involved in just
about every interaction on the Internet, and it has to be deployed on
nearly every Internet node. Moreover, most DNS deployments (stub
resolvers) are on the machines of people we have no way of reaching
out and talking to. Finally, the DNS is an old protocol in Internet
terms, and therefore there is a lot of opportunity for small
carbuncles to have grown on it and become part of the _de facto_
standard, even though said growths are not actually found in any RFC.

None of those is true of EPP: the community is still relatively small,
and because EPP is a two-way protocol with a handshake step and so on,
it is possible to warn clients of an impending change to the protocol.
While provisioning in the DNS is pretty important, it's not core
infrastructure the way resolution in the DNS is, because it's not
directly invoked for every Internet transaction. And finally, since
the protocol isn't that old, the opportunities for it to have grown
significant differences from the RFCs are fewer (and such cases can,
in any case, be called errors without causing half the installed base
to qualify thereby as "broken").

So, the risk in changing EPP is obviously one of cost and some
disruption; but not "time to reformat the Internet", which is what
major changes to the DNS might entail if not done just right. In the
DNS, there are some pretty big rewards we'd like to go after, but the
risk is too great so we don't make the changes. Similar rewards, if
they were available in EPP, might be worth the risk.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0K9YfWb026047 for ; Wed, 20 Jan 2010 10:34:41 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0K9YfOj019095 for ietf-provreg-outgoing; Wed, 20 Jan 2010 10:34:41 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0K9YeAM007078 for ; Wed, 20 Jan 2010 10:34:40 +0100 (MET)
DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:Subject:To: X-Mailer:Message-ID:From:Date:X-MIMETrack:MIME-Version: Content-type; b=cEopupd1t29quGBVS5FGQ4K6kKFKtTyLjL/ffe2cxh3G/V6uhppDFRMv iX1ulMSiBVryj9YaUn0oXDLcmHLTp3A4OnT/4KLrByQlGEQLMRZ/Zxd/i pgyHf/Kj9ZUlX2k;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=[email-masked]; q=dns/txt; s=main.dkim.nominet.selector; t=1263980080; x=1295516080; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=[email-masked]|Subject:=20Re:=20 [ietf-provreg]=20new=20epp=20commands?|Date:=20Wed,=2020 =20Jan=202010=2009:34:38=20+0000|Message-ID:=20|To:=20"EPP=20Provreg"=20 |MIME-Version:=201.0|In-Reply-To:=20<20100119185736.GC733 [email-masked]>|References:=20=20=20<20100119185736.GC73378@ shinkuro.com>; bh=K50QFqjPuqhslygP/rZkIc5al0SK7JS4AkUZ5dzx/es=; b=PwSL6MCUeXgoE5xMQotydaPHH5oIht+czscbAEKdLnnu9vDTdqs6hW4V fIrqcOfCDHzIhTn3rn4fh8Rg1JjpgxHA5pkGwDtkIax34UWikteLE4zfq RvfkIjdTEUJ+YGP;
X-IronPort-AV: E=Sophos;i="4.49,309,1262563200"; d="scan'208";a="15676515"
Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 20 Jan 2010 09:34:40 +0000
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Subject: Re: [ietf-provreg] new epp commands?
To: "EPP Provreg"
X-Mailer: Lotus Notes Release 8.5 December 05, 2008
Message-ID:
From: [email-masked]
Date: Wed, 20 Jan 2010 09:34:38 +0000
X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 20/01/2010 09:34:39 AM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: [email-masked]
Precedence: bulk

> Andrew Sullivan

> On Tue, Jan 19, 2010 at 12:27:11PM -0500, James Gould wrote:
> > provided a complete list of sponsorship. Unbounded queries via EPP is
not
> > scalable.
>
> Why not? It's just an XML document. Why couldn't one have a
> mechanism for this? (Whether it's sane is another matter. I'm just
> being querulous.)

As has been mentioned, we have an EPP implementation of a list command. The
email-based system which predates EPP has a similar command, and is
routinely used by registrars to retrieve lists of ~1M domain names along
with account, host details etc. Registrars migrating to EPP have a
reasonable expectation to do the same thing, hence we have implemented it.

There were several scalability issues, but the most compelling was that
length of the message has to be known before it is sent, so that the 4-byte
header can be correctly written. This means that the entire message has to
be held in memory (or other storage), which in this case has the potential
to be very large. Multiply this size by the number of possible concurrent
requests, and you have an obvious hardware problem. Although the 4-byte
header clearly has its uses, it prevented us from streaming information
through the EPP server to the user - the storage issue disappears if you
can retrieve a small number of rows from the database, format them in XML,
send them down the socket, and repeat until you have fulfilled the request.
This way, the amount of storage needed per connection is bounded above and
is no different to a single-domain , which is much easier to cope
with.

For this and other reasons, we settled for a hamstrung version with a
configurable upper bound. This is rather inferior to the equivalent 'less
sophisticated' email system but is useful enough, and is rather more
efficient, both server- and client-side, than the registrar sending one
request for each of their domain names. By comparison, the
email-based system does not process concurrent requests, so the maximum
storage required is bounded above by the size of our registry, so holding
the entire message in memory was never a problem. Also, it does not return
XML, so the message itself is a lot more terse.

Alistair Braden

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JM72Is020228 for ; Tue, 19 Jan 2010 23:07:02 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0JM71Gh005775 for ietf-provreg-outgoing; Tue, 19 Jan 2010 23:07:01 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from bne004mr.server-mail.com (bne004mr.server-mail.com [203.147.179.18]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JM6x8i023550 for ; Tue, 19 Jan 2010 23:07:01 +0100 (MET)
Received: from wic002mz.server-mail.com (wic002mz.server-mail.com [210.247.173.2]) by bne004mr.server-mail.com (Postfix) with ESMTP id 2A562B0047 for ; Wed, 20 Jan 2010 08:06:57 +1000 (EST)
Received: from wic001mitef.messaging.mit ([172.31.0.11]) by wic002mz.server-mail.com with - id Xa6o1d0090EERy43Na6o1j; Wed, 20 Jan 2010 08:06:57 +1000
Received: from WIC001MITEBCLV1.messaging.mit ([172.31.0.20]) by wic001mitef.messaging.mit with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 08:03:35 +1000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [ietf-provreg] new epp commands?
Date: Wed, 20 Jan 2010 08:06:47 +1000
Message-ID:
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] new epp commands?
Thread-Index: AcqY/sNAn8NUn2iaSIOqUK9xplw2kgADGLggABIK4uA=
References: <[email-masked]> <[email-masked]>
From: "Bruce Tonkin"
To: "EPP Provreg"
X-OriginalArrivalTime: 19 Jan 2010 22:03:35.0358 (UTC) FILETIME=[3F1B75E0:01CA9953]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o0JM718i023132
Sender: [email-masked]
Precedence: bulk

Hello All,

> >
> > here at .SE many registrars asked for lists of their
> > domains/hosts/contacts. Obviously there are no commands in
> > the standard to extract lists of objects from the epp server.
> >
> > Before proposing new commands I'd like to ask why there
> > aren't any such commands? Has it been a deliberate decision
> > or didn't just nobody ask for it?
>
> It was most definitely a deliberate decision. The primary reason was
> because many people felt that this type of reporting feature would be
> out of place in a provisioning protocol due to the large
> amount of data
> that could be returned.
>

I am certainly getting requests to have some standard commands around
some of the reporting aspects of domain name management.

In particular some way of polling for account balances etc. The
process of adding funds is generally out-of-band - e.g via
accounting/finance functions, so it is useful for the provisioning
systems to be able to check account balances against database
information such as number of names coming up for renewal etc.

Regards,
Bruce Tonkin

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JJ84TC018640 for ; Tue, 19 Jan 2010 20:08:04 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0JJ840P014256 for ietf-provreg-outgoing; Tue, 19 Jan 2010 20:08:04 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JJ83aS001251 for ; Tue, 19 Jan 2010 20:08:04 +0100 (MET)
Received: from zx80.arin.net ([::ffff:192.149.252.11]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 19 Jan 2010 14:08:01 -0500 id 015B00D3.4B560311.0000310A
Subject: Re: [ietf-provreg] new epp commands?
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=iso-8859-1
From: Andrew Newton
In-Reply-To:
Date: Tue, 19 Jan 2010 14:08:00 -0500
Cc: Andrew Sullivan , EPP Provreg
Message-Id:
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
To: "=?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?="
X-Mailer: Apple Mail (2.1077)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o0JJ84aS024348
Sender: [email-masked]
Precedence: bulk

On Jan 19, 2010, at 11:34 AM, Patrik Fältström wrote:

> On 19 jan 2010, at 16.29, Andrew Sullivan wrote:
>
>> On Tue, Jan 19, 2010 at 04:21:07PM +0100, Patrik Fältström wrote:
>>>
>>> IRIS solves a different problem. If you want to sync two databases with epp interface, you definitely want to use epp, as such things like roid, relationship between records etc is absolutely crucial.

Yes, IRIS was focused on end-user to registry/registrar and not registrar to registry. That was the big difference.

>>
>> I thought there was a way to get every single thing you could get in
>> EPP via IRIS. No? (I'm prepared to be wrong. Afilias was never
>> really interested in the IRIS stuff, so I read the documents &
>> commented a little but didn't put a lot of effort into it.)

There was an IRIS serialization format for copying datasets, not necessarily synching. Think LDIF for IRIS.

> Yes, of course you _can_, but it is much easier if the database structure etc is exactly the same for every record you want to work with.
>

I would agree with this, except this entire discussion seems to center around the fact the everyone does something in a different way. Which kinda leads one to question a standard here.

As an aside, the ECRIT working group also has a synchronization format for their problem space and even their simpler cases seem difficult.

>> I wonder, however, whether it's even a good idea to sync two
>> databases, especially via EPP. My time as a database geek taught me
>> nothing so much as that having two authoritative sources for data is a
>> way to be sure that one of them is wrong.
>
> Well, that is how a thick registry works. By having epp as a synchronization protocol. If the registry is to have the information about who is the holder of each domain, while the registrar is to invoice the customer, the registrar definitely also will have information about the same holder. Transfer of domains and contacts, and updates of contact etc information ends up being an "interesting" game where both parties are moving around the pieces on the chess board at the same time.
>
> In this case, we more or less only talk about the ability for the registrar to issue a query like:
>
> - What domains am I sponsor for?
>
> - What contacts am I sponsor for?
>
> Etc.

Andrew is right that two authoritative sources makes the job much more difficult. If the problem were constrained to "the registry is always right", then the task gets much easier.

As for doing this in IRIS or EPP or something else? Resources are resources and I don't think there is much of a difference when it comes to CPU cycles, so it may as well be done inside EPP to lessen the pain of adoption and interoperability. It seems to me that if some registries don't want to implement it, then they shouldn't.

-andy
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JIvfVZ015925 for ; Tue, 19 Jan 2010 19:57:41 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0JIvfKn012133 for ietf-provreg-outgoing; Tue, 19 Jan 2010 19:57:41 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JIvfbn023672 for ; Tue, 19 Jan 2010 19:57:41 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 980042FE8CA1 for ; Tue, 19 Jan 2010 18:57:38 +0000 (UTC)
Date: Tue, 19 Jan 2010 13:57:37 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] new epp commands?
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References:
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Tue, Jan 19, 2010 at 12:27:11PM -0500, James Gould wrote:
> provided a complete list of sponsorship. Unbounded queries via EPP is not
> scalable.

Why not? It's just an XML document. Why couldn't one have a
mechanism for this? (Whether it's sane is another matter. I'm just
being querulous.)

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JHRZfB023389 for ; Tue, 19 Jan 2010 18:27:35 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0JHRZKY007055 for ietf-provreg-outgoing; Tue, 19 Jan 2010 18:27:35 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JHRJEB004765; Tue, 19 Jan 2010 18:27:19 +0100 (MET)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o0JHMaae009259; Tue, 19 Jan 2010 12:22:36 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 12:27:18 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Tue, 19 Jan 2010 17:27:16 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Tue, 19 Jan 2010 12:27:11 -0500
Subject: Re: [ietf-provreg] new epp commands?
From: James Gould
To: , Patrik =?ISO-8859-1?B?RuRsdHN0cvZt?=
CC: Andrew Sullivan , EPP Provreg , "[email-masked]"
Message-ID:
Thread-Topic: [ietf-provreg] new epp commands?
Thread-Index: AcqZLKIPMZCl/8WGrkewW4FDqlkJmQ==
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3346748835_2931367"
X-OriginalArrivalTime: 19 Jan 2010 17:27:18.0183 (UTC) FILETIME=[A6574B70:01CA992C]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3346748835_2931367
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

We created an info extension for getting the additional whois information
(url, whois, and registrar name) to support transfers. We use reports for
provided a complete list of sponsorship. Unbounded queries via EPP is not
scalable. =20

--=20

JG=20

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

=20
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior writte=
n
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

From:
Date: Tue, 19 Jan 2010 16:30:49 +0000
To: Patrik F=E4ltstr=F6m
Cc: Andrew Sullivan , EPP Provreg =
,
"[email-masked]"
Subject: Re: [ietf-provreg] new epp commands?

> We have already gone through one issue in Sweden, and that have to
> do with the fact that access control in EPP was such that a
> registrar could access more data about records via whois than epp.
> That forced registrars to use whois in their automated processing,
> parse the data, risk being blacklisted etc... Now we have made sure
> (thanks to hard work at .SE) a registrar can always get data about
> domains in .SE via epp. Not one access mechanism for their domains,
> and one (whois) for domains the registrar is not a sponsor of.

We've also implemented an extension for sending back a list of
domains:=20

http://www.nominet.org.uk/registrars/systems/nominetepp/list/

Ray=20

--=20
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

--B_3346748835_2931367
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] new epp commands?

We created an info extension for getting the additional whois information =
(url, whois, and registrar name) to support transfers.  We use reports =
for provided a complete list of sponsorship.  Unbounded queries via EPP=
is not scalable.

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

From: <[email-masked]>

Date: Tue, 19 Jan 2010 16:30:49 +0000

To: Patrik Fältström <paf@cisco=
.com>

Cc: Andrew Sullivan <[email-masked]<=
/a>>, EPP Provreg <ietf-provreg@cafax.=
se>, "owner-ietf-provreg@c=
afax.se" <owner-ietf-provr=
[email-masked]>

Subject: Re: [ietf-provreg] new epp commands?

> We have already gone through one issue in Sweden, and that have to
> do with the fact that access control in EPP was such that a

> registrar could access more data about records via whois than epp.
> That forced registrars to use whois in their automated processing,
> parse the data, risk being blacklisted etc... Now we have made sure
> (thanks to hard work at .SE) a registrar can always get data about
> domains in .SE via epp. Not one access mechanism for their domains,
> and one (whois) for domains the registrar is not a sponsor of.

We've also implemented a=
n <info> extension for sending back a list of domains:

http://www.nominet.or=
g.uk/registrars/systems/nominetepp/list/ <http://www.nominet.org.uk/registrars/systems/nominet=
epp/list/>

Ray

--

Ray Bellis, MA(Oxon) MIET

Senior Researcher in Advanced Projects, Nominet

e: [email-masked], t: +44 1865 332211<=
BR>

--B_3346748835_2931367--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JGnpF2014531 for ; Tue, 19 Jan 2010 17:49:51 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0JGnptq017664 for ietf-provreg-outgoing; Tue, 19 Jan 2010 17:49:51 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JGnoTf010425 for ; Tue, 19 Jan 2010 17:49:50 +0100 (MET)
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o0JGVE1w010557; Tue, 19 Jan 2010 11:31:14 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 11:49:48 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Tue, 19 Jan 2010 16:49:48 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Tue, 19 Jan 2010 11:49:47 -0500
Subject: Re: [ietf-provreg] FYI: Last Call: draft-gould-rfc4310bis
From: James Gould
To: Jaap Akkerhuis , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] FYI: Last Call: draft-gould-rfc4310bis
Thread-Index: AcqZInUW9TYLHCcUR6OkzeK2qkT+cQABPNy8
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3346746588_2818770"
X-OriginalArrivalTime: 19 Jan 2010 16:49:48.0694 (UTC) FILETIME=[698A8360:01CA9927]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3346746588_2818770
Content-type: text/plain;
charset="US-ASCII"
Content-transfer-encoding: 7bit

Jaap,

Thanks for sending out the update, you beat me to the punch :-) I want to
thank everyone on the list for their contributions to the draft.

--

JG

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior written
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

From: Jaap Akkerhuis
Date: Tue, 19 Jan 2010 10:51:05 -0500
To: EPP Provreg
Subject: [ietf-provreg] FYI: Last Call: draft-gould-rfc4310bis

In case someone missed this announcement

jaap

________________

To: IETF-Announce
From: The IESG
Subject: Last Call: draft-gould-rfc4310bis (Domain Name System (DNS)
Security
Extensions Mapping for the Extensible Provisioning Protocol
(EPP)) to Proposed Standard
Date: Tue, 19 Jan 2010 06:57:18 -0800 (PST)

The IESG has received a request from an individual submitter to consider
the following document:

- 'Domain Name System (DNS) Security Extensions Mapping for the
Extensible Provisioning Protocol (EPP) '
as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2010-02-16. Exceptionally,
comments may be sent to [email-masked] instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-gould-rfc4310bis-03.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=1945
1&rfc_flag=0

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

--B_3346746588_2818770
Content-type: text/html;
charset="US-ASCII"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] FYI: Last Call: draft-gould-rfc4310bis

Jaap,

Thanks for sending out the update, you beat me to the punch :-)  I wan=
t to thank everyone on the list for their contributions to the draft.  =

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

From: Jaap Akkerhuis <[email-masked]>

Date: Tue, 19 Jan 2010 10:51:05 -0500

To: EPP Provreg <ietf-provreg@caf=
ax.se>

Subject: [ietf-provreg] FYI: Last Call: draft-gould-rfc4310bis

In case someone missed this announcement

jaap

________________

To: IETF-Announce <ietf-ann=
[email-masked]>

From: The IESG <iesg-secre=
[email-masked]>

Subject: Last Call: draft-gould-rfc4310bis (Domain Name System =
(DNS) Security

Extensions Mapping for the =
Extensible Provisioning Protocol

(EPP)) to Proposed Standard=

Date: Tue, 19 Jan 2010 06:57:18 -0800 (PST)

The IESG has received a request from an individual submitter to consider
the following document:

- 'Domain Name System (DNS) Security Extensions Mapping for the

Extensible Provisioning Protocol (EPP) '

<draft-gould-rfc4310bis-03.txt> as a Proposed Stand=
ard

The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action.  Please send substantive comments to th=
e

[email-masked] mailing lists by 2010-02-16. Exce=
ptionally,

comments may be sent to [email-masked] instead. =
In either case, please

retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via

http://www.ietf.org/internet-drafts/draft-gould-rfc4310bis-03.txt

IESG discussion can be tracked via

https://datatracker.ietf.org/public/pidtrack=
er.cgi?command=3Dview_id&dTag=3D19451&rfc_flag=3D0

_______________________________________________

IETF-Announce mailing list

[email-masked]

https://www.i=
etf.org/mailman/listinfo/ietf-announce

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=

List run by majordomo software.  For (Un-)subscription and similar det=
ails

send "help" to ietf-provr=
[email-masked]

--B_3346746588_2818770--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JGn0in015031 for ; Tue, 19 Jan 2010 17:49:00 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0JGn0FT007720 for ietf-provreg-outgoing; Tue, 19 Jan 2010 17:49:00 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JGmxQ1012586 for ; Tue, 19 Jan 2010 17:48:59 +0100 (MET)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqIAAM5xVUuQ/uCWe2dsb2JhbACbfwEBFiQGpiSVEoQzBA
X-IronPort-AV: E=Sophos;i="4.49,304,1262563200"; d="scan'208";a="2577026"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 19 Jan 2010 16:19:35 +0000
Received: from [192.165.72.14] (dhcp-10-61-99-228.cisco.com [10.61.99.228]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0JGmxMK011506; Tue, 19 Jan 2010 16:48:59 GMT
Subject: Re: [ietf-provreg] new epp commands?
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=
In-Reply-To: <[email-masked]>
Date: Tue, 19 Jan 2010 17:34:11 +0100
Cc: EPP Provreg
Message-Id:
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
To: Andrew Sullivan
X-Mailer: Apple Mail (2.1077)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o0JGmxQ1007250
Sender: [email-masked]
Precedence: bulk

On 19 jan 2010, at 16.29, Andrew Sullivan wrote:

> On Tue, Jan 19, 2010 at 04:21:07PM +0100, Patrik Fältström wrote:
>>
>> IRIS solves a different problem. If you want to sync two databases with epp interface, you definitely want to use epp, as such things like roid, relationship between records etc is absolutely crucial.
>
> I thought there was a way to get every single thing you could get in
> EPP via IRIS. No? (I'm prepared to be wrong. Afilias was never
> really interested in the IRIS stuff, so I read the documents &
> commented a little but didn't put a lot of effort into it.)

Yes, of course you _can_, but it is much easier if the database structure etc is exactly the same for every record you want to work with.

> I wonder, however, whether it's even a good idea to sync two
> databases, especially via EPP. My time as a database geek taught me
> nothing so much as that having two authoritative sources for data is a
> way to be sure that one of them is wrong.

Well, that is how a thick registry works. By having epp as a synchronization protocol. If the registry is to have the information about who is the holder of each domain, while the registrar is to invoice the customer, the registrar definitely also will have information about the same holder. Transfer of domains and contacts, and updates of contact etc information ends up being an "interesting" game where both parties are moving around the pieces on the chess board at the same time.

In this case, we more or less only talk about the ability for the registrar to issue a query like:

- What domains am I sponsor for?

- What contacts am I sponsor for?

Etc.

Patrik

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JGVBIv002644 for ; Tue, 19 Jan 2010 17:31:11 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0JGVALm010839 for ietf-provreg-outgoing; Tue, 19 Jan 2010 17:31:10 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JGUriP005067; Tue, 19 Jan 2010 17:30:53 +0100 (MET)
DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=YpW2/lQEqZRi6lAViCITq1pDusGs6XggL3RTyJURHGlsHDU2Pzrn7OtT u3l/3neL/wgWvc6J1ouWSTMLFuc02AMwJ5860tQYBIlag2K2KrKmk3nIW auFB4AFK3ayZlGY;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=[email-masked]; q=dns/txt; s=main.dkim.nominet.selector; t=1263918653; x=1295454653; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=[email-masked]|Subject:=20Re:=20[ietf -provreg]=20new=20epp=20commands?|Date:=20Tue,=2019=20Jan =202010=2016:30:49=20+0000|Message-ID:=20|To:=20Patrik=20=3D?ISO-8859-1?Q?F=3DE4ltstr=3DF6m?=3D =20|Cc:=20Andrew=20Sullivan=20,=0D=0A=09EPP=20Provreg=20, =0D=0A=[email-masked]|MIME-Version:=201.0 |In-Reply-To:=20|References:=20<[email-masked]>=20< [email-masked] rp.ad.vrsn.com>=20<[email-masked]> =20; bh=VYFmco3TjPawGqwO94PgJfE/qJJyhfoW6iZI2Sc8HZ8=; b=k6kNbs7ggYpfq1krJMsfM6NwMZtoLz2/8ZLwMiwDialERo5MiIWVXWcX 0budvMXDhrfAKABHK9riPR4Pmsx0lY1zJExBwbCre52UOuE8NLU5w7lBw +sDwBrJSbBEtHbE;
X-IronPort-AV: E=Sophos;i="4.49,304,1262563200"; d="scan'208";a="21012540"
Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 19 Jan 2010 16:30:50 +0000
In-Reply-To:
References: <[email-masked]> <[email-masked]> <[email-masked]>
To: Patrik =?ISO-8859-1?Q?F=E4ltstr=F6m?=
Cc: Andrew Sullivan , EPP Provreg , [email-masked]
Subject: Re: [ietf-provreg] new epp commands?
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 8.5 December 05, 2008
Message-ID:
From: [email-masked]
Date: Tue, 19 Jan 2010 16:30:49 +0000
X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 19/01/2010 04:30:50 PM, Serialize complete at 19/01/2010 04:30:50 PM
Content-Type: multipart/alternative; boundary="=_alternative 005AB670802576B0_="
Sender: [email-masked]
Precedence: bulk

This is a multipart message in MIME format.
--=_alternative 005AB670802576B0_=
Content-Type: text/plain; charset="US-ASCII"

> We have already gone through one issue in Sweden, and that have to
> do with the fact that access control in EPP was such that a
> registrar could access more data about records via whois than epp.
> That forced registrars to use whois in their automated processing,
> parse the data, risk being blacklisted etc... Now we have made sure
> (thanks to hard work at .SE) a registrar can always get data about
> domains in .SE via epp. Not one access mechanism for their domains,
> and one (whois) for domains the registrar is not a sponsor of.

We've also implemented an extension for sending back a list of
domains:

http://www.nominet.org.uk/registrars/systems/nominetepp/list/

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

--=_alternative 005AB670802576B0_=
Content-Type: text/html; charset="US-ASCII"

> We have already gone through one issue in Sweden, and that have to

> do with the fact that access control in EPP was such that a

> registrar could access more data about records via whois than epp.

> That forced registrars to use whois in their automated processing,

> parse the data, risk being blacklisted etc... Now we have made sure

> (thanks to hard work at .SE) a registrar can always get data about

> domains in .SE via epp. Not one access mechanism for their domains,

> and one (whois) for domains the registrar is not a sponsor of.

We've also implemented an <info> extension for
sending back a list of domains:

http://www.nominet.org.uk/registrars/systems/nominetepp/list/

Ray

--

Ray Bellis, MA(Oxon) MIET

Senior Researcher in Advanced Projects, Nominet

e: [email-masked], t: +44 1865 332211

--=_alternative 005AB670802576B0_=--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JFp9St019086 for ; Tue, 19 Jan 2010 16:51:09 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0JFp9ml000184 for ietf-provreg-outgoing; Tue, 19 Jan 2010 16:51:09 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [213.154.224.50]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JFp8r0029347 for ; Tue, 19 Jan 2010 16:51:08 +0100 (MET)
Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id o0JFp5lx003812 for ; Tue, 19 Jan 2010 16:51:05 +0100 (CET) (envelope-from [email-masked])
Message-Id: <[email-masked]>
To: [email-masked]
Subject: [ietf-provreg] FYI: Last Call: draft-gould-rfc4310bis
Date: Tue, 19 Jan 2010 16:51:05 +0100
From: Jaap Akkerhuis
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (bartok.nlnetlabs.nl [127.0.0.1]); Tue, 19 Jan 2010 16:51:06 +0100 (CET)
X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, MISSING_MID autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bartok.nlnetlabs.nl
Sender: [email-masked]
Precedence: bulk

In case someone missed this announcement

jaap

________________

To: IETF-Announce
From: The IESG
Subject: Last Call: draft-gould-rfc4310bis (Domain Name System (DNS) Security
Extensions Mapping for the Extensible Provisioning Protocol
(EPP)) to Proposed Standard
Date: Tue, 19 Jan 2010 06:57:18 -0800 (PST)

The IESG has received a request from an individual submitter to consider
the following document:

- 'Domain Name System (DNS) Security Extensions Mapping for the
Extensible Provisioning Protocol (EPP) '
as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2010-02-16. Exceptionally,
comments may be sent to [email-masked] instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-gould-rfc4310bis-03.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19451&rfc_flag=0

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JFTObC023483 for ; Tue, 19 Jan 2010 16:29:24 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0JFTOUV028134 for ietf-provreg-outgoing; Tue, 19 Jan 2010 16:29:24 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JFTON8029860 for ; Tue, 19 Jan 2010 16:29:24 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 8600C2FE8CA1 for ; Tue, 19 Jan 2010 15:29:21 +0000 (UTC)
Date: Tue, 19 Jan 2010 10:29:19 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] new epp commands?
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References: <[email-masked]> <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To:
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Tue, Jan 19, 2010 at 04:21:07PM +0100, Patrik FÃ¤ltstrÃ¶m wrote:
>
> IRIS solves a different problem. If you want to sync two databases with epp interface, you definitely want to use epp, as such things like roid, relationship between records etc is absolutely crucial.
>

I thought there was a way to get every single thing you could get in
EPP via IRIS. No? (I'm prepared to be wrong. Afilias was never
really interested in the IRIS stuff, so I read the documents &
commented a little but didn't put a lot of effort into it.)

I wonder, however, whether it's even a good idea to sync two
databases, especially via EPP. My time as a database geek taught me
nothing so much as that having two authoritative sources for data is a
way to be sure that one of them is wrong.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JFL8w4001793 for ; Tue, 19 Jan 2010 16:21:08 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0JFL81X015644 for ietf-provreg-outgoing; Tue, 19 Jan 2010 16:21:08 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JFL8mh006095 for ; Tue, 19 Jan 2010 16:21:08 +0100 (MET)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqIAADJcVUuQ/uCWe2dsb2JhbACbfwEBFiQGpiWVFYQzBA
X-IronPort-AV: E=Sophos;i="4.49,303,1262563200"; d="scan'208";a="56291647"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Jan 2010 15:21:08 +0000
Received: from [192.165.72.14] (ams3-vpn-dhcp5252.cisco.com [10.61.84.131]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0JFL7Qu021477; Tue, 19 Jan 2010 15:21:07 GMT
Subject: Re: [ietf-provreg] new epp commands?
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=
In-Reply-To: <[email-masked]>
Date: Tue, 19 Jan 2010 16:21:07 +0100
Cc: EPP Provreg
Message-Id:
References: <[email-masked]> <[email-masked]> <[email-masked]>
To: Andrew Sullivan
X-Mailer: Apple Mail (2.1077)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o0JFL8mh015102
Sender: [email-masked]
Precedence: bulk

On 19 jan 2010, at 14.50, Andrew Sullivan wrote:

> On Tue, Jan 19, 2010 at 08:31:58AM -0500, Hollenbeck, Scott wrote:
>> It was most definitely a deliberate decision. The primary reason was
>> because many people felt that this type of reporting feature would be
>> out of place in a provisioning protocol due to the large amount of data
>> that could be returned.
>
> Also, there was another IETF working group aiming to solve that
> problem, IIRC. CRISP produced IRIS. I'm not aware of any
> implementations, however.

IRIS solves a different problem. If you want to sync two databases with epp interface, you definitely want to use epp, as such things like roid, relationship between records etc is absolutely crucial.

But, if the IETF do not want to have a unified way of doing that, then we will done in .SE (I hope) and some other TLDs will invent their way of doing the same thing.

;-)

We have already gone through one issue in Sweden, and that have to do with the fact that access control in EPP was such that a registrar could access more data about records via whois than epp. That forced registrars to use whois in their automated processing, parse the data, risk being blacklisted etc... Now we have made sure (thanks to hard work at .SE) a registrar can always get data about domains in .SE via epp. Not one access mechanism for their domains, and one (whois) for domains the registrar is not a sponsor of.

When you start having tons of data in the registry (about holders, hosts, dnssec keys etc) having one stable way of communicating and not flip flopping between protocols for me absolutely makes sense.

Patrik

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JEIRUC019784 for ; Tue, 19 Jan 2010 15:18:27 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0JEIQQp023682 for ietf-provreg-outgoing; Tue, 19 Jan 2010 15:18:26 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JEIQe1024367 for ; Tue, 19 Jan 2010 15:18:26 +0100 (MET)
Received: from sidn.nl ([192.168.2.12]) by ede1-kamx.sidn.nl with ESMTP id o0JEIPsC015886 for ; Tue, 19 Jan 2010 15:18:26 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [ietf-provreg] new epp commands?
Date: Tue, 19 Jan 2010 15:18:25 +0100
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] new epp commands?
Thread-Index: AcqZEN2HhmKdJkbuSrCNrb+WsH5kwgAASXpQ
References: <[email-masked]> <[email-masked]> <[email-masked]>
From: "Marc Groeneweg"
To: "EPP Provreg"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o0JEIQe1005830
Sender: [email-masked]
Precedence: bulk

Andrew,

> Also, there was another IETF working group aiming to solve that
> problem, IIRC. CRISP produced IRIS. I'm not aware of any
> implementations, however.
As far as I know, only one implementation exists, and that's Denic with
a dchk implementation. Verisign themselves have pulled the plug of their
IRIS testbed (as far as I can see).

Regards,
Marc

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JECO2h029412 for ; Tue, 19 Jan 2010 15:12:24 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0JECObA011850 for ietf-provreg-outgoing; Tue, 19 Jan 2010 15:12:24 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from complx.nepustil.net (complx.nepustil.net [212.71.195.58]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JECNa3014157 for ; Tue, 19 Jan 2010 15:12:23 +0100 (MET)
Received: from pi by complx.nepustil.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NXEoh-000FC5-3T for [email-masked]; Tue, 19 Jan 2010 15:12:23 +0100
Date: Tue, 19 Jan 2010 15:12:23 +0100
From: Kurt Jaeger
To: EPP Provreg
Subject: Re: [ietf-provreg] new epp commands?
Message-ID: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
Sender: [email-masked]
Precedence: bulk

Hi!

> > It was most definitely a deliberate decision. The primary reason was
> > because many people felt that this type of reporting feature would be
> > out of place in a provisioning protocol due to the large amount of data
> > that could be returned.
>
> Also, there was another IETF working group aiming to solve that
> problem, IIRC. CRISP produced IRIS. I'm not aware of any
> implementations, however.

DENIC has some code and docs on IRIS.

http://www.denic.de/domaincheck/domaincheck-hintergrund.html

--
MfG/Best regards, Kurt Jaeger 10 years to go !
Dr.-Ing. Nepustil & Co. GmbH fon +49 7123 93006-0 [email-masked]
Rathausstr. 3 fax +49 7123 93006-99
72658 Bempflingen mob +49 171 3101372
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JE4oEV010712 for ; Tue, 19 Jan 2010 15:04:50 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0JE4oYC012648 for ietf-provreg-outgoing; Tue, 19 Jan 2010 15:04:50 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JE4n4Q025348 for ; Tue, 19 Jan 2010 15:04:49 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id AA08D2FE8CA1 for ; Tue, 19 Jan 2010 14:04:48 +0000 (UTC)
Date: Tue, 19 Jan 2010 09:04:47 -0500
From: Andrew Sullivan
To: "'EPP Provreg'"
Subject: Re: [ietf-provreg] a question for the list
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , 'EPP Provreg'
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Tue, Jan 19, 2010 at 07:54:10AM -0500, Michael Young wrote:
> can't help but think that if we were talking about this level of change with
> DNS, more than a few operators would get very concerned.

While I am obviously sympathetic to your argument, using DNS as an
analogue won't work: it's too different. The DNS is involved in just
about every interaction on the Internet, and it has to be deployed on
nearly every Internet node. Moreover, most DNS deployments (stub
resolvers) are on the machines of people we have no way of reaching
out and talking to. Finally, the DNS is an old protocol in Internet
terms, and therefore there is a lot of opportunity for small
carbuncles to have grown on it and become part of the _de facto_
standard, even though said growths are not actually found in any RFC.

None of those is true of EPP: the community is still relatively small,
and because EPP is a two-way protocol with a handshake step and so on,
it is possible to warn clients of an impending change to the protocol.
While provisioning in the DNS is pretty important, it's not core
infrastructure the way resolution in the DNS is, because it's not
directly invoked for every Internet transaction. And finally, since
the protocol isn't that old, the opportunities for it to have grown
significant differences from the RFCs are fewer (and such cases can,
in any case, be called errors without causing half the installed base
to qualify thereby as "broken").

So, the risk in changing EPP is obviously one of cost and some
disruption; but not "time to reformat the Internet", which is what
major changes to the DNS might entail if not done just right. In the
DNS, there are some pretty big rewards we'd like to go after, but the
risk is too great so we don't make the changes. Similar rewards, if
they were available in EPP, might be worth the risk.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JDoXEG004083 for ; Tue, 19 Jan 2010 14:50:33 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0JDoXR9012663 for ietf-provreg-outgoing; Tue, 19 Jan 2010 14:50:33 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JDoW0j004048 for ; Tue, 19 Jan 2010 14:50:33 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id F40862FE8CA1 for ; Tue, 19 Jan 2010 13:50:31 +0000 (UTC)
Date: Tue, 19 Jan 2010 08:50:30 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] new epp commands?
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References: <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Tue, Jan 19, 2010 at 08:31:58AM -0500, Hollenbeck, Scott wrote:
> It was most definitely a deliberate decision. The primary reason was
> because many people felt that this type of reporting feature would be
> out of place in a provisioning protocol due to the large amount of data
> that could be returned.

Also, there was another IETF working group aiming to solve that
problem, IIRC. CRISP produced IRIS. I'm not aware of any
implementations, however.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JDZuK3029051 for ; Tue, 19 Jan 2010 14:35:56 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0JDZueu008185 for ietf-provreg-outgoing; Tue, 19 Jan 2010 14:35:56 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JDZtsW003562 for ; Tue, 19 Jan 2010 14:35:55 +0100 (MET)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnsAAA9EVUuQ/uCWe2dsb2JhbACbfQEBFiQGpUSVEYQzBA
X-IronPort-AV: E=Sophos;i="4.49,303,1262563200"; d="scan'208";a="2569038"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 19 Jan 2010 13:06:31 +0000
Received: from [192.165.72.14] (ams3-vpn-dhcp5252.cisco.com [10.61.84.131]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0JDZsnV027300; Tue, 19 Jan 2010 13:35:55 GMT
Subject: Re: [ietf-provreg] a question for the list
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=
In-Reply-To: <[email-masked]>
Date: Tue, 19 Jan 2010 14:35:54 +0100
Cc: "'Andrew Sullivan'" , "'EPP Provreg'"
Message-Id: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
To: "Michael Young"
X-Mailer: Apple Mail (2.1077)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o0JDZtsW000527
Sender: [email-masked]
Precedence: bulk

On 19 jan 2010, at 13.54, Michael Young wrote:

> I think we need to separate
> discussions about updating the core protocol and consolidating efforts
> around extensions. Consolidating efforts around extensions seems like a
> reasonable goal in principal to me, changing a core protocol that in use
> supporting almost all of the internet is a much more serious objective that
> I think needs some serious justification (ie,that vital shortcomings cannot
> be addressed through extension work).

True, I agree with this view.

I have implemented epp from ground up for .SE, and working on extending for other TLDs

So here is a voice from a registrar that would support _some_ work on synchronization while the cost for even making changes is lower than what it will be to have eep + private extensions in every TLD in the world.

The goal I think should be to be able to use the same epp client and server implementation for more than one TLD.

Patrik

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JDX51j013645 for ; Tue, 19 Jan 2010 14:33:05 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0JDX5w1020027 for ietf-provreg-outgoing; Tue, 19 Jan 2010 14:33:05 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JDX4vJ028169 for ; Tue, 19 Jan 2010 14:33:04 +0100 (MET)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnsAAJdDVUuQ/uCWe2dsb2JhbACaXYEgAQEWJAalQZURhDME
X-IronPort-AV: E=Sophos;i="4.49,303,1262563200"; d="scan'208";a="56286953"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Jan 2010 13:33:04 +0000
Received: from [192.165.72.14] (ams3-vpn-dhcp5252.cisco.com [10.61.84.131]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0JDX4Jk026610; Tue, 19 Jan 2010 13:33:04 GMT
Subject: Re: [ietf-provreg] new epp commands?
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=
In-Reply-To: <[email-masked]>
Date: Tue, 19 Jan 2010 14:33:03 +0100
Cc: Ulrich Wisser , EPP Provreg
Message-Id: <[email-masked]>
References: <[email-masked]> <[email-masked]>
To: Jaap Akkerhuis
X-Mailer: Apple Mail (2.1077)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o0JDX4vJ012614
Sender: [email-masked]
Precedence: bulk

.SE is a thick registry, which means you have the data in reality both in the registry and the registar. Anything that can help ensuring the two databases are in sync is a good thing.

So yes, I would support such a command be standardized.

Patrik

On 19 jan 2010, at 13.08, Jaap Akkerhuis wrote:

> My two cents in-line
>
> here at .SE many registrars asked for lists of their
> domains/hosts/contacts. Obviously there are no commands in the standard
> to extract lists of objects from the epp server.
>
> These registrars don't have an administration on there own?
>
> Before proposing new commands I'd like to ask why there aren't any such
> commands? Has it been a deliberate decision or didn't just nobody ask
> for it?
>
> It has been deliberate not to turn EPP into yet another whois
> protocol. Also, not all registries do have this data because not
> all are "thick registries".
>
> jaap
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> List run by majordomo software. For (Un-)subscription and similar details
> send "help" to [email-masked]
>

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JDW0aj008896 for ; Tue, 19 Jan 2010 14:32:00 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0JDW0pt009513 for ietf-provreg-outgoing; Tue, 19 Jan 2010 14:32:00 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JDVx3D028484 for ; Tue, 19 Jan 2010 14:31:59 +0100 (MET)
Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o0JDDPUg002518; Tue, 19 Jan 2010 08:13:25 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 08:31:59 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [ietf-provreg] new epp commands?
Date: Tue, 19 Jan 2010 08:31:58 -0500
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] new epp commands?
Thread-Index: AcqY/sNAn8NUn2iaSIOqUK9xplw2kgADGLgg
References: <[email-masked]>
From: "Hollenbeck, Scott"
To: "Ulrich Wisser" , "EPP Provreg"
X-OriginalArrivalTime: 19 Jan 2010 13:31:59.0299 (UTC) FILETIME=[C6D49130:01CA990B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o0JDW03D028923
Sender: [email-masked]
Precedence: bulk

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Ulrich Wisser
> Sent: Tuesday, January 19, 2010 6:42 AM
> To: EPP Provreg
> Subject: [ietf-provreg] new epp commands?
>
> Hi,
>
> here at .SE many registrars asked for lists of their
> domains/hosts/contacts. Obviously there are no commands in
> the standard to extract lists of objects from the epp server.
>
> Before proposing new commands I'd like to ask why there
> aren't any such commands? Has it been a deliberate decision
> or didn't just nobody ask for it?

It was most definitely a deliberate decision. The primary reason was
because many people felt that this type of reporting feature would be
out of place in a provisioning protocol due to the large amount of data
that could be returned.

Scott

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JCsExR018251 for ; Tue, 19 Jan 2010 13:54:14 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0JCsESN015896 for ietf-provreg-outgoing; Tue, 19 Jan 2010 13:54:14 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JCsDaS011278 for ; Tue, 19 Jan 2010 13:54:13 +0100 (MET)
From: "Michael Young"
To: "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" , "'Andrew Sullivan'"
Cc: "'EPP Provreg'"
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Subject: RE: [ietf-provreg] a question for the list
Date: Tue, 19 Jan 2010 07:54:10 -0500
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcqY6bJRIP6zM+NLQBCP28F8dhDaRAAG0nVw
Content-Language: en-us
X-Authenticated: True
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o0JCsEaS020914
Sender: [email-masked]
Precedence: bulk

Perhaps what we need here is an equivalent to DNSOPs for EPP (EPPOPs)? I
can't help but think that if we were talking about this level of change with
DNS, more than a few operators would get very concerned.

Let's remember that an EPPv2 costs registrars money and time to implement
plus there's risk to changing a core protocol. I think we need to separate
discussions about updating the core protocol and consolidating efforts
around extensions. Consolidating efforts around extensions seems like a
reasonable goal in principal to me, changing a core protocol that in use
supporting almost all of the internet is a much more serious objective that
I think needs some serious justification (ie,that vital shortcomings cannot
be addressed through extension work).

Also, we need a representative sample of registrars to weigh in before we
could consider proceeding, after all, they are the client side of this
protocol and their entire infrastructure stands to be effected at some real
$$$ cost.

IMHO, this conversation is very different than building the first EPP
version, now we have real world infrastructure, security and stability to
consider as primary considerations to any core protocol changes.

Michael Young

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]]
Sent: Tuesday, January 19, 2010 2:20 AM
To: Andrew Sullivan
Cc: EPP Provreg
Subject: Re: [ietf-provreg] a question for the list

On 18 jan 2010, at 17.21, Patrik Fältström wrote:

> On 18 jan 2010, at 16.56, Andrew Sullivan wrote:
>
>> Since I'm playing devil's advocate, however (and let me emphasise that
>> I'm pushing mostly because I think the best way to make a strong
>> argument is to find all its weak points and press on them), where were
>> these voices when the protocol was moving along the standards track?
>
> In short, I did rise my voice exactly like this, but the document moved
forward, and I thought I was in the minority. I also explicitly then brought
up the issue that exist that some policy issues are not well defined, for
example on what a transfer (of a domain name) implies regarding sponsor of
the contact object that is the holder of the domain.
>
> The conclusion then was that epp _as_defined_ was implemented as nice and
clean and obviously works.
>
> The question now is whether we should do eppV2, so I think the questions
are different. Or, that I was told ;-)

Maybe my wording was badly phrased. And I feel I must clarify:

I do NOT think the move of epp to standard was wrong. The protocol is in
wide use. It is usable. We have multiple implementations.

I DO think we should do eppV2 because the deployment and implementation can
be better. I claim we can move more today developed extensions to epp to
become standard parts of the protocol -- and that way make deployment
easier.

Patrik

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JCZ0KN025859 for ; Tue, 19 Jan 2010 13:35:00 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0JCZ0IJ007029 for ietf-provreg-outgoing; Tue, 19 Jan 2010 13:35:00 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JCYx53008015 for ; Tue, 19 Jan 2010 13:34:59 +0100 (MET)
Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o0JCGN7f000721; Tue, 19 Jan 2010 07:16:23 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 07:34:57 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA9903.CF419E2E"
Subject: Re: [ietf-provreg] new epp commands?
Date: Tue, 19 Jan 2010 07:34:57 -0500
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] new epp commands?
Thread-Index: AcqZAvPsfupACDDkSbGsezusMbGBBAAANsBp
From: "Gould, James"
To: ,
Cc:
X-OriginalArrivalTime: 19 Jan 2010 12:34:57.0712 (UTC) FILETIME=[CF67D300:01CA9903]
Sender: [email-masked]
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA9903.CF419E2E
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Jaap,

I believe that this was by design. We use reports for providing this =
kind of information. Using the provisioning protocol as a query =
protocol for what could be lists of millions of objects is not a good =
use of the protocol.=20

JG

----- Original Message -----
From: [email-masked]
To: Ulrich Wisser
Cc: EPP Provreg
Sent: Tue Jan 19 07:08:39 2010
Subject: Re: [ietf-provreg] new epp commands?=20

My two cents in-line
=20
here at .SE many registrars asked for lists of their=20
domains/hosts/contacts. Obviously there are no commands in the =
standard=20
to extract lists of objects from the epp server.

These registrars don't have an administration on there own?
=20
Before proposing new commands I'd like to ask why there aren't any =
such=20
commands? Has it been a deliberate decision or didn't just nobody =
ask=20
for it?

It has been deliberate not to turn EPP into yet another whois
protocol. Also, not all registries do have this data because not
all are "thick registries".

jaap
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-
List run by majordomo software. For (Un-)subscription and similar =
details
send "help" to [email-masked]

------_=_NextPart_001_01CA9903.CF419E2E
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Re: [ietf-provreg] new epp commands?

Jaap,

I believe that this was by design.  We use reports for providing =
this kind of information.  Using the provisioning protocol as a =
query protocol for what could be lists of millions of objects is not a =
good use of the protocol.

JG

----- Original Message -----

From: [email-masked] =
<[email-masked]>

To: Ulrich Wisser <[email-masked]>

Cc: EPP Provreg <[email-masked]>

Sent: Tue Jan 19 07:08:39 2010

Subject: Re: [ietf-provreg] new epp commands?

My two cents in-line

here at .SE many registrars asked for lists of =
their

domains/hosts/contacts. Obviously there are no =
commands in the standard

to extract lists of objects from the epp server.

These registrars don't have an administration on there own?

Before proposing new commands I'd like to ask why =
there aren't any such

commands? Has it been a deliberate decision or didn't =
just nobody ask

for it?

It has been deliberate not to turn EPP into yet another whois

protocol. Also, not all registries do have this data because not

all are "thick registries".

jaap

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-

List run by majordomo software.  For (Un-)subscription and similar =
details

send "help" to [email-masked]

------_=_NextPart_001_01CA9903.CF419E2E--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JCLeNc008187 for ; Tue, 19 Jan 2010 13:21:40 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0JCLewZ018803 for ietf-provreg-outgoing; Tue, 19 Jan 2010 13:21:40 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from web4.internetx.de (gate2.mailgate.de [62.116.129.39]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JCLenf018273 for ; Tue, 19 Jan 2010 13:21:40 +0100 (MET)
Received: from marcoschrieck.rgb.intranetx.de (pizza.internetx.de [62.116.129.3]) by web4.internetx.de (8.13.8/8.13.8) with ESMTP id o0JCLbQa004181 for ; Tue, 19 Jan 2010 13:21:39 +0100
Received: from scotty by marcoschrieck.rgb.intranetx.de with local (Exim 4.69) (envelope-from ) id 1NXD5V-0002XE-Qz; Tue, 19 Jan 2010 13:21:37 +0100
Date: Tue, 19 Jan 2010 13:21:37 +0100
From: InterNetX - Marco Schrieck
To: [email-masked]
Cc: EPP Provreg
Subject: Re: [ietf-provreg] new epp commands?
Message-ID: <[email-masked]>
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <[email-masked]>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

Hi Ulrich,

for us as registrar it is very important to have such a list. We need
this to ensure that our system is working correct.

Most registries provide such lists via ftp or http. NASK (.PL) do this
via EPP commands. But if you have million of domains in an account
then the XML is very large and you may have problems with parsing it.
Or you limit the request and inquire the list step by step. This solution
has the problem that the list can changes while inquiring.

So for me the best way is an external list (with timestamp).

Regards
Marco

On Tue, Jan 19, 2010 at 12:41:48PM +0100, Ulrich Wisser wrote:
> Hi,
>
> here at .SE many registrars asked for lists of their
> domains/hosts/contacts. Obviously there are no commands in the standard
> to extract lists of objects from the epp server.
>
> Before proposing new commands I'd like to ask why there aren't any such
> commands? Has it been a deliberate decision or didn't just nobody ask
> for it?
>
> /Ulrich
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> List run by majordomo software. For (Un-)subscription and similar details
> send "help" to [email-masked]
>

--
Marco Schrieck
Bereichsleiter Entwicklung

InterNetX GmbH
Maximilianstr. 6
93047 Regensburg
Germany

Tel: +49 941 59559-0
Fax: +49 941 59579-050

Geschäftsführer/CEO: Thomas Mörz
Amtsgericht Regensburg, HRB 7142

ICQ: 232016987
GPG-Key: 0xB44D5EAE
GPG-Fingerprint: 8285 3373 9776 E21A 94B1 38B1 2E52 D28C B44D 5EAE

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JC8iRf002548 for ; Tue, 19 Jan 2010 13:08:44 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0JC8i6j018471 for ietf-provreg-outgoing; Tue, 19 Jan 2010 13:08:44 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [213.154.224.50]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JC8iWs016823 for ; Tue, 19 Jan 2010 13:08:44 +0100 (MET)
Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id o0JC8d7b003705; Tue, 19 Jan 2010 13:08:39 +0100 (CET) (envelope-from [email-masked])
Message-Id: <[email-masked]>
To: Ulrich Wisser
cc: EPP Provreg
Subject: Re: [ietf-provreg] new epp commands?
In-reply-to: <[email-masked]>
References: <[email-masked]>
Comments: In-reply-to Ulrich Wisser message dated "Tue, 19 Jan 2010 12:41:48 +0100."
Date: Tue, 19 Jan 2010 13:08:39 +0100
From: Jaap Akkerhuis
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (bartok.nlnetlabs.nl [127.0.0.1]); Tue, 19 Jan 2010 13:08:39 +0100 (CET)
X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, MISSING_MID autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bartok.nlnetlabs.nl
Sender: [email-masked]
Precedence: bulk

My two cents in-line

here at .SE many registrars asked for lists of their
domains/hosts/contacts. Obviously there are no commands in the standard
to extract lists of objects from the epp server.

These registrars don't have an administration on there own?

Before proposing new commands I'd like to ask why there aren't any such
commands? Has it been a deliberate decision or didn't just nobody ask
for it?

It has been deliberate not to turn EPP into yet another whois
protocol. Also, not all registries do have this data because not
all are "thick registries".

jaap
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JBfrPQ014828 for ; Tue, 19 Jan 2010 12:41:53 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0JBfrju003626 for ietf-provreg-outgoing; Tue, 19 Jan 2010 12:41:53 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from lvps87-230-32-221.dedicated.hosteurope.de (mail.publisher.de [87.230.32.221]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0JBfq8u016047 for ; Tue, 19 Jan 2010 12:41:52 +0100 (MET)
Received: (qmail 3420 invoked from network); 19 Jan 2010 11:41:52 +0000
Received: from gw.iis.se (HELO ulrich-wissers-macbook-pro.local) (212.247.14.38) by mail.publisher.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Jan 2010 11:41:52 +0000
Message-ID: <[email-masked]>
Date: Tue, 19 Jan 2010 12:41:48 +0100
From: Ulrich Wisser
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: EPP Provreg
Subject: [ietf-provreg] new epp commands?
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

Hi,

here at .SE many registrars asked for lists of their
domains/hosts/contacts. Obviously there are no commands in the standard
to extract lists of objects from the epp server.

Before proposing new commands I'd like to ask why there aren't any such
commands? Has it been a deliberate decision or didn't just nobody ask
for it?

/Ulrich
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0J7KAM7003957 for ; Tue, 19 Jan 2010 08:20:10 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0J7KAYV022368 for ietf-provreg-outgoing; Tue, 19 Jan 2010 08:20:10 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0J7K9Lw013468 for ; Tue, 19 Jan 2010 08:20:09 +0100 (MET)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AsQAAMHrVEuQ/uCWe2dsb2JhbACbfwEBFiQGpAqVCIQzBA
X-IronPort-AV: E=Sophos;i="4.49,302,1262563200"; d="scan'208";a="56272952"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Jan 2010 07:20:09 +0000
Received: from [192.165.72.14] (dhcp-10-55-80-243.cisco.com [10.55.80.243]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0J7K8NY004184; Tue, 19 Jan 2010 07:20:09 GMT
Subject: Re: [ietf-provreg] a question for the list
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=
In-Reply-To:
Date: Tue, 19 Jan 2010 08:20:07 +0100
Cc: EPP Provreg
Message-Id: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
To: Andrew Sullivan
X-Mailer: Apple Mail (2.1077)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o0J7K9Lw005280
Sender: [email-masked]
Precedence: bulk

On 18 jan 2010, at 17.21, Patrik Fältström wrote:

> On 18 jan 2010, at 16.56, Andrew Sullivan wrote:
>
>> Since I'm playing devil's advocate, however (and let me emphasise that
>> I'm pushing mostly because I think the best way to make a strong
>> argument is to find all its weak points and press on them), where were
>> these voices when the protocol was moving along the standards track?
>
> In short, I did rise my voice exactly like this, but the document moved forward, and I thought I was in the minority. I also explicitly then brought up the issue that exist that some policy issues are not well defined, for example on what a transfer (of a domain name) implies regarding sponsor of the contact object that is the holder of the domain.
>
> The conclusion then was that epp _as_defined_ was implemented as nice and clean and obviously works.
>
> The question now is whether we should do eppV2, so I think the questions are different. Or, that I was told ;-)

Maybe my wording was badly phrased. And I feel I must clarify:

I do NOT think the move of epp to standard was wrong. The protocol is in wide use. It is usable. We have multiple implementations.

I DO think we should do eppV2 because the deployment and implementation can be better. I claim we can move more today developed extensions to epp to become standard parts of the protocol -- and that way make deployment easier.

Patrik

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0J4Aluv026045 for ; Tue, 19 Jan 2010 05:10:47 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0J4Al4k023287 for ietf-provreg-outgoing; Tue, 19 Jan 2010 05:10:47 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.130]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0J4Akcd011420 for ; Tue, 19 Jan 2010 05:10:46 +0100 (MET)
Received: from limpet.local (static-72-8-47-126.roc.onecommunications.net [72.8.47.126]) by abenaki.wabanaki.net (8.14.3/8.14.3) with ESMTP id o0J4485l095877; Mon, 18 Jan 2010 23:04:08 -0500 (EST) (envelope-from [email-masked])
Message-ID: <[email-masked]>
Date: Mon, 18 Jan 2010 23:10:40 -0500
From: Eric Brunner-Williams
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
To: "Hollenbeck, Scott"
CC: [email-masked], [email-masked]
Subject: Re: [ietf-provreg] Default contact element disclosure problem - RFC bug?
References: <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

Yup. I'll do that tomorrow. I didn't suggest the other feature.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0J3gsCB005526 for ; Tue, 19 Jan 2010 04:42:54 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0J3gs0Z017562 for ietf-provreg-outgoing; Tue, 19 Jan 2010 04:42:54 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0J3grTk020538 for ; Tue, 19 Jan 2010 04:42:53 +0100 (MET)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o0J3OJr8009674; Mon, 18 Jan 2010 22:24:19 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 22:42:52 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [ietf-provreg] Default contact element disclosure problem - RFC bug?
Date: Mon, 18 Jan 2010 22:42:51 -0500
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] Default contact element disclosure problem - RFC bug?
Thread-Index: AcqYUxi1uCpFNegCS42RaWWeEoeSNgAZUcQg
References: <[email-masked]>
From: "Hollenbeck, Scott"
To: ,
X-OriginalArrivalTime: 19 Jan 2010 03:42:52.0310 (UTC) FILETIME=[7A621360:01CA98B9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o0J3gsTk015239
Sender: [email-masked]
Precedence: bulk

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Monday, January 18, 2010 10:05 AM
> To: [email-masked]
> Subject: [ietf-provreg] Default contact element disclosure
> problem - RFC bug?
>
> All,
>
> We're planning to change our contact disclosure default from
> "disclose everything" to "don't disclose anything" because of
> data privacy considerations. EPP already provides the
> "contact:disclose" element to override the server default.
>
> Because of the structure of the "contact:disclose" element,
> it is required on the client side to be aware of the default
> setting, so that the proper "overriding" elements can be put
> into the "contact:disclose"
> element. If the client is not aware of the default setting on
> the server, it couldn't identify whether "disclosed" or "undisclosed"
> elements are to be put into the "disclose" element.
>
> However, it seems that there is no way to announce the
> default disclosure policy to the client, even though it is
> mentioned in the RFC:
>
> RFC5733 says:
>
> A server operator announces a default disclosure policy when
> establishing a session with a client. When an object is created or
> updated, the client can specify contact attributes that require
> exceptional disclosure handling using an OPTIONAL
>
> element. Once set, disclosure preferences can be reviewed using a
>
> (most important piece of that snippet is the first sentence)
>
> However, looking at the schema definition of the greeting, as
> well as the examples, there's no way to actually perform that
> "announcement"
> during session establishment.
>
> The closest match is probably the "dcp" element - however,
> there's no element within that element that relates to
> announcing the "contact:disclose" policy. The "dcp" element
> as far as i understood does also relate to the global data
> collection policy, while the disclose policy of the contact
> would be specific to a certain object type, since there could
> be other defaults for different object types..
>
> So, is this a bug in the RFCs, or are we missing something?
> Any advice on how clients should detect the disclose policy
> of the server?

Alex,

Thye element *is* the mechanism used to announce the server
operator's default data collection policy. It may help to read up on the
W3C Platform for Privacy Preferences (P3P) work. That's the framework
we adopted and modified slightly for use in EPP at Eric
Brunner-Williams' request. Eric is much more familiar with that work
than I am, so I hope he can provide more info as needed.

Scott

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0IJ0JqU002072 for ; Mon, 18 Jan 2010 20:00:19 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0IJ0J9H003097 for ietf-provreg-outgoing; Mon, 18 Jan 2010 20:00:19 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0IJ0Ib4017213 for ; Mon, 18 Jan 2010 20:00:18 +0100 (MET)
Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o0IIfiJR027293; Mon, 18 Jan 2010 13:41:44 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 14:00:17 -0500
Received: from 10.169.80.6 ([10.169.80.6]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Jan 2010 19:00:16 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Mon, 18 Jan 2010 14:00:14 -0500
Subject: Re: [ietf-provreg] a question for the list
From: James Gould
To: Patrik =?ISO-8859-1?B?RuRsdHN0cvZt?= , Andrew Sullivan
CC: EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] a question for the list
Thread-Index: AcqYXhqT7GEIBqXCSMu5GqbrK99YRAAElzMI
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3346668015_2070361"
X-OriginalArrivalTime: 18 Jan 2010 19:00:17.0108 (UTC) FILETIME=[7939F140:01CA9870]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3346668015_2070361
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

I personally don=B9t believe that the creation of a large number of additiona=
l
mappings and extensions represents an issue with the base protocol, but mor=
e
of meeting one of the goals of the base protocol in being flexible. There
is no way that everyone could foresee all of the possible needs of a
provisioning system, so the ability to create mappings and extensions
without touching the base protocol is a huge benefit. I would like to see
as the goal of a working group be the following:

1. Identify the custom EPP mappings and extensions out there. Look for
overlap and for the potential of some of them moving up the standards track=
.
2. Identify common patterns followed in creating extensions and mappings an=
d
document them for consistency. For example, adding a new verb has been don=
e
by creating an extension to an empty update. I would call the pattern =B3New
EPP Verb=B2 or something like that :-)
3. Collaborate on additional mappings and extensions for the standards
track. I have a few that I would like to discuss around key management but
it would require a good cross-cutting representation of the EPP community.
4. Identify areas of improvement of the base protocol that could be
addressed by common conventions, extensions, or even on update to the base
protocol.

It would be good if each of us could recommend goal items that can be
clearly listed in the charter.

--=20

JG=20

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

=20
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior writte=
n
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

From: Patrik F=E4ltstr=F6m
Date: Mon, 18 Jan 2010 11:21:13 -0500
To: Andrew Sullivan
Cc: EPP Provreg
Subject: Re: [ietf-provreg] a question for the list

On 18 jan 2010, at 16.56, Andrew Sullivan wrote:

> Since I'm playing devil's advocate, however (and let me emphasise that
> I'm pushing mostly because I think the best way to make a strong
> argument is to find all its weak points and press on them), where were
> these voices when the protocol was moving along the standards track?

In short, I did rise my voice exactly like this, but the document moved
forward, and I thought I was in the minority. I also explicitly then brough=
t
up the issue that exist that some policy issues are not well defined, for
example on what a transfer (of a domain name) implies regarding sponsor of
the contact object that is the holder of the domain.

The conclusion then was that epp _as_defined_ was implemented as nice and
clean and obviously works.

The question now is whether we should do eppV2, so I think the questions ar=
e
different. Or, that I was told ;-)

Patrik

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

--B_3346668015_2070361
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] a question for the list

I personally don’t believe that the creation of a large number of ad=
ditional mappings and extensions represents an issue with the base protocol,=
but more of meeting one of the goals of the base protocol in being flexible=
.  There is no way that everyone could foresee all of the possible need=
s of a provisioning system, so the ability to create mappings and extensions=
without touching the base protocol is a huge benefit.  I would like to=
see as the goal of a working group be the following:

Identify the custom EPP mappings and extensions out =
there.  Look for overlap and for the potential of some of them moving u=
p the standards track.

Identify common patterns followed in creating extensions=
and mappings and document them for consistency.  For example, adding a=
new verb has been done by creating an extension to an empty update.  I=
would call the pattern “New EPP Verb” or something like that :-=
)

Collaborate on additional mappings and extensions for th=
e standards track.  I have a few that I would like to discuss around ke=
y management but it would require a good cross-cutting representation of the=
EPP community.

Identify areas of improvement of the base protocol that =
could be addressed by common conventions, extensions, or even on update to t=
he base protocol.

It would be good if each of us could recommend goal items that can be clear=
ly listed in the charter.

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

From: Patrik Fältströ=
;m <[email-masked]>

Date: Mon, 18 Jan 2010 11:21:13 -0500

To: Andrew Sullivan <[email-masked]<=
/a>>

Cc: EPP Provreg <ietf-provreg@caf=
ax.se>

Subject: Re: [ietf-provreg] a question for the list

On 18 jan 2010, at 16.56, Andrew Sullivan wrote:

> Since I'm playing devil's advocate, however (and let me emphasise that=

> I'm pushing mostly because I think the best way to make a strong

> argument is to find all its weak points and press on them), where were=

> these voices when the protocol was moving along the standards track?

In short, I did rise my voice exactly like this, but the document moved for=
ward, and I thought I was in the minority. I also explicitly then brought up=
the issue that exist that some policy issues are not well defined, for exam=
ple on what a transfer (of a domain name) implies regarding sponsor of the c=
ontact object that is the holder of the domain.

The conclusion then was that epp _as_defined_ was implemented as nice and c=
lean and obviously works.

The question now is whether we should do eppV2, so I think the questions ar=
e different. Or, that I was told ;-)

Patrik

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=

List run by majordomo software.  For (Un-)subscription and similar det=
ails

send "help" to ietf-provr=
[email-masked]

--B_3346668015_2070361--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0IGLGh8018072 for ; Mon, 18 Jan 2010 17:21:16 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0IGLFix016077 for ietf-provreg-outgoing; Mon, 18 Jan 2010 17:21:15 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0IGLFSe014426 for ; Mon, 18 Jan 2010 17:21:15 +0100 (MET)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnQAAMMYVEuQ/uCWe2dsb2JhbACbfgEBFiQGpXyUCIQzBA
X-IronPort-AV: E=Sophos;i="4.49,297,1262563200"; d="scan'208";a="56258603"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 18 Jan 2010 16:21:14 +0000
Received: from [192.165.72.14] (ams3-vpn-dhcp443.cisco.com [10.61.65.187]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0IGLEnI016049; Mon, 18 Jan 2010 16:21:14 GMT
Subject: Re: [ietf-provreg] a question for the list
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=
In-Reply-To: <[email-masked]>
Date: Mon, 18 Jan 2010 17:21:13 +0100
Cc: "'EPP Provreg'"
Message-Id:
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
To: Andrew Sullivan
X-Mailer: Apple Mail (2.1077)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o0IGLFSe000639
Sender: [email-masked]
Precedence: bulk

On 18 jan 2010, at 16.56, Andrew Sullivan wrote:

> Since I'm playing devil's advocate, however (and let me emphasise that
> I'm pushing mostly because I think the best way to make a strong
> argument is to find all its weak points and press on them), where were
> these voices when the protocol was moving along the standards track?

In short, I did rise my voice exactly like this, but the document moved forward, and I thought I was in the minority. I also explicitly then brought up the issue that exist that some policy issues are not well defined, for example on what a transfer (of a domain name) implies regarding sponsor of the contact object that is the holder of the domain.

The conclusion then was that epp _as_defined_ was implemented as nice and clean and obviously works.

The question now is whether we should do eppV2, so I think the questions are different. Or, that I was told ;-)

Patrik

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0IFufor000537 for ; Mon, 18 Jan 2010 16:56:41 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0IFuf5C011454 for ietf-provreg-outgoing; Mon, 18 Jan 2010 16:56:41 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0IFueUP009104 for ; Mon, 18 Jan 2010 16:56:41 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id CE3A82FE8CA1 for ; Mon, 18 Jan 2010 15:56:39 +0000 (UTC)
Date: Mon, 18 Jan 2010 10:56:38 -0500
From: Andrew Sullivan
To: "'EPP Provreg'"
Subject: Re: [ietf-provreg] a question for the list
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , 'EPP Provreg'
References: <[email-masked]> <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Fri, Jan 15, 2010 at 09:50:53AM -0500, Edward Lewis wrote:
> I'd like to second what Eric mentions here - mostly because he and I
> have never discussed this in person before. For the most part, his list
> is dead-on the same as the one I wrote in my mind recently.

Ok, so I'm picking on Ed's message, but several people responded with
similar sorts of arguments, and one at least said an I-D is
forthcoming.

Since I'm playing devil's advocate, however (and let me emphasise that
I'm pushing mostly because I think the best way to make a strong
argument is to find all its weak points and press on them), where were
these voices when the protocol was moving along the standards track?
I recall submitting an I-D some time ago that argued for some fairly
major changes, some of which were intended to address these issues,
before any movement had happened. It seemed to me then (as it does
now) that the time to make incompatible changes to a protocol is
before it moves to Draft Standard, not after it has been declared an
Internet Standard. So I thought I'd propose a number of changes that
I would have found useful, in the hopes of opening a discussion about
the issues.

The response at the time was overwhelmingly that we had EPP, it was
mostly working, and nobody had the energy or interest to open it up to
make it perfect. Sure, there were issues, but this was the one we had
and so it would be good enough. Moreover, some said, any attempt to
add a new protocol would surely, for ICANN-constrained registries,
entail running more than one protocol in parallel, which either means
that you're stuck with the functionality actually available or else
that you have to kludge things up to make them backward compatible.
Finally, there was a side chorus claiming that, given the wide
variation in EPP implementations and extensions, EPP isn't really a
protocol anyway and that therefore "improving" it wouldn't work.

What has changed to make those arguments less compelling now that EPP
has become an Internet Standard?

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0IF5kiw002595 for ; Mon, 18 Jan 2010 16:05:46 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0IF5kQr011511 for ietf-provreg-outgoing; Mon, 18 Jan 2010 16:05:46 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from na.nona.net (engine01.malakii.net [188.40.65.119]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0IF5kUm019761 for ; Mon, 18 Jan 2010 16:05:46 +0100 (MET)
Received: from [10.10.0.133] ([::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by kahua with esmtp; Mon, 18 Jan 2010 16:05:45 +0100 id 0000000000154713.000000004B5478C9.00002B7A
Message-ID: <[email-masked]>
Date: Mon, 18 Jan 2010 16:05:07 +0100
From: [email-masked]
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: [email-masked]
Subject: [ietf-provreg] Default contact element disclosure problem - RFC bug?
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

All,

We're planning to change our contact disclosure default from "disclose
everything" to "don't disclose anything" because of data privacy
considerations. EPP already provides the "contact:disclose" element to
override the server default.

Because of the structure of the "contact:disclose" element, it is
required on the client side to be aware of the default setting, so that
the proper "overriding" elements can be put into the "contact:disclose"
element. If the client is not aware of the default setting on the
server, it couldn't identify whether "disclosed" or "undisclosed"
elements are to be put into the "disclose" element.

However, it seems that there is no way to announce the default
disclosure policy to the client, even though it is mentioned in the RFC:

RFC5733 says:

A server operator announces a default disclosure policy when
establishing a session with a client. When an object is created or
updated, the client can specify contact attributes that require
exceptional disclosure handling using an OPTIONAL
element. Once set, disclosure preferences can be reviewed using a

(most important piece of that snippet is the first sentence)

However, looking at the schema definition of the greeting, as well as
the examples, there's no way to actually perform that "announcement"
during session establishment.

The closest match is probably the "dcp" element - however, there's no
element within that element that relates to announcing the
"contact:disclose" policy. The "dcp" element as far as i understood does
also relate to the global data collection policy, while the disclose
policy of the contact would be specific to a certain object type, since
there could be other defaults for different object types..

So, is this a bug in the RFCs, or are we missing something? Any advice
on how clients should detect the disclose policy of the server?

Thanks,

Alex Mayrhofer
Team lead R&D nic.at

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0FF7h3g010503 for ; Fri, 15 Jan 2010 16:07:43 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0FF7h7H000467 for ietf-provreg-outgoing; Fri, 15 Jan 2010 16:07:43 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0FF7ha2001183 for ; Fri, 15 Jan 2010 16:07:43 +0100 (MET)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApAAANoTUEuQ/uCWe2dsb2JhbACcAgEBFiQGp2iVA4QxBIMf
X-IronPort-AV: E=Sophos;i="4.49,282,1262563200"; d="scan'208";a="56190289"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 15 Jan 2010 15:07:43 +0000
Received: from [10.130.4.40] (ams3-vpn-dhcp5926.cisco.com [10.61.87.37]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0FF7gXp010943; Fri, 15 Jan 2010 15:07:42 GMT
Subject: Re: [ietf-provreg] a question for the list
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=
In-Reply-To: <[email-masked]>
Date: Fri, 15 Jan 2010 16:07:41 +0100
Cc: "EPP Provreg"
Message-Id: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
To: "Marc Groeneweg"
X-Mailer: Apple Mail (2.1077)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o0FF7ha2019904
Sender: [email-masked]
Precedence: bulk

On 15 jan 2010, at 09.34, Marc Groeneweg wrote:

> Agreed. SIDN as the Dutch registry is implementing EPP at this very
> moment. We are going live in March this year. During the development
> phase, we have consulted several registries to try to stay in line with
> those regarding EPP and extensions.

And, btw, not all TLDs have publicised documentation for their extensions. .EU require actual payment of the fee to become a registrar before you get the technical documentation. Sure, there is a Net::DRI support for .EU, which one can reverse engineer, but if one would like to know what the details are? Pay first, then you get to know whether you actually are interested in doing it.

Interesting business model.

And, if I am wrong and documentation for .EU exists out there. My apologies (if I get documentation sent to me ;-) ). Enough people have though asked me, and looked for it, that I do not think it exists.

Patrik

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0FEp0c5020317 for ; Fri, 15 Jan 2010 15:51:00 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0FEp0Y5012256 for ietf-provreg-outgoing; Fri, 15 Jan 2010 15:51:00 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0FEoxUT003426 for ; Fri, 15 Jan 2010 15:50:59 +0100 (MET)
Received: from [10.31.200.189] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0FEothU085617; Fri, 15 Jan 2010 09:50:56 -0500 (EST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Date: Fri, 15 Jan 2010 09:50:53 -0500
To: "'EPP Provreg'"
From: Edward Lewis
Subject: Re: [ietf-provreg] a question for the list
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20
Sender: [email-masked]
Precedence: bulk

I'd like to second what Eric mentions here - mostly because he and I
have never discussed this in person before. For the most part, his
list is dead-on the same as the one I wrote in my mind recently.

It's not just the extensions that are being written. It's the angst
of the growing community I hear. (See also PAF's note).

At 2:38 -0500 1/15/10, Eric Brunner-Williams wrote:
>Our universe was 6 and 60. It is now 60 and 600.
>
>We over constrained the end points, and the event model.
>
>We over constrained the transport mappings, the drop pool is an edge
>case, not the general case.
>
>We didn't generalize the syntax to allow "containers" (Zhang/Damaraju).
>
>The syntax wasn't really all that extensible.
>
>We didn't include resellers/members in the end points model, and
>therefore we didn't include routing, settlement, giveup, pricing
>query or subaccounts in the use cases.
>
>Eric

But - next week I hope to cobble together a more complete work load
list/charter prototype. (If no one else does one first. ;))
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0F8Yxb7007746 for ; Fri, 15 Jan 2010 09:34:59 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0F8YxP9025043 for ietf-provreg-outgoing; Fri, 15 Jan 2010 09:34:59 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0F8Ywkn004664 for ; Fri, 15 Jan 2010 09:34:58 +0100 (MET)
Received: from sidn.nl ([192.168.2.9]) by ede1-kamx.sidn.nl with ESMTP id o0F8YwFm006950 for ; Fri, 15 Jan 2010 09:34:58 +0100
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [ietf-provreg] a question for the list
Date: Fri, 15 Jan 2010 09:34:57 +0100
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] a question for the list
Thread-Index: AcqVqI/JNIe6RqxCS/KOQPaA5INRdwAE985A
References: <[email-masked]> <[email-masked]> <[email-masked]>
From: "Marc Groeneweg"
To: "EPP Provreg"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o0F8Yxkn027984
Sender: [email-masked]
Precedence: bulk

> From my perspective, there are too many extensions out there.
>
> A WG should:
>
> - Compile a list of extensions that are developed and used by
> registries
> - Evaluate whether any of those implies changes are needed to the core
> protocol
> - If changes are needed, roll those into the protocol itself
>
> All to make epp better and easier to use. It is not fun at the moment.

Agreed. SIDN as the Dutch registry is implementing EPP at this very
moment. We are going live in March this year. During the development
phase, we have consulted several registries to try to stay in line with
those regarding EPP and extensions. But we have made our own extension
to get domainnames out of quarantine (period after deleting a
domainname) and didn't follow the RRP extension of Verisign (considered
too complex for the job). No RFC planned though for this. Just like
several other registries, we have documented the differences with the
core protocol. I think that when you write an RFC for this, you should
ask yourself if it's going to contribute to all (not just for one
registry) and are we going to make a standard out of this.

The next planned release of our registry system should have a kind of
trade option (transfer and registrant change in one process), which
several other registries have, but which is different in implementation
from each other. The problem there might be in policies just like there
was in the transfer process.

Marc Groeneweg

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0F86n8T009551 for ; Fri, 15 Jan 2010 09:06:49 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0F86n9v000853 for ietf-provreg-outgoing; Fri, 15 Jan 2010 09:06:49 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0F86m1s029804 for ; Fri, 15 Jan 2010 09:06:48 +0100 (MET)
DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=xzOLMvchA2SMxBFuKmUbUVIIUjoixaQ811sFt9d1Km6XoDCyo4irH3e4 VQVqp8zuHbVv6hAS+z4kvUYFIgrXwEOaMoSPakdgYROI1oFmh3EJCgxtn ITzn8F0osGyRbiE;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=[email-masked]; q=dns/txt; s=main.dkim.nominet.selector; t=1263542808; x=1295078808; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=[email-masked]|Subject:=20Re:=20[ietf -provreg]=20a=20question=20for=20the=20list|Date:=20Fri, =2015=20Jan=202010=2008:06:47=20+0000|Message-ID:=20|To:=20Andrew=20Sullivan=20 |Cc:=20"'EPP=20Provreg'"=20 |MIME-Version:=201.0|In-Reply-To:=20<20100115034356.GB596 [email-masked]>|References:=20=20=20<0 [email-masked]>=20<201001150 [email-masked]>; bh=US6mo2WfU8lU27e9fiVNdTI28XiHAVY+Yj0C76X6YdE=; b=i0AozUmsZPCv/gQE1SIDcpDy/LmxcNW/9FbZBFWB9+LvET+ENammH4ft XOqqN1gPhkYOF6iFrIGmM9HLKEOAU3snbLWp9I6i5NvIdloeBlpdd7ts3 JG97oJr/kx0HFxj;
X-IronPort-AV: E=Sophos;i="4.49,281,1262563200"; d="scan'208";a="15557094"
Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 15 Jan 2010 08:06:48 +0000
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
To: Andrew Sullivan
Cc: "'EPP Provreg'"
Subject: Re: [ietf-provreg] a question for the list
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 8.5 December 05, 2008
Message-ID:
From: [email-masked]
Date: Fri, 15 Jan 2010 08:06:47 +0000
X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 15/01/2010 08:06:47 AM, Serialize complete at 15/01/2010 08:06:47 AM
Content-Type: multipart/alternative; boundary="=_alternative 002C9104802576AC_="
Sender: [email-masked]
Precedence: bulk

This is a multipart message in MIME format.
--=_alternative 002C9104802576AC_=
Content-Type: text/plain; charset="US-ASCII"

> Or, to put this more negatively, what possible reason is there for me
> not to stand up in the BOF and say, "There are no individual drafts,
> there is no real problem to be solved here, and therefore setting up
> a WG is a waste of the Area's time,"?

I plan to submit an individual draft for a proposed EPP extension within
the next few weeks.

Ray

--=_alternative 002C9104802576AC_=
Content-Type: text/html; charset="US-ASCII"

> Or, to put this more negatively, what possible reason
is there for me

> not to stand up in the BOF and say, "There
are no individual drafts,

> there is no real problem to be solved here, and
therefore setting up

> a WG is a waste of the Area's time,"?

I plan to submit an individual draft for a proposed
EPP extension within the next few weeks.

Ray

--=_alternative 002C9104802576AC_=--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0F7ciDk013597 for ; Fri, 15 Jan 2010 08:38:44 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0F7ciOB010401 for ietf-provreg-outgoing; Fri, 15 Jan 2010 08:38:44 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.130]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0F7ch7O001853 for ; Fri, 15 Jan 2010 08:38:43 +0100 (MET)
Received: from limpet.local (65-149.106-92.cust.bluewin.ch [92.106.149.65]) by abenaki.wabanaki.net (8.14.3/8.14.3) with ESMTP id o0F7X5Np057595; Fri, 15 Jan 2010 02:33:05 -0500 (EST) (envelope-from [email-masked])
Message-ID: <[email-masked]>
Date: Fri, 15 Jan 2010 02:38:35 -0500
From: Eric Brunner-Williams
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
To: Andrew Sullivan , "'EPP Provreg'"
Subject: Re: [ietf-provreg] a question for the list
References: <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

Our universe was 6 and 60. It is now 60 and 600.

We over constrained the end points, and the event model.

We over constrained the transport mappings, the drop pool is an edge
case, not the general case.

We didn't generalize the syntax to allow "containers" (Zhang/Damaraju).

The syntax wasn't really all that extensible.

We didn't include resellers/members in the end points model, and
therefore we didn't include routing, settlement, giveup, pricing query
or subaccounts in the use cases.

Eric

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0F5g8cT023812 for ; Fri, 15 Jan 2010 06:42:09 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0F5g8Pe009491 for ietf-provreg-outgoing; Fri, 15 Jan 2010 06:42:08 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0F5g87M026705 for ; Fri, 15 Jan 2010 06:42:08 +0100 (MET)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap8AAHiPT0uQ/uCWe2dsb2JhbACbeQEBFiQGpXmVGIQxBA
X-IronPort-AV: E=Sophos;i="4.49,280,1262563200"; d="scan'208";a="56173493"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 15 Jan 2010 05:42:08 +0000
Received: from [10.0.1.3] (dhcp-10-61-98-27.cisco.com [10.61.98.27]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0F5g6Zf026509; Fri, 15 Jan 2010 05:42:07 GMT
Subject: Re: [ietf-provreg] a question for the list
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=
In-Reply-To: <[email-masked]>
Date: Fri, 15 Jan 2010 07:42:05 +0200
Cc: "'EPP Provreg'"
Message-Id: <[email-masked]>
References: <[email-masked]> <[email-masked]>
To: Andrew Sullivan
X-Mailer: Apple Mail (2.1077)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o0F5g87M007350
Sender: [email-masked]
Precedence: bulk

On 15 jan 2010, at 05.43, Andrew Sullivan wrote:

> I'd like to know what
> problem we have that is actually going to be solved.

>From my perspective, there are too many extensions out there.

A WG should:

- Compile a list of extensions that are developed and used by registries
- Evaluate whether any of those implies changes are needed to the core protocol
- If changes are needed, roll those into the protocol itself

All to make epp better and easier to use. It is not fun at the moment.

Patrik

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0F3i02W000817 for ; Fri, 15 Jan 2010 04:44:00 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0F3i0Qu011178 for ietf-provreg-outgoing; Fri, 15 Jan 2010 04:44:00 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0F3hxAZ012727 for ; Fri, 15 Jan 2010 04:43:59 +0100 (MET)
Received: from crankycanuck.ca (unknown [12.176.20.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 490E62FE8CA1 for ; Fri, 15 Jan 2010 03:43:58 +0000 (UTC)
Date: Thu, 14 Jan 2010 22:43:56 -0500
From: Andrew Sullivan
To: "'EPP Provreg'"
Subject: Re: [ietf-provreg] a question for the list
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , 'EPP Provreg'
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Thu, Jan 14, 2010 at 09:48:18PM -0500, Michael Young wrote:
> I second James' questions here, I am not sure a WG is required at this point
> but I'd like to see a proposed charter draft as a first step.

It seems to me that one of Ed's observations might have been a bit too
subtle for some who are less attuned to the IETF processes, so I
thought I'd try to make it more plain.

The DNSEXT WG has as one of its explicit current chartered work items
to move a very long list of RFCs along the standards track. Whenever
this comes up for review, people nod sagely, say it's all very
important, and say that it should be a charter item. Yet the moving
along in the standards track seems not to happen. Very few DNS RFCs
are at the level of STANDARD. For instance RFC 2181, easily among the
most important of the DNS RFCs I'd expect anyone interested in the
topic to have read, is only at Proposed Standard. RFC 1982, Serial
Number Arithmetic -- a terribly influential RFC even outside the DNS
-- also stopped at PS. IXFR is still PS (RFC 1995), as is Notify
(1996). I could go on, but I guess you get the picture.

By contrast, without any WG and without a great deal of fanfare, EPP
has become an Internet Standard. I remember confidently predicting at
one point in the past that EPP could never be a Standard because the
community was simply too small. I am delighted to have been wrong.

So, before anyone produces a draft charter, I'd like to know what
problem we have that is actually going to be solved. Never mind
charters and so on: if nobody has been interested enough in
documenting their extensions that they've bothered to write an
individual submission Internet Draft, what problem of any conceivable
interest will be solved by spinning up the considerable machinery
necessary actually to charter a working group? Or, to put this more
negatively, what possible reason is there for me not to stand up in
the BOF and say, "There are no individual drafts, there is no real
problem to be solved here, and therefore setting up a WG is a waste of
the Area's time,"?

None of this is to say I don't think there's work to be done (or do
think there's such work). What I think instead is that, if one wants
a WG, one had better have at least prima facie evidence of an
interested community. So if people are interested, let's see some
drafts.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0F2m9hn022774 for ; Fri, 15 Jan 2010 03:48:09 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0F2m9Ij010596 for ietf-provreg-outgoing; Fri, 15 Jan 2010 03:48:09 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0F2m7Bt003625 for ; Fri, 15 Jan 2010 03:48:07 +0100 (MET)
From: "Michael Young"
To: "'James Gould'" , "'Edward Lewis'" , "'EPP Provreg'"
References:
In-Reply-To:
Subject: RE: [ietf-provreg] a question for the list
Date: Thu, 14 Jan 2010 21:48:18 -0500
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0039_01CA9563.492C4760"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcqVPrsFx9vhz4QwRuGvNrA9tizxcwAC7rIgABCg6CA=
Content-Language: en-us
X-Authenticated: True
Sender: [email-masked]
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0039_01CA9563.492C4760
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

I second James' questions here, I am not sure a WG is required at this point
but I'd like to see a proposed charter draft as a first step.

Michael Young

From: James Gould [mailto:[email-masked]]
Sent: Thursday, January 14, 2010 1:51 PM
To: Edward Lewis; EPP Provreg
Subject: Re: [ietf-provreg] a question for the list

Edward,

I would like to know more about which extensions would go up the standards
track and what the goals of the WG would be. We have implemented a set of
custom extensions that might be of interest, but I'm really not sure. It
might be best to work on a charter first to determine if there is adequate
work to form a WG.

--

JG

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior written
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

_____

From: Edward Lewis
Date: Thu, 14 Jan 2010 12:03:19 -0500
To: EPP Provreg
Cc:
Subject: [ietf-provreg] a question for the list

It's been about 7 years since PROVREG WG closed and about 5 years
since the IETF has taken on a serious amount of registry-related work
(such as CRISP). In that time Scott has shepherded EPP's base
specification to Full Standard. By comparison, DNS's original RFCs
have been elevated to Full Standard without the current process, and
almost no extensions to DNS have progressed even to Draft Standard.
I say that to highlight the extent of Scott's effort and achievement.

Currently we have a draft proposing an update to RFC 4310 (DNSSEC in
EPP), I have been asked about "how to submit" another extension.
There have been a few other extensions published as RFCs.

EPP is also growing in deployments. Early it was the registration
protocol for the ICANN shared registry model but it has been
spreading to other registries that are not subject to ICANN's
overview. With less "evidence" on hand, a few registries have had to
modify something to get an EPP interface. I suspect that some of the
extensions have not been published as RFCs (which is fine, but, it
would be nice).

Based on this, I wanted to ask the audience of this list if they
thought it would be a good idea to organize a new WG to cover EPP. A
new WG would mean another mail list, as well as the other trappings -
drafts, charter, BoFs, etc.

I can imagine extensions being discussed here, as well as trying to
promote the existing ones to Draft and Full. Also, a document that
discusses what could have been done better in EPP (as maybe a
requirements to EPP 2.0).

So - the question here is - is there interest?

Ultimately, there are other registry-specific things to discuss these
days, discussions that currently have no other appropriate home.
Such as - getting DNSSEC information into a registry in a generalized
environment.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

------=_NextPart_000_0039_01CA9563.492C4760
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Re: [ietf-provreg] a question for the list

I second James’ questions here, I am not sure a WG =
is required
at this point but I’d like to see a proposed charter draft as a =
first step.

Michael Young

From:=
James =
Gould
[mailto:[email-masked]]

Sent: Thursday, January 14, 2010 1:51 PM

To: Edward Lewis; EPP Provreg

Subject: Re: [ietf-provreg] a question for the =
list

Edward,

I would like to know more about which extensions would go up the =
standards
track and what the goals of the WG would be.  We have implemented a =
set of
custom extensions that might be of interest, but I’m really not =
sure.  It
might be best to work on a charter first to determine if there is =
adequate work
to form a WG.

--

JG

-------------------------------------------------------
=

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient: =
This e-mail =
contains
confidential, proprietary and/or Registry  Sensitive information =
intended
solely for the recipient and, thus may not be  retransmitted, =
reproduced
or disclosed without the prior written consent of  VeriSign Naming =
and Directory
Services.  If you have received  this e-mail message in =
error,
please notify the sender immediately by  telephone or reply e-mail =
and
destroy the original message without making a  copy. =
Thank you.

=

From: Edward Lewis <[email-masked]>

Date: Thu, 14 Jan 2010 12:03:19 -0500

To: EPP Provreg <[email-masked]>

Cc: <[email-masked]>

Subject: [ietf-provreg] a question for the list

It's been about 7 years since PROVREG WG closed and about 5 years

since the IETF has taken on a serious amount of registry-related =
work

(such as CRISP).  In that time Scott has shepherded EPP's base

specification to Full Standard.  By comparison, DNS's original =
RFCs

have been elevated to Full Standard without the current process, and

almost no extensions to DNS have progressed even to Draft Standard.

I say that to highlight the extent of Scott's effort and =
achievement.

Currently we have a draft proposing an update to RFC 4310 (DNSSEC in

EPP), I have been asked about "how to submit" another =
extension.

There have been a few other extensions published as RFCs.

EPP is also growing in deployments.  Early it was the =
registration

protocol for the ICANN shared registry model but it has been

spreading to other registries that are not subject to ICANN's

overview.  With less "evidence" on hand, a few registries =
have
had to

modify something to get an EPP interface.  I suspect that some of =
the

extensions have not been published as RFCs (which is fine, but, it

would be nice).

Based on this, I wanted to ask the audience of this list if they

thought it would be a good idea to organize a new WG to cover EPP. =
A

new WG would mean another mail list, as well as the other trappings =
-

drafts, charter, BoFs, etc.

I can imagine extensions being discussed here, as well as trying to

promote the existing ones to Draft and Full.  Also, a document =
that

discusses what could have been done better in EPP (as maybe a

requirements to EPP 2.0).

So - the question here is - is there interest?

Ultimately, there are other registry-specific things to discuss =
these

days, discussions that currently have no other appropriate home.

Such as - getting DNSSEC information into a registry in a =
generalized

environment.

--

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-

Edward Lewis

NeuStar
&=
nbsp;      You
can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces =
is

that they're not getting traction.

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-

List run by majordomo software.  For (Un-)subscription and similar =
details

send "help" to [email-masked]<=
br>

------=_NextPart_000_0039_01CA9563.492C4760--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0EIog77026278 for ; Thu, 14 Jan 2010 19:50:42 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0EIogTu008539 for ietf-provreg-outgoing; Thu, 14 Jan 2010 19:50:42 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0EIofUq028140 for ; Thu, 14 Jan 2010 19:50:42 +0100 (MET)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o0EIk7SU029216; Thu, 14 Jan 2010 13:46:07 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 13:50:40 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Thu, 14 Jan 2010 18:50:40 +0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Thu, 14 Jan 2010 13:50:37 -0500
Subject: Re: [ietf-provreg] a question for the list
From: James Gould
To: Edward Lewis , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] a question for the list
Thread-Index: AcqVPrsFx9vhz4QwRuGvNrA9tizxcwAC7rIg
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3346321837_50615390"
X-OriginalArrivalTime: 14 Jan 2010 18:50:40.0793 (UTC) FILETIME=[78104090:01CA954A]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3346321837_50615390
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Edward,

I would like to know more about which extensions would go up the standards
track and what the goals of the WG would be. We have implemented a set of
custom extensions that might be of interest, but I=B9m really not sure. It
might be best to work on a charter first to determine if there is adequate
work to form a WG.=20

--=20

JG=20

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

=20
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior writte=
n
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

From: Edward Lewis
Date: Thu, 14 Jan 2010 12:03:19 -0500
To: EPP Provreg
Cc:
Subject: [ietf-provreg] a question for the list

It's been about 7 years since PROVREG WG closed and about 5 years
since the IETF has taken on a serious amount of registry-related work
(such as CRISP). In that time Scott has shepherded EPP's base
specification to Full Standard. By comparison, DNS's original RFCs
have been elevated to Full Standard without the current process, and
almost no extensions to DNS have progressed even to Draft Standard.
I say that to highlight the extent of Scott's effort and achievement.

Currently we have a draft proposing an update to RFC 4310 (DNSSEC in
EPP), I have been asked about "how to submit" another extension.
There have been a few other extensions published as RFCs.

EPP is also growing in deployments. Early it was the registration
protocol for the ICANN shared registry model but it has been
spreading to other registries that are not subject to ICANN's
overview. With less "evidence" on hand, a few registries have had to
modify something to get an EPP interface. I suspect that some of the
extensions have not been published as RFCs (which is fine, but, it
would be nice).

Based on this, I wanted to ask the audience of this list if they
thought it would be a good idea to organize a new WG to cover EPP. A
new WG would mean another mail list, as well as the other trappings -
drafts, charter, BoFs, etc.

I can imagine extensions being discussed here, as well as trying to
promote the existing ones to Draft and Full. Also, a document that
discusses what could have been done better in EPP (as maybe a
requirements to EPP 2.0).

So - the question here is - is there interest?

Ultimately, there are other registry-specific things to discuss these
days, discussions that currently have no other appropriate home.
Such as - getting DNSSEC information into a registry in a generalized
environment.
--
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

--B_3346321837_50615390
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] a question for the list

Edward,

I would like to know more about which extensions would go up the standards =
track and what the goals of the WG would be.  We have implemented a set=
of custom extensions that might be of interest, but I’m really not su=
re.  It might be best to work on a charter first to determine if there =
is adequate work to form a WG.

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

From: Edward Lewis <[email-masked]>

Date: Thu, 14 Jan 2010 12:03:19 -0500

To: EPP Provreg <ietf-provreg@caf=
ax.se>

Cc: <[email-masked]><=
BR>
Subject: [ietf-provreg] a question for the list

It's been about 7 years since PROVREG WG closed and about 5 years

since the IETF has taken on a serious amount of registry-related work

(such as CRISP).  In that time Scott has shepherded EPP's base

specification to Full Standard.  By comparison, DNS's original RFCs
have been elevated to Full Standard without the current process, and

almost no extensions to DNS have progressed even to Draft Standard.

I say that to highlight the extent of Scott's effort and achievement.

Currently we have a draft proposing an update to RFC 4310 (DNSSEC in

EPP), I have been asked about "how to submit" another extension.<=
BR>
There have been a few other extensions published as RFCs.

EPP is also growing in deployments.  Early it was the registration

protocol for the ICANN shared registry model but it has been

spreading to other registries that are not subject to ICANN's

overview.  With less "evidence" on hand, a few registries ha=
ve had to

modify something to get an EPP interface.  I suspect that some of the<=
BR>
extensions have not been published as RFCs (which is fine, but, it

would be nice).

Based on this, I wanted to ask the audience of this list if they

thought it would be a good idea to organize a new WG to cover EPP.  A<=
BR>
new WG would mean another mail list, as well as the other trappings -

drafts, charter, BoFs, etc.

I can imagine extensions being discussed here, as well as trying to

promote the existing ones to Draft and Full.  Also, a document that
discusses what could have been done better in EPP (as maybe a

requirements to EPP 2.0).

So - the question here is - is there interest?

Ultimately, there are other registry-specific things to discuss these

days, discussions that currently have no other appropriate home.

Such as - getting DNSSEC information into a registry in a generalized

environment.

--

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=

Edward Lewis

NeuStar            &=
nbsp;       You can leave a voice message=
at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=

List run by majordomo software.  For (Un-)subscription and similar det=
ails

send "help" to ietf-provr=
[email-masked]

--B_3346321837_50615390--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0EIgwvr015756 for ; Thu, 14 Jan 2010 19:42:58 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0EIgwo6029244 for ietf-provreg-outgoing; Thu, 14 Jan 2010 19:42:58 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0EIgvCN010994 for ; Thu, 14 Jan 2010 19:42:57 +0100 (MET)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqgAAMj0TkuQ/uCWe2dsb2JhbACbdgEBFiQGqBSUdoQwBA
X-IronPort-AV: E=Sophos;i="4.49,276,1262563200"; d="scan'208";a="56159262"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Jan 2010 18:42:52 +0000
Received: from [10.0.1.3] (ams3-vpn-dhcp5514.cisco.com [10.61.85.137]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0EIgkdL019091; Thu, 14 Jan 2010 18:42:48 GMT
Subject: Re: [ietf-provreg] a question for the list
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=
In-Reply-To: <[email-masked]>
Date: Thu, 14 Jan 2010 20:42:43 +0200
Cc: Edward Lewis , [email-masked]
Content-Transfer-Encoding: 7bit
Message-Id: <[email-masked]>
References: <[email-masked]>
To: Eric Brunner-Williams
X-Mailer: Apple Mail (2.1077)
Sender: [email-masked]
Precedence: bulk

On 14 jan 2010, at 19.47, Eric Brunner-Williams wrote:

> Ed,
> I think so.

+1

paf

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0EHlwcU019317 for ; Thu, 14 Jan 2010 18:47:58 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0EHlwav022625 for ietf-provreg-outgoing; Thu, 14 Jan 2010 18:47:58 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.130]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0EHlv4V018115 for ; Thu, 14 Jan 2010 18:47:58 +0100 (MET)
Received: from [192.168.178.40] (44-143.76-83.cust.bluewin.ch [83.76.143.44]) by abenaki.wabanaki.net (8.14.3/8.14.3) with ESMTP id o0EHgTWQ051794; Thu, 14 Jan 2010 12:42:30 -0500 (EST) (envelope-from [email-masked])
Message-ID: <[email-masked]>
Date: Thu, 14 Jan 2010 12:47:55 -0500
From: Eric Brunner-Williams
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
To: Edward Lewis
CC: [email-masked]
Subject: Re: [ietf-provreg] a question for the list
References:
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

Ed,

I think so.

Eric
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0EH3T0I002995 for ; Thu, 14 Jan 2010 18:03:29 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o0EH3TX5026123 for ietf-provreg-outgoing; Thu, 14 Jan 2010 18:03:29 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o0EH3SbK013208 for ; Thu, 14 Jan 2010 18:03:28 +0100 (MET)
Received: from [10.31.200.252] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0EH3OA2077426; Thu, 14 Jan 2010 12:03:25 -0500 (EST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
Date: Thu, 14 Jan 2010 12:03:19 -0500
To: [email-masked]
From: Edward Lewis
Subject: [ietf-provreg] a question for the list
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20
Sender: [email-masked]
Precedence: bulk

It's been about 7 years since PROVREG WG closed and about 5 years
since the IETF has taken on a serious amount of registry-related work
(such as CRISP). In that time Scott has shepherded EPP's base
specification to Full Standard. By comparison, DNS's original RFCs
have been elevated to Full Standard without the current process, and
almost no extensions to DNS have progressed even to Draft Standard.
I say that to highlight the extent of Scott's effort and achievement.

Currently we have a draft proposing an update to RFC 4310 (DNSSEC in
EPP), I have been asked about "how to submit" another extension.
There have been a few other extensions published as RFCs.

EPP is also growing in deployments. Early it was the registration
protocol for the ICANN shared registry model but it has been
spreading to other registries that are not subject to ICANN's
overview. With less "evidence" on hand, a few registries have had to
modify something to get an EPP interface. I suspect that some of the
extensions have not been published as RFCs (which is fine, but, it
would be nice).

Based on this, I wanted to ask the audience of this list if they
thought it would be a good idea to organize a new WG to cover EPP. A
new WG would mean another mail list, as well as the other trappings -
drafts, charter, BoFs, etc.

I can imagine extensions being discussed here, as well as trying to
promote the existing ones to Draft and Full. Also, a document that
discusses what could have been done better in EPP (as maybe a
requirements to EPP 2.0).

So - the question here is - is there interest?

Ultimately, there are other registry-specific things to discuss these
days, discussions that currently have no other appropriate home.
Such as - getting DNSSEC information into a registry in a generalized
environment.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o01Lp2BX008067 for ; Fri, 1 Jan 2010 22:51:02 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o01Lp24B015766 for ietf-provreg-outgoing; Fri, 1 Jan 2010 22:51:02 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o01Lp1HL013430 for ; Fri, 1 Jan 2010 22:51:01 +0100 (MET)
Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o01LWGPm031384; Fri, 1 Jan 2010 16:33:01 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Jan 2010 16:50:21 -0500
Received: from 10.169.80.1 ([10.169.80.1]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Jan 2010 21:50:22 +0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Fri, 01 Jan 2010 16:50:19 -0500
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-01.txt Submitted for Review
From: James Gould
To: Klaus Malorny
CC: EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] draft-gould-rfc4310bis-01.txt Submitted for Review
Thread-Index: AcqD7rEbvC/B/8etS/63jSASCGf4vQANZrCkAcIHSV0=
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3345209421_34941505"
X-OriginalArrivalTime: 01 Jan 2010 21:50:21.0975 (UTC) FILETIME=[6AC75270:01CA8B2C]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3345209421_34941505
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

All,

I had to make a slight change to 02 to change the MUST to a SHOULD and to
add =B3and based on server policy=B2 with the sentence =B3In addition, the EPP
element SHOULD contain a child element that
identifies the extension namespace if the domain object has data associated
with this extension and based on server policy.=B2 Server policy has to be
considered in returning the secDNS information. I include this update in 0=
3
of the draft at the URL below. Please review for feedback.

http://www.ietf.org/id/draft-gould-rfc4310bis-03.txt

Thanks,

--=20

JG=20

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

=20
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior writte=
n
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

From: James Gould
Date: Wed, 23 Dec 2009 18:04:36 -0500
To: Klaus Malorny
Cc: EPP Provreg
Conversation: [ietf-provreg] draft-gould-rfc4310bis-01.txt Submitted for
Review
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-01.txt Submitted for
Review

Klaus,

I incorporated your feedback in 02 of the draft at the URL below. Please
review for feedback.

http://www.ietf.org/id/draft-gould-rfc4310bis-02.txt

http://www.ietf.org/id/draft-gould-rfc4310bis-03.txt
--=20

JG=20

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

=20
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior writte=
n
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

From: Klaus Malorny
Date: Wed, 23 Dec 2009 11:40:35 -0500
To: James Gould
Cc: EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-01.txt Submitted for
Review

On 21/12/09 19:13, James Gould wrote:
> Klaus,
> [...]

>> While a standard should be concise, it should avoid implicit
> assumptions in my
>> humble opinion. Maybe I am wrong, but I can't remember that RFC 5730
> or RFC
>> 3735
>> say anything about the semantics of not including a certain extension.
> Also,
>> giving the existence of an extension element any meaning limits the
> forward
>> compatibility of the extension itself. For example, if someone thinks t=
o
>> extend
>> RFC 3915 to report something in addition to the , then t=
he
>> semantics of the infData element would have to be changed regarding the
>> existence.
>
> I=B9m really not sure if there is any defined extension points for an
> extension. I can add some global statement to the draft around the
> meaning of the inclusion or exclusion of the extension, where the
> remainder of the draft assumes that the extension is only included for
> commands or responses when there is data relevant to the extension to
> pass along with one or two examples. Does this meet your request?
>

Yes, this would be IMHO sufficient.

>> I cannot agree. RFC 2119 says regarding "MUST":
>>
>> 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
>> definition is an absolute requirement of the specification.
>>
>> Although I am not a native English speaker, this seems to be pretty
> clear to
>> me
>> that there may not exist any hidden assumptions. There is no
> comparative to
>> "absolute". And it is no excuse for me that other EPP related RFCs do t=
he
>> same.
>> Their wording has been the source for confusion more than once ;-)
>>
>
> I personally have not been confused, but does a global statement in the
> draft meet this request as well? I can=B9t change other RFC=B9s, so I will
> look to add some clarity in a global statement.

Yes, I think so.

>[...]
> JG

Regards,

Klaus

--B_3345209421_34941505
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] draft-gould-rfc4310bis-01.txt Submitted for Revie=
w

All,

I had to make a slight change to 02 to change the MUST to a SHOULD and to a=
dd “and based on server policy” with the sentence “In addi=
tion, the EPP <extension> element SHOULD contain a child <secDNS:in=
fData> element that identifies the extension namespace if the domain obje=
ct has data associated with this extension and based on server policy.”=
;  Server policy has to be considered in returning the secDNS informati=
on.  I include this update in 03 of the draft at the URL below.  P=
lease review for feedback.

http://www.i=
etf.org/id/draft-gould-rfc4310bis-03.txt

Thanks,

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

From: James Gould <[email-masked]>

Date: Wed, 23 Dec 2009 18:04:36 -0500

To: Klaus Malorny <Klaus.Malorny=
@knipp.de>

Cc: EPP Provreg <ietf-provreg@caf=
ax.se>

Conversation: [ietf-provreg] draft-gould-rfc4310bis-01.txt Submitted=
for Review

Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-01.txt Submitted =
for Review

Klaus,

I incorporated your feedback in 02 of the  draft at the URL below. &nb=
sp;Please review for feedback.

http://www.i=
etf.org/id/draft-gould-rfc4310bis-02.txt

http://www.i=
etf.org/id/draft-gould-rfc4310bis-03.txt

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

From: Klaus Malorny <[email-masked]>

Date: Wed, 23 Dec 2009 11:40:35 -0500

To: James Gould <[email-masked]=
m>

Cc: EPP Provreg <ietf-provreg@caf=
ax.se>

Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-01.txt Submitted =
for Review

On 21/12/09 19:13, James Gould wrote:

> Klaus,

> [...]

>>  While a standard should be concise, it should avoid implicit=

> assumptions in my

>>  humble opinion. Maybe I am wrong, but I can't remember that =
RFC 5730

> or RFC

>>  3735

>>  say anything about the semantics of not including a certain =
extension.

> Also,

>>  giving the existence of an extension element any meaning lim=
its the

> forward

>>  compatibility of the extension itself. For example, if someo=
ne thinks to

>>  extend

>>  RFC 3915 to report something in addition to the <rgp:rgpS=
tatus>, then the

>>  semantics of the infData element would have to be changed re=
garding the

>>  existence.

> I’m really not sure if there is any defined extension points for=
an

> extension. I can add some global statement to the draft around the

> meaning of the inclusion or exclusion of the extension, where the

> remainder of the draft assumes that the extension is only included for=

> commands or responses when there is data relevant to the extension to<=
BR>
> pass along with one or two examples. Does this meet your request?

Yes, this would be IMHO sufficient.

>>  I cannot agree. RFC 2119 says regarding "MUST":
>>

>>  1. MUST This word, or the terms "REQUIRED" or &quo=
t;SHALL", mean that the

>>  definition is an absolute requirement of the specification.<=
BR>

>>  Although I am not a native English speaker, this seems to be=
pretty

> clear to

>>  me

>>  that there may not exist any hidden assumptions. There is no=

> comparative to

>>  "absolute". And it is no excuse for me that other =
EPP related RFCs do the

>>  same.

>>  Their wording has been the source for confusion more than on=
ce ;-)

> I personally have not been confused, but does a global statement in th=
e

> draft meet this request as well? I can’t change other RFC’=
s, so I will

> look to add some clarity in a global statement.

Yes, I think so.

>[...]

> JG

Regards,

Klaus

--B_3345209421_34941505--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]