Subject: Real women love big dimensions

From: <[email-masked]>
Date: Tue, 30 Dec 2008 09:58:05 -0800 (PST)

Please do not reply to this email. To contact Armstrong Shank Advertising, please
visit us

This email message was sent to . If
you do not wish to receive further communications from Armstrong Shank Advertising,
click
here to unsubscribe.

If you've experience any difficulty
in being removed from a Armstrong Shank Advertising email list, click
here for personalized help.

Copyright Â© 2008 Armstrong Shank Advertising, Inc. All rights reserved.

7450 S Seneca, Haysville, KS 67060

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 mBU89wdp006473 for ; Tue, 30 Dec 2008 09:09:58 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBU89wE1008518 for ietf-provreg-outgoing; Tue, 30 Dec 2008 09:09: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 mBU89wYS012024 for ; Tue, 30 Dec 2008 09:09:58 +0100 (MET)
X-IronPort-AV: E=Sophos;i="4.36,300,1228089600"; d="scan'208";a="29706761"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 30 Dec 2008 08:09:49 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBU89nMu003474 for ; Tue, 30 Dec 2008 09:09:49 +0100
Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBU89nD2026241 for ; Tue, 30 Dec 2008 08:09:49 GMT
Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Dec 2008 09:09:49 +0100
Received: from [192.168.1.200] ([10.61.86.54]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Dec 2008 09:09:49 +0100
Message-Id:
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=
To: EPP Provreg
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: [ietf-provreg] epp in python?
Date: Tue, 30 Dec 2008 09:09:46 +0100
X-Mailer: Apple Mail (2.930.3)
X-OriginalArrivalTime: 30 Dec 2008 08:09:49.0137 (UTC) FILETIME=[FC1E2C10:01C96A55]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=271; t=1230624589; x=1231488589; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[email-masked]; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20
|Subject:=20epp=20in=20python? |Sender:=20; bh=yp+pivjTgWWUhshhlDnIL1fxiv8vE6WbZYkSoE15z7c=; b=nFw1vCmfvfqV55oajqMQ5dkoiB/shilGdoLoHeesSw8BbZUf9nA1Rlk/u1 gWNiZq2t9KKEvZ/kJ4ngcUfXfLj676sgC+M5sklMHy1xVGsP2RVGb+HnQvnf a/Q48lAl6d;
Authentication-Results: ams-dkim-1; header.From=[email-masked]; dkim=pass ( sig from cisco.com/amsdkim1002 verified; );
Sender: [email-masked]
Precedence: bulk

I have btw used the DRI library successfully, in perl, but has anyone
done anything in Python?

My favorite language at the moment is python, and I have to either use
the perl stuff from python, or rewrite the epp pieces I need in
Python, or...

Patrik

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 mBU0IniR009576 for ; Tue, 30 Dec 2008 01:18:49 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBU0InJd004387 for ietf-provreg-outgoing; Tue, 30 Dec 2008 01:18:49 +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 mBU0InNi012267 for ; Tue, 30 Dec 2008 01:18:49 +0100 (MET)
Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 1492B21; Tue, 30 Dec 2008 01:18:49 +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 iptOtUrWV075; Tue, 30 Dec 2008 01:18:47 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 413E635; Tue, 30 Dec 2008 01:18:47 +0100 (MEZ)
Received: from [127.0.0.1] (klaus@localhost [127.0.0.1]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id mBU0IjPY000203; Tue, 30 Dec 2008 01:18:46 +0100 (MEZ)
Message-ID: <[email-masked]>
Date: Tue, 30 Dec 2008 01:18:40 +0100
From: Klaus Malorny
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081228 Shredder/3.0b2pre
MIME-Version: 1.0
To: [email-masked]
CC: EPP Provreg
Subject: [ietf-provreg] Re:
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [email-masked]
Precedence: bulk

On 2008-12-30 00:32, [email-masked] wrote:
>
> Hello,
>
> my name is Ulrich and I am working for .SE (the Swedish registry). Among
> other other things I am responsible for the .SE EPP server.
>
> During the implementation of our EPP server (and client) I found the
> definition to be incomplete. I have no idea if this has
> already been discussed on the list? I haven't been able to find it in
> the archives. Please feel free to point me to any old discussion if
> applicable.
>
> For only keyTag can be specified. But DNSSec explicitly
> defines the keyTag to be *not* unique for a zone. Only algorithm an
> dkeyTag together are unique. Besides that it is possible to specify
> several DS records for the same key but with diffrent digestTypes.=20
>
> Currently due to the low depolyment of DNSSec and due to the fact that
> only one algorithm is required in DNSSec this is not really a problem,
> but it could become one in the future.
>
> Here at .SE we currently publish two DS records for every key, one with
> digest type SHA-1 and one with digest type SHA-256. (Try dnssec.se)
>
> My proposal would be to add two optional tags to the tag
>
>
>
>
> Which would be fully backward compatible, but still allow to be more
> precis if needed.
>
> Kind regards
>
> Ulrich

Hi Ulrich,

I discovered this issue back in 2005. I got two answers, one from Scott
Hollenbeck, vaguely referring me to some not further specified discussions on
the dnsop list and one from Ólafur Guđmundsson. Unfortunately, I couldn't find
the latter e-mail in the list archive, so I cannot point to this e-mail, but
have to quote it from my personal archive:

- - - 8< - - -
> * Using the 16 Bit key tag of the key to identify the DS/DNSKEY that
> should be removed from the domain is a bit risky having the probability
> in mind that more than one key has exactly this tag. DNSSEC never relies
> on the uniqueness of this tag.

First question: Who gets harmed
Answer: Registrant.

As the number of DS at any delegation is supposed to be small (<=5) the
probability of collision is low, as the keys pointed to by DS are supposed to be
strong it is real stupid to have keys that collide. In short this is going to be
infrequent if DS set is a replace operation then this is a non issue.
A smart registry is perfectly within the protocol bounds by refusing the a DS
that conflicts in the key_tag + alg, (or if the digest for two keys of the same
alg is the same).
- - - 8< - - -

Regards,

Klaus

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 mBTNWQ8R026052 for ; Tue, 30 Dec 2008 00:32:26 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBTNWQjA007584 for ietf-provreg-outgoing; Tue, 30 Dec 2008 00:32:26 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from publisher.de (lvps87-230-32-221.dedicated.hosteurope.de [87.230.32.221]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id mBTNWPTV022524 for ; Tue, 30 Dec 2008 00:32:25 +0100 (MET)
Date: Tue, 30 Dec 2008 00:32:25 +0100 (MET)
From: [email-masked]
Message-Id: <[email-masked]>
Received: (qmail 17982 invoked from network); 29 Dec 2008 23:32:25 +0000
Sender: [email-masked]
Precedence: bulk

Received: from p5b006002.dip.t-dialin.net (HELO ?192.168.2.103?) (91.0.96.2)
by lvps87-230-32-221.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 29 Dec 2008 23:32:24 +0000
Subject: definition
From: Ulrich Wisser
To: EPP Provreg
Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-6xtJpR9glNucMLPpIB5J"
Date: Tue, 30 Dec 2008 00:31:01 +0100
Message-Id: <1230593461.11548.311.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1

--=-6xtJpR9glNucMLPpIB5J
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Hello,

my name is Ulrich and I am working for .SE (the Swedish registry). Among
other other things I am responsible for the .SE EPP server.

During the implementation of our EPP server (and client) I found the
definition to be incomplete. I have no idea if this has
already been discussed on the list? I haven't been able to find it in
the archives. Please feel free to point me to any old discussion if
applicable.

For only keyTag can be specified. But DNSSec explicitly
defines the keyTag to be *not* unique for a zone. Only algorithm an
dkeyTag together are unique. Besides that it is possible to specify
several DS records for the same key but with diffrent digestTypes.=20

Currently due to the low depolyment of DNSSec and due to the fact that
only one algorithm is required in DNSSec this is not really a problem,
but it could become one in the future.

Here at .SE we currently publish two DS records for every key, one with
digest type SHA-1 and one with digest type SHA-256. (Try dnssec.se)

My proposal would be to add two optional tags to the tag

Which would be fully backward compatible, but still allow to be more
precis if needed.

Kind regards

Ulrich
=20

--=-6xtJpR9glNucMLPpIB5J
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFYjCCBV4w
ggNGoAMCAQICAwO40TANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL
ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp
dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNzA2MjMyMTI5MDdaFw0w
OTA2MjIyMTI5MDdaMFExFjAUBgNVBAMTDVVscmljaCBXaXNzZXIxNzA1BgkqhkiG9w0BCQEWKDJj
OWM4NWRhMTAzMmRmNDc2NTg5MGZjZWIxZDJmNGNjYTlkMTYxMGMwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCu0E1V+wRtD4Lnqu/NdOxsgNZHc6WvCH9+JMAvVTumjfMB6wIt686F76Mp
xC6xCxFno8pvAdOcosnzIErulQ7HFz7Hu75GKNZE8uhp5o1Fx0FbrpkfaGMJTabfXD6liFPSeXt2
E6Hts0HnAbiWqNPoo4Tk6K/I9lIWJr+FlpkHOBNMd2wVm7edwfjzt8wBnMwwFKAGp2CO+4rOdamm
WNRKOhUnlhZ88aOnLbvI5bjXHjOQy80TVG/mPBVmEBfcs2Tr5IqWvYvRli0BTsnLReOBudYKo99/
2i4V9pPncYVa+tprpnqmFlntetzUUJH7HHJzrKaQwvQC0d7XpzerezhxAgMBAAGjggEVMIIBETAM
BgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUg
Zm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzBABgNVHSUEOTA3Bggr
BgEFBQcDBAYIKwYBBQUHAwIGCisGAQQBgjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggr
BgEFBQcBAQQmMCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwMwYDVR0RBCww
KoEoMmM5Yzg1ZGExMDMyZGY0NzY1ODkwZmNlYjFkMmY0Y2NhOWQxNjEwYzANBgkqhkiG9w0BAQUF
AAOCAgEAiYpAf/5fXWJD1tB7YbZecUy9Ww6Y2y5MwTvIquEP36SuD70yOXOZ8sB2mt7sjuPeFmjw
kU2jHyYjmzGUochSk1bpd2VxGtfHKUUxl8BZyJ5UH8oGNHqgKiSXrpxkbSzzboS+7dbrL0va1zMg
xdgZS22HWjufwowEVKA/jUfyt8k1A2A7qNhZu8QUCOvH2SpP0dOwzhLmVFirUY/AH+CbvvkNFlJF
ocTOtloLFV78pB5M5lYJKcq/LzAHuOJr69mpLp46iZVte3ZqQsdtE/q1H+cvInA7vZs1mDyEIhag
RsKsIsDPVnEnzalaTO1cAKySgictdD/krK3KpS2Wdjnrxye8GaDRkHDlcnARQaCVzG+6BeC8MRtw
1POwcq0q7LJSvThfCAiw8DL7ya6+SrjSzKiQNyIDoaXDR6WmXs6/8AI++bFnperuhcoFX1nImLfy
QPuff8vGyv05o3d2GkJ8xS4CDHqNxkRQSWNwXYB5zVxipWmfFI9D0r0y3mY202a0JyZd9eVT0yAz
dMolC+MqCEpY+q7eBraBdfp5Ds3JYQaWIr+heJGaFSKgfCxYxMeUHK3DVOQZjMN7VBruo2D800+l
YKqON6b+ff5EP8qml+W7xMeRY7Qv1vDuIhN3TBVDtHnJS3lc6yN1WEf9toOl+4tfXkczp1d8g6xh
jisyn6wxggIHMIICAwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8v
d3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkq
hkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDA7jRMAkGBSsOAwIaBQCgXTAYBgkqhkiG9w0B
CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODEyMjkyMzMxMDFaMCMGCSqGSIb3DQEJ
BDEWBBTJ8K3lMYSkNGOw7OQfcdyRld5ptzANBgkqhkiG9w0BAQEFAASCAQB7Ztt5rRDW6KPkmNse
iCT8Xbvl2encdXTbLAIzBDI4NGVSbWfKOoxezgDJHN1RWvJjy3Dh6j+QJ6g7Y1ysHM0EgzuEHfqi
fCf6HkvrF6PbBRJHRbIPAVoAVrWrBoHhKtTDLvGTLr38dL8M4qtlRBF57VPTdn+rUKhny1gLr6Ha
7La3PyvXWa0anRo8Zd4RBtDgt8EQkwlrlhcPyvmwmq9igrKz6VQhsoZg6ZqnEPOOBQtgNZtz1JTc
UBHrTJkkGcdh3CBthuQulKdVLw2nh9lx8fTbpSx7BQQp85aZ4KXwMtyDU7cjraC011QI+z0dBZ1+
GT15JsTXzGAX5cp5/HlAAAAAAAAA

--=-6xtJpR9glNucMLPpIB5J--

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 mBTIAjMf009850 for ; Mon, 29 Dec 2008 19:10:45 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBTIAjWR020515 for ietf-provreg-outgoing; Mon, 29 Dec 2008 19:10: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 mBTIAjIL028392 for ; Mon, 29 Dec 2008 19:10:45 +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 46AEE2FE97ED for ; Mon, 29 Dec 2008 18:10:44 +0000 (UTC)
Date: Mon, 29 Dec 2008 13:10:42 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
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 Mon, Dec 29, 2008 at 10:31:24AM -0500, Edward Lewis wrote:

> What do you mean by "the private keys for the two sponsors?"
>
> Splitting hairs, the signing of DNS information happens after it leaves
> the database (of the registry) and before it hits what is currently known
> as the DNS (the master server). If a registrant has two operators for
> DNS (and many do), the operators are either both offering slave service
> or one is slaving off the other.
>
> IOW, if there are two sources of key-pairs for a domain name, there's
> trouble elsewhere.
>
> Maybe I don't understand the situation you have in mind.

Suppose I have RegA and RegB, and a registrant with example.org
sponsored by RegA. RegA also happens to be the DNS operator for
example.org. Example.org is signed.

If the registrant wants to move to RegB, there's a potential problem.
RegA operates the DNS, and therefore presumably has the private keys
for the current keying material corresponding to the DS record in
.org. There are a few possibilities I've thought of (in no particular
order):

1. Create new keys, publish them in RegA's DNS and as the DS in the
.org DNS, and then use those keys for RegB's DNS as well. This
requires the registrant to know something about DNS, I expect, and
also requires RegA to present an interface for registrant to send the
key information (and RegA may not have such an interface).

2. Get RegA to give the private key data to RegB. This is a bad idea
anyway, and anyway I doubt anyone would co-operate with it.

3. Co-ordinate the operation (independently) between RegA and RegB.
This requires that every DNSSEC-operating registrar in every registry
have some sort of bilateral communication with every other registrar.
I doubt this will work.

4. Make it possible for RegB to modify the DNS data of the domain
while the domain is pending transfer. This strikes me as a very
EPP-like way to do it: the gaining client initiated the transfer, then
sends the update command with the new name servers and key data to the
registry. The domain is in pendingUpdate _and_ pendingTransfer status
until the transfer is approved, at which point the updates
automatically happen. If the transfer is refused, then the update
fails as well. I _think_ this is compatible with the current RFCs,
but I'm not aware of any currently deployed code that works this way.

5. Go through an insecure phase

6. RegB obtains the necessary (public) key data from RegA and
publishes all of it in the RegB DNS. By carefully sequencing the
addition of additional records and removal of old ones, the domain
remains secure the whole time. This can be made to work today, but I
think it's a little fragile.

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

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 mBTFVYVT001113 for ; Mon, 29 Dec 2008 16:31:34 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBTFVYCs027569 for ietf-provreg-outgoing; Mon, 29 Dec 2008 16:31:34 +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 mBTFVW9D005569 for ; Mon, 29 Dec 2008 16:31:34 +0100 (MET)
Received: from [10.31.200.131] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id mBTFVUrm096003; Mon, 29 Dec 2008 10:31: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]>
Date: Mon, 29 Dec 2008 10:31:24 -0500
To: Andrew Sullivan
From: Edward Lewis
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
Cc: EPP Provreg
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4
Sender: [email-masked]
Precedence: bulk

At 9:44 -0500 12/29/08, Andrew Sullivan wrote:

>There's an additional issue in this area that's troubling to me, which
>has to do with domain transfers in a DNSSEC context, particularly in
>cases where the private keys for the two sponsors can't be shared
>(imagine the case where the two sponsors are each involved in
>operating the DNS for the target domain; in this case, they're not
>going to share private keys with one another). It seems to me that in
>such a case, a sponsor needs to be able to add a DS record to a domain
>object when the sponsor doesn't actually own the domain. This is
>problematic, because obviously we don't want random others being able
>to add properties to the objects one sponsors. It would be possible
>to allow this while a transfer is pending, but often there are various
>prohibitions on such a domain, and perhaps those will conflict with
>the ability of the gaining sponsor to add properties to the
>prospectively-transferred domain. Thoughts?

What do you mean by "the private keys for the two sponsors?"

Splitting hairs, the signing of DNS information happens after it
leaves the database (of the registry) and before it hits what is
currently known as the DNS (the master server). If a registrant has
two operators for DNS (and many do), the operators are either both
offering slave service or one is slaving off the other.

IOW, if there are two sources of key-pairs for a domain name, there's
trouble elsewhere.

Maybe I don't understand the situation you have in mind.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468

Never confuse activity with progress. Activity pays more.

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 mBTEi70T024729 for ; Mon, 29 Dec 2008 15:44:07 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBTEi7ZN023000 for ietf-provreg-outgoing; Mon, 29 Dec 2008 15:44: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 mBTEi6m4025973 for ; Mon, 29 Dec 2008 15:44:07 +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 EC4E82FE97EF for ; Mon, 29 Dec 2008 14:44:05 +0000 (UTC)
Date: Mon, 29 Dec 2008 09:44:04 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
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

Hi,

On Sun, Dec 28, 2008 at 12:35:48PM -0500, Gould, James wrote:
>
> Overall, I believe that the inability to do both an add and remove
> in RFC 4310 is an oversight that should be addressed to be
> consistent with the rest of the EPP specifications and to ensure
> transactional consistency, but I'm not sure if it is bad enough to
> warrant the process to make the change on its own. Based on the
> provreg e-mail list it doesn't look like anyone beliefs that it does
> warrant a change to RFC 4310 at this point (other than maybe me), so
> if there is anyone out there that believes that it does please reply
> to the list.

I think it does, and I'm willing to work on such changes. I do worry
about the operational effects of performing add and remove at the same
time: it seems to me to be the sort of thing that could take a domain
dark.

There's an additional issue in this area that's troubling to me, which
has to do with domain transfers in a DNSSEC context, particularly in
cases where the private keys for the two sponsors can't be shared
(imagine the case where the two sponsors are each involved in
operating the DNS for the target domain; in this case, they're not
going to share private keys with one another). It seems to me that in
such a case, a sponsor needs to be able to add a DS record to a domain
object when the sponsor doesn't actually own the domain. This is
problematic, because obviously we don't want random others being able
to add properties to the objects one sponsors. It would be possible
to allow this while a transfer is pending, but often there are various
prohibitions on such a domain, and perhaps those will conflict with
the ability of the gaining sponsor to add properties to the
prospectively-transferred domain. Thoughts?

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

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 mBSHZsEs008767 for ; Sun, 28 Dec 2008 18:35:54 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBSHZsR4003663 for ietf-provreg-outgoing; Sun, 28 Dec 2008 18:35: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 mBSHZrAg028100 for ; Sun, 28 Dec 2008 18:35: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 mBSHUAHr016050; Sun, 28 Dec 2008 12:30: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); Sun, 28 Dec 2008 17:35:49 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
Date: Sun, 28 Dec 2008 12:35:48 -0500
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
Thread-Index: AclmQP6ikKV4A/5+S56wCNfvoXLfXACzFcjQ
From: "Gould, James"
To: "Patrick Mevzek" , "EPP Provreg"
X-OriginalArrivalTime: 28 Dec 2008 17:35:49.0750 (UTC) FILETIME=[B964F960:01C96912]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id mBSHZrAg001758
Sender: [email-masked]
Precedence: bulk

Patrick,

My point of transactional consistency does not deal with the difference between managing a list via deltas (add and remove) versus a complete set (chg), but deals with the inability to manage a list effectively with either since RFC 4310 does not allow the DS data to be managed using deltas (add AND remove) or a compete set (chg). Transactional consistency deals with writable operations, where obtaining the current list of name servers, statuses, or contacts from a local datastore or from the Registry is not part of the transaction context. In my opinion splitting updates across three commands (info, transfer, and update) is fine since info is not part of the transaction context, the transfer is simply a request to change sponsorship of the domain, and the final update should set the domain to the desired state once the transfer is completed and the gaining Registrar is authorized to make the change. When managing an individual list attribute, being able to do both an add and remove in a single command will allow the list attribute to have a consistent matching state on the Registry side and in DNS. This seems to me to be simpler and less error prone.

As far as extensions go, I believe that the ability to add extensions is one of the key features of EPP considering that "E" stands for extensible. Hopefully the Registries make the extensions as opt ins instead of requirements. Each Registry has different business models that can be supported by extensions, but the base specifications should continue to hold true. For example, for .COM and .NET we received feedback from the Registrars that they needed information in EPP that was only available via Whois to support transfers, so we created an extension that would allow them to request it with an info command. Adding an extension for transfers to do more than change sponsorship when the transfer is completed is not a bad idea as long as its optional. I believe it is a best practice to incrementally add extensions as opt ins to increase the value to the channel, where some extensions are specific to a Registry and some extensions are more cross-cutting and could be considered for a standards track.

Overall, I believe that the inability to do both an add and remove in RFC 4310 is an oversight that should be addressed to be consistent with the rest of the EPP specifications and to ensure transactional consistency, but I'm not sure if it is bad enough to warrant the process to make the change on its own. Based on the provreg e-mail list it doesn't look like anyone beliefs that it does warrant a change to RFC 4310 at this point (other than maybe me), so if there is anyone out there that believes that it does please reply to the list.

Thanks,

JG

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Patrick Mevzek
Sent: Wednesday, December 24, 2008 10:05 PM
To: EPP Provreg
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question

James Gould 2008-12-11 18:59
> I disagree with your following paragraph:

Ok, I have no strong opinion in either case.

For a recap, we have:
- ns : add and/or rem
- contact : add and/or rem
- status : add and/or rem
- registrant : chg
- authInfo : chg
- secDNS : add and/or rem and/or chg

> It boils down to a transactional consistency issue. An individual EPP
> command is one unit of work and is typically executed as a single
> database transaction on the Registry side, so when a Registrar either
> manages the DS data for the Registrant or provides a UI for the
> Registrant to update the DS data, having to manage the updates in
> separate commands and subsequently separate transactions is more
> complex and will cause transactional inconsistency.

But this is already the case elsewere then.
For example, for nameservers if you want to *change* them (irrelevant to what they are now) you need to know the current set to be able to do a rem and add the correct set. This is one operation, yes. But how do you know the current set ? Ok, you should be a properly managed registrar and have a local copy of this information. Even then, after a transfer for example, you will need a domain:info before your domain:update, so 2 operations, and even if the domain:info has no side effect there still could happen many things between the two that would create transactional inconsistencies.
Also when you speak below about domain transfers currently this means at least three operations: domain:transfer, domain:info to learn the new nameservers/contacts and then domain:update. A lot of inconsistencies can happen there, in part due to the huge number of related parties for such a case (the registry, the current registrar, the new registrar, the registrant or admin contact or someone having pulled the authInfo code from the current registrar to give the new one, maybe the new hosting company (if != new registrar) and the old none (if != old registrar), and even we could imagine the key management authority (if != hosting company), both old and new one...
this is like 10 entities for an operation that could be seen - depending on the level of where you sit to view it - as a single operation/transaction ; registrants do view it like that, they do not understand why a "simple" change of "webhosting" company needs participation of so many entities with rules to follow, delays to wait, etc.)

So for me, we should be able to have add *or* rem *or* chg for any kind of item, but only one of the three in a given domain:update.

> The only way to keep transactional consistency with the desire of a
> Registrant that uses a Registrarąs UI to manage DS data is to have the
> UI only allow either an add, remove, or change, but not a combination.

I believe I have said the same things when saying: no mix.

> There is also the issue of transfers. What happens when a signed
> domain is transferred to another Registrar? Does the DS data transfer
> along with it or does it get cleared. Iąm assuming that it would be
> transferred along in a similar model as the name servers.

A domain name transfer should have no consequences to the running state of the domain and its resolution. So, as the name servers are preserved during a domain name transfer, all related information such as keys should be preserved too in my mind.

Also, in part because of the problem outlined above, some registries have extended EPP to permit the specification of new nameservers and/or contacts when the domain:transfer operation is started, which basically is identical to a domain:transfer + domain:update without fear of consistency issues (and if the domaine:update would allow a domain:ns in the chg node).

It can be seen as a delayed/callback system. The registrar asks for a domain:transfer (that may succeed or not, immediately or later on) but ties the success of this operation with some others (change of nameserves, contacts, etc.) while sending everything in one command to the registry that will ensure atomicity over the whole set of changes (either domain:transfer fails without obviously any change or domainl:transfer succeeds with all changes asked for in nameservers, contacts, etc.).

> It is up to the gaining Registrar to
> update the name servers and DS data assuming that the hosting is
> changing along with the transfer. In this case, the gaining Registrar
> would have a need to remove the existing name servers, add the new
> name servers, and do the same with the DS data.

It has a need to *replace* the current set of nameservers with a new set. He should be able to do that without even having to know the current set. Hence the usefulness of the domain:update chg for nameservers (and same for contacts or statuses) or some registries extension to do that during the domain:transfer.

> Having this done in separate commands / transactions would result in
> DNS getting incremental changes based on the add and remove order
> chosen by the Registrar.

Again, not a problem with a domain:update chg domain:ns or specifying new nameservers (and key materials but since DNSSEC is not widely deployed it I've not seen it used the same way in an extended
domain:transfer) directly into the domain:transfer operation.

> It is much cleaner to simply
> be able to remove and add in a single command and single transaction,
> which will result in one unit of work for DNS updates.

It believe it is even cleaner to be able to force a new set without even have to know the previous one.

> I donąt believe managing a list with delta adds, removes, and changes
> is overly complicated. The RFC could include text that describes some
> of the basic rules to ensure there is consistency. That assumes that
> all Registries fully follow the RFC, which based on your łEPP : An
> implementor experience and recommendations˛ is doesnąt look like that is the case.

I believe in this case that we are more touching issues not strictly technical. EPP with the current behaviour in domain:update is one point of view, it has merits and drawbacks and other points of view have other merits and other drawbacks. But seeing that some registries did extend it to support other point of view just make me think that domain:update should be made simpler with my 2 points (add or rem or chg for any item, and no mix of any of these 3 in any single domain:update) which would also then accomodate all points of view.

I do note that domain:update is a very specific case as due to its nature it is more difficult to properly extend it, and this also created problems in the past (empty domain:update needed or not in case of extensions nodes attached to the command).

> In either event, changing the choice to a sequence is backward
> compatible, so it should not break current client implementations.
> The protocol should address the most common use cases and ensure transactional consistency.

I think in a previous message I've tried to gather some use cases that seemed legitimate to me... but it was more a bait than anything else to make registrars let us know what they do most of the times and/or registries pull some statistics on this topic based on their logs :-)

With that data from "true" sources, I believe it would be easier to see what are the needs and the use cases. We would of course need to take into account extensions related to this, like I've said above the fact that registries permit specifying nameservers/contacts during a domain:transfer, and seeing how it is used by their registrars.

--
Patrick Mevzek

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 mBP35JK2005565 for ; Thu, 25 Dec 2008 04:05:19 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBP35JpA013293 for ietf-provreg-outgoing; Thu, 25 Dec 2008 04:05:19 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from triglav.dotandco.com (triglav.dotandco.com [194.242.114.22]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id mBP35ITs023376 for ; Thu, 25 Dec 2008 04:05:19 +0100 (MET)
Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by triglav.dotandco.com (8.13.8/8.13.8/Debian-3) with ESMTP id mBP35IAC032569; Thu, 25 Dec 2008 04:05:18 +0100
Received: from localhost (localhost [[UNIX: localhost]]) by triglav.dotandco.com (8.13.8/8.13.8/Submit) id mBP35FG4032450; Thu, 25 Dec 2008 04:05:15 +0100
X-Authentication-Warning: triglav.dotandco.com: patrick set sender to [email-masked] using -f
Date: Thu, 25 Dec 2008 04:05:15 +0100
From: Patrick Mevzek
To: EPP Provreg
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
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:
Organization: Dot And Co
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (triglav.dotandco.com [127.0.0.1]); Thu, 25 Dec 2008 04:05:18 +0100 (CET)
Sender: [email-masked]
Precedence: bulk

James Gould 2008-12-11 18:59
> I disagree with your following paragraph:

Ok, I have no strong opinion in either case.

For a recap, we have:
- ns : add and/or rem
- contact : add and/or rem
- status : add and/or rem
- registrant : chg
- authInfo : chg
- secDNS : add and/or rem and/or chg

> It boils down to a transactional consistency issue. An individual EPP
> command is one unit of work and is typically executed as a single database
> transaction on the Registry side, so when a Registrar either manages the DS
> data for the Registrant or provides a UI for the Registrant to update the DS
> data, having to manage the updates in separate commands and subsequently
> separate transactions is more complex and will cause transactional
> inconsistency.

But this is already the case elsewere then.
For example, for nameservers if you want to *change* them (irrelevant
to what they are now) you need to know the current set to be able to
do a rem and add the correct set. This is one operation, yes. But how
do you know the current set ? Ok, you should be a properly managed
registrar and have a local copy of this information. Even then,
after a transfer for example, you will need a domain:info before your
domain:update, so 2 operations, and even if the domain:info has no
side effect there still could happen many things between the two that
would create transactional inconsistencies.
Also when you speak below about domain transfers currently this means
at least three operations: domain:transfer, domain:info to learn the
new nameservers/contacts and then domain:update. A lot of
inconsistencies can happen there, in part due to the huge number of
related parties for such a case (the registry, the current registrar,
the new registrar, the registrant or admin contact or someone having
pulled the authInfo code from the current registrar to give the new
one, maybe the new hosting company (if != new registrar) and the
old none (if != old registrar), and even we could imagine the key
management authority (if != hosting company), both old and new one...
this is like 10 entities for an operation that could be seen -
depending on the level of where you sit to view it - as a single
operation/transaction ; registrants do view it like that, they do not
understand why a "simple" change of "webhosting" company needs
participation of so many entities with rules to follow, delays to
wait, etc.)

So for me, we should be able to have add *or* rem *or* chg for any
kind of item, but only one of the three in a given domain:update.

> The only way to keep transactional consistency with the
> desire of a Registrant that uses a Registrarąs UI to manage DS data is to
> have the UI only allow either an add, remove, or change, but not a
> combination.

I believe I have said the same things when saying: no mix.

> There is also the issue of transfers. What happens when a signed domain is
> transferred to another Registrar? Does the DS data transfer along with it
> or does it get cleared. Iąm assuming that it would be transferred along in
> a similar model as the name servers.

A domain name transfer should have no consequences to the running
state of the domain and its resolution. So, as the name servers are
preserved during a domain name transfer, all related information such
as keys should be preserved too in my mind.

Also, in part because of the problem outlined above, some registries have
extended EPP to permit the specification of new nameservers and/or
contacts when the domain:transfer operation is started, which
basically is identical to a domain:transfer + domain:update without
fear of consistency issues (and if the domaine:update would allow a
domain:ns in the chg node).

It can be seen as a delayed/callback system. The registrar asks for a
domain:transfer (that may succeed or not, immediately or later on)
but ties the success of this operation with some others (change of
nameserves, contacts, etc.) while sending everything in one command
to the registry that will ensure atomicity over the whole set of
changes (either domain:transfer fails without obviously any change or
domainl:transfer succeeds with all changes asked for in nameservers,
contacts, etc.).

> It is up to the gaining Registrar to
> update the name servers and DS data assuming that the hosting is changing
> along with the transfer. In this case, the gaining Registrar would have a
> need to remove the existing name servers, add the new name servers, and do
> the same with the DS data.

It has a need to *replace* the current set of nameservers with a new
set. He should be able to do that without even having to know the
current set. Hence the usefulness of the domain:update chg for
nameservers (and same for contacts or statuses) or some registries
extension to do that during the domain:transfer.

> Having this done in separate commands /
> transactions would result in DNS getting incremental changes based on the
> add and remove order chosen by the Registrar.

Again, not a problem with a domain:update chg domain:ns or specifying
new nameservers (and key materials but since DNSSEC is not widely
deployed it I've not seen it used the same way in an extended
domain:transfer) directly into the domain:transfer operation.

> It is much cleaner to simply
> be able to remove and add in a single command and single transaction, which
> will result in one unit of work for DNS updates.

It believe it is even cleaner to be able to force a new set without
even have to know the previous one.

> I donąt believe managing a list with delta adds, removes, and changes is
> overly complicated. The RFC could include text that describes some of the
> basic rules to ensure there is consistency. That assumes that all
> Registries fully follow the RFC, which based on your łEPP : An implementor
> experience and recommendations˛ is doesnąt look like that is the case.

I believe in this case that we are more touching issues not strictly
technical. EPP with the current behaviour in domain:update is one
point of view, it has merits and drawbacks and other points of view
have other merits and other drawbacks. But seeing that some
registries did extend it to support other point of view just make me
think that domain:update should be made simpler with my 2 points (add
or rem or chg for any item, and no mix of any of these 3 in any
single domain:update) which would also then accomodate all points of
view.

I do note that domain:update is a very specific case as due to its
nature it is more difficult to properly extend it, and this also
created problems in the past (empty domain:update needed or not in
case of extensions nodes attached to the command).

> In either event, changing the choice to a sequence is backward compatible, so
> it should not break current client implementations. The protocol should
> address the most common use cases and ensure transactional consistency.

I think in a previous message I've tried to gather some use cases
that seemed legitimate to me... but it was more a bait than anything
else to make registrars let us know what they do most of the times
and/or registries pull some statistics on this topic based on their
logs :-)

With that data from "true" sources, I believe it would be easier to
see what are the needs and the use cases. We would of course need to
take into account extensions related to this, like I've said above
the fact that registries permit specifying nameservers/contacts
during a domain:transfer, and seeing how it is used by their
registrars.

--
Patrick Mevzek

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 mBMF41XC001661 for ; Mon, 22 Dec 2008 16:04:01 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBMF415h008784 for ietf-provreg-outgoing; Mon, 22 Dec 2008 16:04:01 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id mBMF41QY028466 for ; Mon, 22 Dec 2008 16:04:01 +0100 (MET)
Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 00DFD1C011C; Mon, 22 Dec 2008 16:04:01 +0100 (CET)
Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id EFE7B1C00FD; Mon, 22 Dec 2008 16:04:00 +0100 (CET)
Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id E485DA1D9C5; Mon, 22 Dec 2008 16:04:00 +0100 (CET)
Date: Mon, 22 Dec 2008 16:04:00 +0100
From: Stephane Bortzmeyer
To: Patrick Mevzek
Cc: [email-masked]
Subject: [ietf-provreg] Re: Standards Track Advancement Request for EPP RFCs
Message-ID: <[email-masked]>
References: <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
X-Operating-System: Debian GNU/Linux 5.0
X-Kernel: Linux 2.6.26-1-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Thu, Dec 18, 2008 at 05:45:09PM +0100,
Patrick Mevzek wrote
a message of 52 lines which said:

> And as I can see by the very low response to my other thread about
> my draft, there does not seem to be a lot of interest among
> registries to collaborate, share their experiences, and build things
> together.

Hold on! I've read it, I was planning to comment on it but it was
posted only nine days ago and there were other things to do during
this time...

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 mBMEPRBe025029 for ; Mon, 22 Dec 2008 15:25:27 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBMEPRna011394 for ietf-provreg-outgoing; Mon, 22 Dec 2008 15:25:27 +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 mBMEPQHT020450 for ; Mon, 22 Dec 2008 15:25:26 +0100 (MET)
Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id EB30A21; Mon, 22 Dec 2008 15:25: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 BUPH3djRfAAp; Mon, 22 Dec 2008 15:25:19 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id E78224F; Mon, 22 Dec 2008 15:25: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 mBMEPH8J020868; Mon, 22 Dec 2008 15:25:18 +0100 (MEZ)
Message-ID: <[email-masked]>
Date: Mon, 22 Dec 2008 15:25:17 +0100
From: Klaus Malorny
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1b3pre) Gecko/20081221 Shredder/3.0b2pre
MIME-Version: 1.0
To: Olafur Gudmundsson
CC: EPP Provreg
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
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

On 18/12/08 16:08, Olafur Gudmundsson wrote:

>> The DS data is not a separate object, but part of the domain object,
>> so there is no question that it shall be transferred along with the
>> domain itself. Also it is doubtless that the data MAY NOT be cleared.
>
> Clearing DS is what you do when child stops using DNSSEC, thus it must
> be allowed.
>

Sure -- I expressed myself unclear. I meant that they should not be cleared as a
side effect of transfers, as a transfer not necessarily means that the domain is
moved to a new name server operator and/or to a new set of name servers.

>
> [...]
>
> The important question that registries need to ask them self is
> "Does the DS record in the EPP update the data go into the registry or
> does it only go in if/after the child's DNSKEY RRset has a key that
> matches the DS record?"

A pre-check may reduce the risk of human/machine errors that either make the
domain unsigned or suggest the domain being compromised. But it seems to me that
it does not improve security in general.

Thinking a little bit more of my question after your and Patrick's answers, I
have to admit that it is probably not a good idea -- first, the establishment
and management of this channel is a problem. If one would not trust the
registrar/reseller chain enough, this separate channel could not be
created/maintained using their credibility. However, alternative solutions are
likely hard to find. Second, name server assignment/host management would need
to be moved to the name server operators as well. This sounds like a big
responsibility mess.

Regards,

Klaus

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 mBIHItma029037 for ; Thu, 18 Dec 2008 18:18:55 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBIHItG9019228 for ietf-provreg-outgoing; Thu, 18 Dec 2008 18:18:55 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from triglav.dotandco.com (triglav.dotandco.com [194.242.114.22]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id mBIHIswr018404 for ; Thu, 18 Dec 2008 18:18:54 +0100 (MET)
Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by triglav.dotandco.com (8.13.8/8.13.8/Debian-3) with ESMTP id mBIHIsXQ013244; Thu, 18 Dec 2008 18:18:54 +0100
Received: from localhost (localhost [[UNIX: localhost]]) by triglav.dotandco.com (8.13.8/8.13.8/Submit) id mBIHIrLO013243; Thu, 18 Dec 2008 18:18:53 +0100
X-Authentication-Warning: triglav.dotandco.com: patrick set sender to [email-masked] using -f
Date: Thu, 18 Dec 2008 18:18:53 +0100
From: Patrick Mevzek
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
Message-ID: <[email-masked]>
References: <[email-masked]> <[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]>
Organization: Dot And Co
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (triglav.dotandco.com [127.0.0.1]); Thu, 18 Dec 2008 18:18:54 +0100 (CET)
Sender: [email-masked]
Precedence: bulk

Hollenbeck, Scott 2008-12-18 16:16
> If you're asking about overall adoption, I know that it's used by all of
> the gTLD operators (it's an ICANN requirement) and many ccTLD operators.
> Patrick Mevzek recently reported on recent deployments here:
>
> http://www.dotandco.com/services/software/Net-DRI/docs/netdri-icann-cair
> o-ccnso-techday-200811.html
>
> Sorry if the URL gets broken across two lines.

If that can help, from my software, here are some registries using EPP,
sometimes alongside other ancillary protocols, and sometimes still in
the process of deploying it (sorry in advance for any error).

aero
fr re (being currently deployed)
ag
si (being currently deployed)
asia
at
au
be
biz
br
bz
cat
la
cx
gs
tl
ki
ms
mu
nf
ht
na
coop
cz
eu
hn
i.3.4.e164.arpa (Infrastructure Enum in Austria)
info
lc
lu
me
mn
mobi
name
uk
no (being currently deployed)
nu
org
pl (over HTTPS)
pro
pt
sc
se
ch
li
travel
us
vc
com
net
cc
tv
jobs

There is also:
es (over HTTPS)
cn
tw
im
cl
ac
sh
io
tm
in

And I'm sure I've forgotten some...

>From the ICANN Caďro meeting I can see that even some "small" ccTLD
operator are now interested to provide EPP to their registrars (since
most registrars are registering in multiple TLDs, it makes sense for
them to consolidate their protocols and so it make sense for a
registry to suit them).

In short there is a massive move towards EPP (we may already have
crossed the top of the curve), and no move in the opposite direction
(past critics of EPP, specifically in ccTLDs, have changed their
minds or at least agreed to move towards EPP)

> > 1. Move RFC 4930-4934 to full standard without change. I am
> > willing to attempt this, although it's less likely to pass
> > IETF last call than the other options due to the obsolescence
> > of some of the normative references.
> >
> > 2. Republish with only references updated. This will require
> > somewhat less use of the RFC 3967 procedures and make improve
> > the odds of a successful last call.
> >
> > 3. Republish with references updated and operational
> > clarifications; primarily documenting the TLS practices that
> > have been used in practice to interoperate. I recognize
> > there is some risk that the new TLS practices text will not
> > be correct, which is why I've decided I'm willing to let this
> > issue pass for a draft->full advancement. IMHO, the problem
> > should have been noticed and fixed when advancing to draft so
> > any errata could be applied when advancing to full. We
> > missed the window where it was most appropriate to fix that
> > sort of problem, so we shouldn't hold advancement hostage
> > over the issue, IMHO. I can't promise my the rest of the
> > IESG will agree, but that's my opinion.
> >
> > So the steps to advance are:
> >
> > A. Provide data for the "significant benefit to the Internet"
> > litmus test.
> > I'll need to
> > defend this before the IESG.

Besides the number of TLDs/domain names managed through/with EPP,
some quick ideas:
- native support for IPv6 in hostnames (was added only late in RRP,
see RFC3632)
- use of XML hence Unicode hence native support for any kind of IDNs
(if the unicode string version need to be passed during the exchange,
without any encoding)
- support of ENUM provision
- support of DNSSEC provision
- extensibility to cater for needs of current and future TLDs
- standardization on an « EPP authcode » needed for domain name
transfers, being adopted by more and more TLDs, this simplifies the
life of registrants (the merit of this use can be discussed, but at
least it is starting to be uniform in multiple TLDs)

> > B. Choose option 1-3, publish revised I-Ds as appropriate C.
> > It would be very helpful to provide candidate RFC 3967 text
> > for the last call notice.
> >
> > and I'll take it forward from there.
>
> I'm open to either option 2 or 3. What do others think?

>From an implementor point of view again, TLS is not a problem for EPP
deployment, I mean besides just knowing if the registry verify the
client certificate and if so which client certificates issuers the
registry accept, that it is enough to fullfill RFC4934 (EPP over
TCP).
It is far more complicated to enable the interoperability on the
protocol level, taking into account each registry EPP extensions and
various tweaks in namespaces, ordering, result codes, etc.

So I would favor option 2, or after that option 3, so that not too
much time is used for TLS which is not a big issue for EPP in my
mind.

--
Patrick Mevzek

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 mBIGjEgn023746 for ; Thu, 18 Dec 2008 17:45:14 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBIGjEIp013409 for ietf-provreg-outgoing; Thu, 18 Dec 2008 17:45:14 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from triglav.dotandco.com (triglav.dotandco.com [194.242.114.22]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id mBIGjDuR007512 for ; Thu, 18 Dec 2008 17:45:14 +0100 (MET)
Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by triglav.dotandco.com (8.13.8/8.13.8/Debian-3) with ESMTP id mBIGjDbN000658; Thu, 18 Dec 2008 17:45:13 +0100
Received: from localhost (localhost [[UNIX: localhost]]) by triglav.dotandco.com (8.13.8/8.13.8/Submit) id mBIGj9ME000513; Thu, 18 Dec 2008 17:45:09 +0100
X-Authentication-Warning: triglav.dotandco.com: patrick set sender to [email-masked] using -f
Date: Thu, 18 Dec 2008 17:45:09 +0100
From: Patrick Mevzek
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
Message-ID: <[email-masked]>
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
Organization: Dot And Co
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (triglav.dotandco.com [127.0.0.1]); Thu, 18 Dec 2008 17:45:13 +0100 (CET)
Sender: [email-masked]
Precedence: bulk

Jaap Akkerhuis 2008-12-18 17:24
> I admire your patience over advancing this.
>
> Yes, this worth some compliments.

Count me too.

> When I talk to other registry operators, EPP is nearly always
> mentioned. Operators have been and still are converting to it.
> I don't think the RIRs have but just about all TLD operators I
> have come across use it.
>
> Registry operators tend not to document this nor issue reports
> measuring this. Other tasks take precedence.
>
> Yes, and it is too bad that they don't. There is an opportunity to
> learn from ech other experience here. And since the registry operators
> do have to document and explain these to their registrars anyway,
> the extra effort shouldn't be that much, at least, that's what I
> think.

If I can again share my experience on this as a third party EPP client implementor,
some registries are very hostile even in providing their
documentation (describing their local EPP extensions).
Some explain that their local registrar market is very competitive
and they fear to be criticized.
However, most of the time the documentation is public or at least can
be available upon request (but I did not hear back from .NL for
example :-)).
As for building their EPP extension it seems that most registry did
it in house, and not always putting their own registrars in the loop
and working with them. It happens with some registries, but
definitively not all of them.
As for OT&E access to test interoperability it is almost impossible
(there are some nice exceptions) to have one if you are not a
registrar in the relevant TLD. Speaking as for myself I would love to
test interoperability with all EPP registries, but of course I can't
be a registrar in all of them.

If anyone has any idea to change that, I sure would like to hear and
help.

And as I can see by the very low response to my other thread about my
draft, there does not seem to be a lot of interest among registries
to collaborate, share their experiences, and build things together. I
could understand that for gTLDs that would say there are under a
competitive market, but I do not understand that at all for ccTLDs.
Maybe (probably) I'm not using the correct form and channels to
propagate this idea.

--
Patrick Mevzek

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 mBIG43GN014494 for ; Thu, 18 Dec 2008 17:04:03 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBIG43aJ023687 for ietf-provreg-outgoing; Thu, 18 Dec 2008 17:04:03 +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 mBIG42n4023959 for ; Thu, 18 Dec 2008 17:04:02 +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 mBIG3v8W033574; Thu, 18 Dec 2008 17:03:58 +0100 (CET) (envelope-from [email-masked])
Message-Id: <[email-masked]>
To: Edward Lewis
cc: "Hollenbeck, Scott" , [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
In-reply-to: Your message of Thu, 18 Dec 2008 10:09:09 -0500.
Date: Thu, 18 Dec 2008 17:03:57 +0100
From: Jaap Akkerhuis
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (bartok.nlnetlabs.nl [127.0.0.1]); Thu, 18 Dec 2008 17:03:59 +0100 (CET)
X-Spam-Status: No, score=-4.3 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

Hi Scott,

I admire your patience over advancing this.

Yes, this worth some compliments.

When I talk to other registry operators, EPP is nearly always
mentioned. Operators have been and still are converting to it.
I don't think the RIRs have but just about all TLD operators I
have come across use it.

Registry operators tend not to document this nor issue reports
measuring this. Other tasks take precedence.

Yes, and it is too bad that they don't. There is an opportunity to
learn from ech other experience here. And since the registry operators
do have to document and explain these to their registrars anyway,
the extra effort shouldn't be that much, at least, that's what I
think.

Regarding the options - I've never run into any issue with the
original spec, I doubt that we have updated anything for quite
a while. (We did add DNSSEC extensions and some others, but
nothing touching the base.) So I don't have a real opinion on
the needed changes. (As in I don't think/know of anything [is]
needed.)

I'm pretty neutral to the options as well. I always thought that
during advancing a document removing (unused) material was not a
real problem but changing and or adding material, other then updating
references, is close to a no-no, so I would go for the easier one
(1 or 2) to keep the processes going. But there are likely people
way better versed in IETF process to see what the risk there is for
advancing these RFCs.

jaap

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 mBIFGKPU003720 for ; Thu, 18 Dec 2008 16:16:20 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBIFGKg3003320 for ietf-provreg-outgoing; Thu, 18 Dec 2008 16:16:20 +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 mBIFGIaX000140 for ; Thu, 18 Dec 2008 16:16:18 +0100 (MET)
Received: from [0.0.0.0] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id mBIFGF9n085772; Thu, 18 Dec 2008 10:16:16 -0500 (EST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Thu, 18 Dec 2008 10:09:09 -0500
To: "Hollenbeck, Scott"
From: Edward Lewis
Subject: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
Cc: , , , , [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4
Sender: [email-masked]
Precedence: bulk

Scott,

I admire your patience over advancing this.

NeuStar has been using EPP for a long time, in a lot of ways, and
reliably for our domain name registry business. We have even already
implemented the DNSSEC extensions and whatever extensions have been
needed for our business model.

When I talk to other registry operators, EPP is nearly always
mentioned. Operators have been and still are converting to it. I
don't think the RIRs have but just about all TLD operators I have
come across use it.

Registry operators tend not to document this nor issue reports
measuring this. Other tasks take precedence.

Regarding the options - I've never run into any issue with the
original spec, I doubt that we have updated anything for quite a
while. (We did add DNSSEC extensions and some others, but nothing
touching the base.) So I don't have a real opinion on the needed
changes. (As in I don't think/know of anything [is] needed.)

At 8:29 -0500 12/18/08, Hollenbeck, Scott wrote:
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Monday, December 15, 2008 11:58 PM
>> To: Hollenbeck, Scott; [email-masked]
>> Cc: [email-masked]; [email-masked]
>> Subject: RE: Standards Track Advancement Request for EPP RFCs
>>
>> Apologies for taking far too long to review this in detail.
>>
>> I've had several discussions about where to set the bar for
>> advancement to full standard status. RFC 2026 does have this
>> statement:
>>
>> A specification for which significant implementation and
>> successful operational
>> experience has been obtained may be elevated to the
>> Internet Standard level. An
>> Internet Standard (which may simply be referred to as a
>> Standard) is characterized
>> by a high degree of technical maturity and by a generally
>> held belief that the
>> specified protocol or service provides significant benefit
>> to the Internet community.
>>
>> I believe the implementation report fully covers the first
>> sentence. I would want an answer for the second sentence
>> before going forward with this
>> -- certainly domain registration is a significant benefit to
>> the Internet community, so to answer this question, I'd like
>> a rough idea about how often this protocol is used in
>> production between vendors for domain registration. Do you
>> have any information on that?
>
>Depends on what you mean by "how often". It's used for several million
>transactions per day between VeriSign and registrars managing .com and
>.net domains. I don't have direct access to production stats for other
>registry operators, so I'd like to ask others to speak up here as
>appropriate.
>
>If you're asking about overall adoption, I know that it's used by all of
>the gTLD operators (it's an ICANN requirement) and many ccTLD operators.
>Patrick Mevzek recently reported on recent deployments here:
>
>http://www.dotandco.com/services/software/Net-DRI/docs/netdri-icann-cair
>o-ccnso-techday-200811.html
>
>Sorry if the URL gets broken across two lines.
>
>> Beyond that, I think the bar should be set very high before
>> permitting _changes_ during the advancement from draft to
>> full standard. After talking with other parties, I suspect
>> that while my concerns about TLS would improve the quality of
>> the specification, they are not something I feel the IESG
>> should force an author/WG change during this advancement
>> (it's something I would strongly favor for republication at
>> proposed or draft, however).
>>
>> I don't feel any of the normative references are
>> inappropriate for an RFC
>> 3967 downward reference.
>>
>> 1. Move RFC 4930-4934 to full standard without change. I am
>> willing to attempt this, although it's less likely to pass
>> IETF last call than the other options due to the obsolescence
>> of some of the normative references.
>>
>> 2. Republish with only references updated. This will require
>> somewhat less use of the RFC 3967 procedures and make improve
>> the odds of a successful last call.
>>
>> 3. Republish with references updated and operational
>> clarifications; primarily documenting the TLS practices that
>> have been used in practice to interoperate. I recognize
>> there is some risk that the new TLS practices text will not
>> be correct, which is why I've decided I'm willing to let this
>> issue pass for a draft->full advancement. IMHO, the problem
>> should have been noticed and fixed when advancing to draft so
>> any errata could be applied when advancing to full. We
>> missed the window where it was most appropriate to fix that
>> sort of problem, so we shouldn't hold advancement hostage
>> over the issue, IMHO. I can't promise my the rest of the
>> IESG will agree, but that's my opinion.
>>
>> So the steps to advance are:
>>
>> A. Provide data for the "significant benefit to the Internet"
>> litmus test.
>> I'll need to
>> defend this before the IESG.
>> B. Choose option 1-3, publish revised I-Ds as appropriate C.
>> It would be very helpful to provide candidate RFC 3967 text
>> for the last call notice.
>>
>> and I'll take it forward from there.
>
>I'm open to either option 2 or 3. What do others think?
>
>-Scott-

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

Never confuse activity with progress. Activity pays more.

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 mBIDTOe7010561 for ; Thu, 18 Dec 2008 14:29:24 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBIDTOhS012416 for ietf-provreg-outgoing; Thu, 18 Dec 2008 14:29:24 +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 mBIDTNkE014302 for ; Thu, 18 Dec 2008 14:29:23 +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 mBIDNxE7005804; Thu, 18 Dec 2008 08:24:02 -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, 18 Dec 2008 13:29:19 +0000
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: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
Date: Thu, 18 Dec 2008 08:29:13 -0500
Message-ID: <[email-masked]>
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Standards Track Advancement Request for EPP RFCs
Thread-Index: AclfOtlcElWE6u1CR+mi3pKU1EQFYgB2Bb4Q
References: <[email-masked]>
From: "Hollenbeck, Scott"
To: ,
Cc: ,
X-OriginalArrivalTime: 18 Dec 2008 13:29:19.0068 (UTC) FILETIME=[A15481C0:01C96114]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id mBIDTOkE007871
Sender: [email-masked]
Precedence: bulk

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, December 15, 2008 11:58 PM
> To: Hollenbeck, Scott; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Standards Track Advancement Request for EPP RFCs
>
> Apologies for taking far too long to review this in detail.
>
> I've had several discussions about where to set the bar for
> advancement to full standard status. RFC 2026 does have this
> statement:
>
> A specification for which significant implementation and
> successful operational
> experience has been obtained may be elevated to the
> Internet Standard level. An
> Internet Standard (which may simply be referred to as a
> Standard) is characterized
> by a high degree of technical maturity and by a generally
> held belief that the
> specified protocol or service provides significant benefit
> to the Internet community.
>
> I believe the implementation report fully covers the first
> sentence. I would want an answer for the second sentence
> before going forward with this
> -- certainly domain registration is a significant benefit to
> the Internet community, so to answer this question, I'd like
> a rough idea about how often this protocol is used in
> production between vendors for domain registration. Do you
> have any information on that?

Depends on what you mean by "how often". It's used for several million
transactions per day between VeriSign and registrars managing .com and
.net domains. I don't have direct access to production stats for other
registry operators, so I'd like to ask others to speak up here as
appropriate.

If you're asking about overall adoption, I know that it's used by all of
the gTLD operators (it's an ICANN requirement) and many ccTLD operators.
Patrick Mevzek recently reported on recent deployments here:

http://www.dotandco.com/services/software/Net-DRI/docs/netdri-icann-cair
o-ccnso-techday-200811.html

Sorry if the URL gets broken across two lines.

> Beyond that, I think the bar should be set very high before
> permitting _changes_ during the advancement from draft to
> full standard. After talking with other parties, I suspect
> that while my concerns about TLS would improve the quality of
> the specification, they are not something I feel the IESG
> should force an author/WG change during this advancement
> (it's something I would strongly favor for republication at
> proposed or draft, however).
>
> I don't feel any of the normative references are
> inappropriate for an RFC
> 3967 downward reference.
>
> 1. Move RFC 4930-4934 to full standard without change. I am
> willing to attempt this, although it's less likely to pass
> IETF last call than the other options due to the obsolescence
> of some of the normative references.
>
> 2. Republish with only references updated. This will require
> somewhat less use of the RFC 3967 procedures and make improve
> the odds of a successful last call.
>
> 3. Republish with references updated and operational
> clarifications; primarily documenting the TLS practices that
> have been used in practice to interoperate. I recognize
> there is some risk that the new TLS practices text will not
> be correct, which is why I've decided I'm willing to let this
> issue pass for a draft->full advancement. IMHO, the problem
> should have been noticed and fixed when advancing to draft so
> any errata could be applied when advancing to full. We
> missed the window where it was most appropriate to fix that
> sort of problem, so we shouldn't hold advancement hostage
> over the issue, IMHO. I can't promise my the rest of the
> IESG will agree, but that's my opinion.
>
> So the steps to advance are:
>
> A. Provide data for the "significant benefit to the Internet"
> litmus test.
> I'll need to
> defend this before the IESG.
> B. Choose option 1-3, publish revised I-Ds as appropriate C.
> It would be very helpful to provide candidate RFC 3967 text
> for the last call notice.
>
> and I'll take it forward from there.

I'm open to either option 2 or 3. What do others think?

-Scott-

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 mBC9qvOw001606 for ; Fri, 12 Dec 2008 10:52:57 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBC9qvK2025868 for ietf-provreg-outgoing; Fri, 12 Dec 2008 10:52:57 +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 mBC9qu9o014382 for ; Fri, 12 Dec 2008 10:52:56 +0100 (MET)
X-IronPort-AV: E=Sophos;i="4.36,210,1228089600"; d="scan'208";a="28434267"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 12 Dec 2008 09:52:56 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBC9quuo001270; Fri, 12 Dec 2008 10:52:56 +0100
Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBC9quYO020044; Fri, 12 Dec 2008 09:52:56 GMT
Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Dec 2008 10:52:55 +0100
Received: from [192.165.72.13] ([10.61.82.101]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Dec 2008 10:52:44 +0100
Cc: James Gould , Patrick Mevzek , EPP Provreg
Message-Id: <[email-masked]>
From: =?WINDOWS-1252?Q?Patrik_F=E4ltstr=F6m?=
To: Klaus Malorny
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
Date: Fri, 12 Dec 2008 10:52:44 +0100
References: <[email-masked]>
X-Mailer: Apple Mail (2.929.2)
X-OriginalArrivalTime: 12 Dec 2008 09:52:44.0842 (UTC) FILETIME=[61B078A0:01C95C3F]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=757; t=1229075576; x=1229939576; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[email-masked]; z=From:=20=3D?WINDOWS-1252?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:=20Re=3A=20[ietf-provreg]=20DNSSEC=20EPP=20Extensi on=20(RFC=204310)=20Usability=20Question |Sender:=20; bh=RZUEml3aDtYcBwaAKF3hPSlsxdnAR2t3Fa55JIozpZg=; b=sPYBVXe4dlaWDuMePaenv+M7rbMPXjsIQABywsw2cBVzQkvshBxErtsAaN hYcHJD0tZFyXjdv0cIqWPY6NCelxL8X2iwVHVoSX7t7Giz0/ulaoU0nNnKcV cnn5kCxSBQ;
Authentication-Results: ams-dkim-2; header.From=[email-masked]; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );
Sender: [email-masked]
Precedence: bulk

On 12 dec 2008, at 10.23, Klaus Malorny wrote:

> Shouldn't the name server operator get a separate out-of-the-band
> channel to the registry operator to submit the DS data directly, for
> example with a subset of RFC 4931/RFC 4310? Any comments on this?

My immediate reaction is "no". There is the same attack vector as
changes in NS records or glue. I think the DS data should definitely
follow the same path as other domain related data.

That said, the registry can easily do some checks and balances
calculation when the data arrive -- before the zone is published. Just
like they can check glue, that servers are auth etc, they can also
check the KSK in the child zone that it matches the DS passed to them.

Patrik

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 mBC9NTeR010423 for ; Fri, 12 Dec 2008 10:23:29 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBC9NTvk019110 for ietf-provreg-outgoing; Fri, 12 Dec 2008 10:23:29 +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 mBC9NSDr026925 for ; Fri, 12 Dec 2008 10:23:28 +0100 (MET)
Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 73AC24E; Fri, 12 Dec 2008 10:23:28 +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 xhViE0H+y8tV; Fri, 12 Dec 2008 10:23:26 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 8055935; Fri, 12 Dec 2008 10:23:26 +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 mBC9NP1g025809; Fri, 12 Dec 2008 10:23:25 +0100 (MEZ)
Message-ID: <[email-masked]>
Date: Fri, 12 Dec 2008 10:23:25 +0100
From: Klaus Malorny
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1b3pre) Gecko/20081210 Shredder/3.0b2pre
MIME-Version: 1.0
To: James Gould
CC: Patrick Mevzek , EPP Provreg
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
References:
In-Reply-To:
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id mBC9NTDr009039
Sender: [email-masked]
Precedence: bulk

On 12/11/2008 03:59 PM, James Gould wrote:
> [...]
>
> There is also the issue of transfers. What happens when a signed domain
> is transferred to another Registrar? Does the DS data transfer along
> with it or does it get cleared. I’m assuming that it would be
> transferred along in a similar model as the name servers. It is up to
> the gaining Registrar to update the name servers and DS data assuming
> that the hosting is changing along with the transfer.
> [...]

The DS data is not a separate object, but part of the domain object, so there is
no question that it shall be transferred along with the domain itself. Also it
is doubtless that the data MAY NOT be cleared.

But this brings me to another question which I have already discussed with
various people, but with no real satisfying answer yet. Maybe this list is not
the right place for this question neither, but does the management of the DS
data via the whole reseller-registrar chain suffice the security needs of the
DNSSEC infrastructure?

As the name server operator is not necessarily even in this chain, there could
be weak links, attack vectors that could void the security gained by the DNSSEC
protocol itself. Shouldn't the name server operator get a separate
out-of-the-band channel to the registry operator to submit the DS data directly,
for example with a subset of RFC 4931/RFC 4310? Any comments on this?

Regards,

Klaus

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 mBC90AX6007578 for ; Fri, 12 Dec 2008 10:00:10 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBC90AAC021993 for ietf-provreg-outgoing; Fri, 12 Dec 2008 10:00:10 +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 mBC90Anl010252 for ; Fri, 12 Dec 2008 10:00:10 +0100 (MET)
Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 9D5BB82; Fri, 12 Dec 2008 10:00:09 +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 KZD8LKJVKu+n; Fri, 12 Dec 2008 10:00:07 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 8952580; Fri, 12 Dec 2008 10:00:07 +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 mBC906VU023247; Fri, 12 Dec 2008 10:00:07 +0100 (MEZ)
Message-ID: <[email-masked]>
Date: Fri, 12 Dec 2008 10:00:06 +0100
From: Klaus Malorny
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1b3pre) Gecko/20081210 Shredder/3.0b2pre
MIME-Version: 1.0
To: James Gould
CC: "Hollenbeck, Scott" , EPP Provreg
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
References:
In-Reply-To:
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id mBC90Anl017892
Sender: [email-masked]
Precedence: bulk

On 12/11/2008 03:25 PM, James Gould wrote:
> Klaus,
>
> Your two statements “The respective DNSSEC EPP Extension could handle
> this in the same way,
> i.e. a certain key tag may appear only in one of the three sections
> within one
> request, otherwise the request would fail” and “Although I don't think
> there is a
> need to update RFC 4310, I think such kind of constraints in the EPP specs
> should be a little bit more relaxed to make it more flexible” are sort
> of conflicting.
>
> RFC 4310 would have to be updated to allow for the use of add, rem, and
> chg in a single command. The XML schema defined in the RFC will disallow
> a combination of add, rem, and chg assuming the Registry has XML schema
> validation enabled, which in our case we do. Do you see a need to change
> the XML schema?
>
> --
>

Hi James,

as I am in favour of not increasing the protocol entropy without a real need(*),
I would not update RFC 4310 just for this reason. This is not a limitation one
cannot live with. If there would be a major overhaul of this RFC, one could
consider to change the to a though, as this is backward
compatible.

Regards,

Klaus

* We still struggle with various pre-EPP-1.0 and other strange EPP (-like)
implementations.

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 mBBF0A8K024849 for ; Thu, 11 Dec 2008 16:00:10 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBBF0Acm023191 for ietf-provreg-outgoing; Thu, 11 Dec 2008 16:00:10 +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 mBBF08Aa008622 for ; Thu, 11 Dec 2008 16:00:09 +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 mBBEt2Pm021062; Thu, 11 Dec 2008 09:55:02 -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); Thu, 11 Dec 2008 10:00:07 -0500
Received: from 10.131.29.236 ([10.131.29.236]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Thu, 11 Dec 2008 15:00:07 +0000
User-Agent: Microsoft-Entourage/12.14.0.081024
Date: Thu, 11 Dec 2008 09:59:46 -0500
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
From: James Gould
To: Patrick Mevzek , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
Thread-Index: AclaaL5v9kA3UreLQhWXXa+gzwTKvwBOFy1R
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3311834390_9942303"
X-OriginalArrivalTime: 11 Dec 2008 15:00:07.0921 (UTC) FILETIME=[28353E10:01C95BA1]
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_3311834390_9942303
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Patrick,

I disagree with your following paragraph:

For me, no mix at all would be the simpler case, both on registry
side and registrar side: that way there is nothing to think about
what will happen if we do add+rem at the same type for the same info
(otherwise it depends on registry policies and in some case it will
be a noop as add+rem will be seen as opposite, where sometimes in
other registries or other cases it will be a removal since it comes
last), and registrars still have all power to do what they want, they
just, if really needed, do multiple domain:update calls one after the
following and each one with either an add, a rem or a chg. And this
can be encapsulated on their side as a global operation in an higher
API.

It boils down to a transactional consistency issue. An individual EPP
command is one unit of work and is typically executed as a single database
transaction on the Registry side, so when a Registrar either manages the DS
data for the Registrant or provides a UI for the Registrant to update the D=
S
data, having to manage the updates in separate commands and subsequently
separate transactions is more complex and will cause transactional
inconsistency. The only way to keep transactional consistency with the
desire of a Registrant that uses a Registrar=B9s UI to manage DS data is to
have the UI only allow either an add, remove, or change, but not a
combination. I personally have never seen a UI that manages a list in this
manor.=20

There is also the issue of transfers. What happens when a signed domain is
transferred to another Registrar? Does the DS data transfer along with it
or does it get cleared. I=B9m assuming that it would be transferred along in
a similar model as the name servers. It is up to the gaining Registrar to
update the name servers and DS data assuming that the hosting is changing
along with the transfer. In this case, the gaining Registrar would have a
need to remove the existing name servers, add the new name servers, and do
the same with the DS data. Having this done in separate commands /
transactions would result in DNS getting incremental changes based on the
add and remove order chosen by the Registrar. It is much cleaner to simply
be able to remove and add in a single command and single transaction, which
will result in one unit of work for DNS updates.

I don=B9t believe managing a list with delta adds, removes, and changes is
overly complicated. The RFC could include text that describes some of the
basic rules to ensure there is consistency. That assumes that all
Registries fully follow the RFC, which based on your =B3EPP : An implementor
experience and recommendations=B2 is doesn=B9t look like that is the case. In
either event, changing the choice to a sequence is backward compatible, so
it should not break current client implementations. The protocol should
address the most common use cases and ensure transactional consistency.

--=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: Patrick Mevzek
Organization: Dot And Co
Date: Tue, 9 Dec 2008 20:16:41 -0500
To: EPP Provreg
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability
Question

James Gould 2008-12-09 18:29
> In reviewing the DNSSEC EPP Extension (RFC 4310) I noticed one usability
> issue that I would like to get feedback from the existing implementations=
of
> the extension.=20
>
> The specification allows adding (), removing (), =
and
> changing () DS data, but according to the XML schema they can=
=B9t
> be done at the same time. Below is from the RFC 4210 XML schema for the
> :

As others have said I think the whole "issue" is the same for all
update operations on various objects, not only DNSkey materials.

I think that by allowing more flexibility with all operations
possible at the same time, it only create confusion with no big
benefit at the end.

Specifically, I think the most frequent use case for DNS material
would be to add *OR* remove a key, and not at the same time if we are
after smooth transitions.
Change of a key detail may be useful but should not happen too often
in practice.

So having only either one add or one chg or one rem block in a
domain:update for DNSkey material seem fine to me, and I would not be
in favor of mixing.

I also observe (without hard numbers) that use cases depend on object
types.
I would say that for status values it seems more logical to have
mainly add and rem operations (and again probably very few with add
and rem together in a single call), where for nameservers the chg
operation may be more frequent (even if not possible by core EPP
RFCs, it is done by some registries).
As for contact, I would say that it derives a lot from the fact that
very few registries seem to allow really multiple contacts of the
same type, and if they do I think very few registrars use that
feature. Hence in that case add or rem operations are probably the
more logical one for contacts during domain update.

For me, no mix at all would be the simpler case, both on registry
side and registrar side: that way there is nothing to think about
what will happen if we do add+rem at the same type for the same info
(otherwise it depends on registry policies and in some case it will
be a noop as add+rem will be seen as opposite, where sometimes in
other registries or other cases it will be a removal since it comes
last), and registrars still have all power to do what they want, they
just, if really needed, do multiple domain:update calls one after the
following and each one with either an add, a rem or a chg. And this
can be encapsulated on their side as a global operation in an higher
API.

I also observe that, for the same object types, some registries allow
*only* chg, others allow *only* add and/or rem and some allow all
3 ... which create even more confusion.

--
Patrick Mevzek

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

Patrick,

I disagree with your following paragraph:

For me, no mix at all would be the simpler case, both on registry

side and registrar side: that way there is nothing to think about

what will happen if we do add+rem at the same type for the same info

(otherwise it depends on registry policies and in some case it will

be a noop as add+rem will be seen as opposite, where sometimes in

other registries or other cases it will be a removal since it comes

last), and registrars still have all power to do what they want, they

just, if really needed, do multiple domain:update calls one after the

following and each one with either an add, a rem or a chg. And this

can be encapsulated on their side as a global operation in an higher

API.

It boils down to a transactional consistency issue.  An individual EPP=
command is one unit of work and is typically executed as a single database =
transaction on the Registry side, so when a Registrar either manages the DS =
data for the Registrant or provides a UI for the Registrant to update the DS=
data, having to manage the updates in separate commands and subsequently se=
parate transactions is more complex and will cause transactional inconsisten=
cy.  The only way to keep transactional consistency with the desire of =
a Registrant that uses a Registrar’s UI to manage DS data is to have t=
he UI only allow either an add, remove, or change, but not a combination. &n=
bsp;I personally have never seen a UI that manages a list in this manor.

There is also the issue of transfers.  What happens when a signed doma=
in is transferred to another Registrar?  Does the DS data transfer alon=
g with it or does it get cleared.  I’m assuming that it would be =
transferred along in a similar model as the name servers.  It is up to =
the gaining Registrar to update the name servers and DS data assuming that t=
he hosting is changing along with the transfer.  In this case, the gain=
ing Registrar would have a need to remove the existing name servers, add the=
new name servers, and do the same with the DS data.  Having this done =
in separate commands / transactions would result in DNS getting incremental =
changes based on the add and remove order chosen by the Registrar.  It =
is much cleaner to simply be able to remove and add in a single command and =
single transaction, which will result in one unit of work for DNS updates. &=
nbsp;

I don’t believe managing a list with delta adds, removes, and changes=
is overly complicated.  The RFC could include text that describes some=
of the basic rules to ensure there is consistency.  That assumes that =
all Registries fully follow the RFC, which based on your “EPP : An imp=
lementor experience and recommendations” is doesn’t look like th=
at is the case.   In either event, changing the choice to a sequen=
ce is backward compatible, so it should not break current client implementat=
ions.  The protocol should address the most common use cases and ensure=
transactional consistency.

--

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: Patrick Mevzek <[email-masked]>

Organization: Dot And Co

Date: Tue, 9 Dec 2008 20:16:41 -0500

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

Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usabilit=
y Question

James Gould <[email-masked]> 2=
008-12-09 18:29

> In reviewing the DNSSEC EPP Extension (RFC 4310) I noticed one usabili=
ty

> issue that I would like to get feedback from the existing implementati=
ons of

> the extension.

> The specification allows adding (<secDNS:add>), removing (<se=
cDNS:rem>), and

> changing (<secDNS:chg>) DS data, but according to the XML schema=
they can’t

> be done at the same time.  Below is from the RFC 4210 XML schema =
for the

> <secDNS:update>:

As others have said I think the whole "issue" is the same for all=

update operations on various objects, not only DNSkey materials.

I think that by allowing more flexibility with all operations

possible at the same time, it only create confusion with no big

benefit at the end.

Specifically, I think the most frequent use case for DNS material

would be to add *OR* remove a key, and not at the same time if we are

after smooth transitions.

Change of a key detail may be useful but should not happen too often

in practice.

So having only either one add or one chg or one rem block in a

domain:update for DNSkey material seem fine to me, and I would not be

in favor of mixing.

I also observe (without hard numbers) that use cases depend on object

types.

I would say that for status values it seems more logical to have

mainly add and rem operations (and again probably very few with add

and rem together in a single call), where for nameservers the chg

operation may be more frequent (even if not possible by core EPP

RFCs, it is done by some registries).

As for contact, I would say that it derives a lot from the fact that

very few registries seem to allow really multiple contacts of the

same type, and if they do I think very few registrars use that

feature. Hence in that case add or rem operations are probably the

more logical one for contacts during domain update.

For me, no mix at all would be the simpler case, both on registry

side and registrar side: that way there is nothing to think about

what will happen if we do add+rem at the same type for the same info

(otherwise it depends on registry policies and in some case it will

be a noop as add+rem will be seen as opposite, where sometimes in

other registries or other cases it will be a removal since it comes

last), and registrars still have all power to do what they want, they

just, if really needed, do multiple domain:update calls one after the

following and each one with either an add, a rem or a chg. And this

can be encapsulated on their side as a global operation in an higher

API.

I also observe that, for the same object types, some registries allow

*only* chg, others allow *only* add and/or rem and some allow all

3 ... which create even more confusion.

--

Patrick Mevzek

--B_3311834390_9942303--

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 mBBEPLxW021792 for ; Thu, 11 Dec 2008 15:25:21 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBBEPLhG018150 for ietf-provreg-outgoing; Thu, 11 Dec 2008 15:25: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 mBBEPJmX020466 for ; Thu, 11 Dec 2008 15:25:20 +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 mBBEKonA029514; Thu, 11 Dec 2008 09:20:51 -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); Thu, 11 Dec 2008 09:25:18 -0500
Received: from 10.131.29.236 ([10.131.29.236]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Thu, 11 Dec 2008 14:25:17 +0000
User-Agent: Microsoft-Entourage/12.14.0.081024
Date: Thu, 11 Dec 2008 09:25:10 -0500
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
From: James Gould
To: Klaus Malorny , "Hollenbeck, Scott"
CC: EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
Thread-Index: AclaQ+wcpoffmQ7CTi2wzHl9F3F5twBWFmjD
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3311832314_9790664"
X-OriginalArrivalTime: 11 Dec 2008 14:25:18.0750 (UTC) FILETIME=[4AF70BE0:01C95B9C]
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_3311832314_9790664
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Klaus,

Your two statements =B3The respective DNSSEC EPP Extension could handle this
in the same way,
i.e. a certain key tag may appear only in one of the three sections within
one
request, otherwise the request would fail=B2 and =B3Although I don't think ther=
e
is a
need to update RFC 4310, I think such kind of constraints in the EPP specs
should be a little bit more relaxed to make it more flexible=B2 are sort of
conflicting. =20

RFC 4310 would have to be updated to allow for the use of add, rem, and chg
in a single command. The XML schema defined in the RFC will disallow a
combination of add, rem, and chg assuming the Registry has XML schema
validation enabled, which in our case we do. Do you see a need to change
the XML schema? =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: Tue, 9 Dec 2008 16:19:56 -0500
To: "Hollenbeck, Scott"
Cc: James Gould , EPP Provreg
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability
Question

On 2008-12-09 20:07, Hollenbeck, Scott wrote:
> Ah, but there's a significant difference: adding and removing the same
> status or name server produces no change in end state. The order in
> which a keyTag is changed and removed in one command significant. It can
> either produce an error (remove followed by change) or a state change
> (change followed by remove). That seems like a bad situation that the
> protocol should prevent.
>
> -Scott-
>

Hi Scott,

being nitpicky, adding and removing the same status value in one request is
actually undefined, since the status value not only consists of its name,
but of
a human readable text also. So if there is a status

put on hold because of name infringement

and I submit an update request containing

put on hold because of excessive
spamming

what shall the result be? It is undefined to which of the two (the existing
or
added status value) the removal applies to and which shall survive.

For that reason, our EPP implementation generally disallows the addition an=
d
deletion of the very same name server/status/IP address or whatever in one
request. The respective DNSSEC EPP Extension could handle this in the same
way,
i.e. a certain key tag may appear only in one of the three sections within
one
request, otherwise the request would fail. Although I don't think there is =
a
need to update RFC 4310, I think such kind of constraints in the EPP specs
should be a little bit more relaxed to make it more flexible. I just want t=
o
remind of the issue in RFC 3731, where the requirement of the domain:update
request to have at least one , or element caused either
headaches or protocol bending in the context of EPP extensions (fortunately=
,
this was later fixed in RFC 4931).

Regards,

Klaus

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

Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Questio=
n

Klaus,

Your two statements “The respective DNSSEC EPP Extension could handle=
this in the same way,

i.e. a certain key tag may appear only in one of the three sections within =
one

request, otherwise the request would fail” and “Although I don'=
t think there is a

need to update RFC 4310, I think such kind of constraints in the EPP specs<=
BR>
should be a little bit more relaxed to make it more flexible” are sor=
t of conflicting.

RFC 4310 would have to be updated to allow for the use of add, rem, and chg=
in a single command.  The XML schema defined in the RFC will disallow =
a combination of add, rem, and chg assuming the Registry has XML schema vali=
dation enabled, which in our case we do.  Do you see a need to change t=
he XML schema?

--

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: Tue, 9 Dec 2008 16:19:56 -0500

To: "Hollenbeck, Scott" <[email-masked]>

Cc: James Gould <[email-masked]=
m>, EPP Provreg <ietf-provreg@cafa=
x.se>

Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usabilit=
y Question

On 2008-12-09 20:07, Hollenbeck, Scott wrote:

> Ah, but there's a significant difference: adding and removing the same=

> status or name server produces no change in end state. The order in
> which a keyTag is changed and removed in one command significant. It c=
an

> either produce an error (remove followed by change) or a state change<=
BR>
> (change followed by remove). That seems like a bad situation that the<=
BR>
> protocol should prevent.

> -Scott-

Hi Scott,

being nitpicky, adding and removing the same status value in one request is=

actually undefined, since the status value not only consists of its name, b=
ut of

a human readable text also. So if there is a status

<status s=3D"serverHold">put on hold becaus=
e of name infringement</status>

and I submit an update request containing

<add>

<status s=3D"serverHold">put on=
hold because of excessive spamming</status>

<add>

<rem>

<status s=3D"serverHold"/>

</rem>

what shall the result be? It is undefined to which of the two (the existing=
or

added status value) the removal applies to and which shall survive.

For that reason, our EPP implementation generally disallows the addition an=
d

deletion of the very same name server/status/IP address or whatever in one<=
BR>
request. The respective DNSSEC EPP Extension could handle this in the same =
way,

i.e. a certain key tag may appear only in one of the three sections within =
one

request, otherwise the request would fail. Although I don't think there is =
a

need to update RFC 4310, I think such kind of constraints in the EPP specs<=
BR>
should be a little bit more relaxed to make it more flexible. I just want t=
o

remind of the issue in RFC 3731, where the requirement of the domain:update=

request to have at least one <add>, <rem> or <chg> elemen=
t caused either

headaches or protocol bending in the context of EPP extensions (fortunately=
,

this was later fixed in RFC 4931).

Regards,

Klaus

--B_3311832314_9790664--

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 mBA8jhDq003476 for ; Wed, 10 Dec 2008 09:45:43 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBA8jhXS020710 for ietf-provreg-outgoing; Wed, 10 Dec 2008 09:45:43 +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 mBA8jhKx028863 for ; Wed, 10 Dec 2008 09:45:43 +0100 (MET)
Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id F244D52; Wed, 10 Dec 2008 09:45:42 +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 XQJGmh9dbV-z; Wed, 10 Dec 2008 09:45:39 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 1BA6566; Wed, 10 Dec 2008 09:43:17 +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 mBA8hGpF020157; Wed, 10 Dec 2008 09:43:16 +0100 (MEZ)
Message-ID: <[email-masked]>
Date: Wed, 10 Dec 2008 09:43:16 +0100
From: Klaus Malorny
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1b3pre) Gecko/20081208 Shredder/3.0b2pre
MIME-Version: 1.0
To: Patrick Mevzek
CC: [email-masked]
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
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 12/10/2008 02:16 AM, Patrick Mevzek wrote:

> For me, no mix at all would be the simpler case, both on registry
> side and registrar side: that way there is nothing to think about
> what will happen if we do add+rem at the same type for the same info
> (otherwise it depends on registry policies and in some case it will
> be a noop as add+rem will be seen as opposite, where sometimes in
> other registries or other cases it will be a removal since it comes
> last), and registrars still have all power to do what they want, they
> just, if really needed, do multiple domain:update calls one after the
> following and each one with either an add, a rem or a chg. And this
> can be encapsulated on their side as a global operation in an higher
> API.
>
> I also observe that, for the same object types, some registries allow
> *only* chg, others allow *only* add and/or rem and some allow all
> 3 ... which create even more confusion.
>

Just my two cents: I personally want to have as few calls as possible, so I like
being able to do additions and removals at the same time. Generally speaking,
the design question is whether the "add/remove" approach is the preferable
solution, or whether it is better to choose a "replace all" approach,
especially, as the number of items (status values, contact reference, IP
addresses etc.) are rather small. So a client side application would either
determine the desired state from its own storage and submit it to the registry
or would query the current state from the registry, alter the state at its own
discretion and submit it as a whole to the registry. Our experience with such an
approach in other protocols is rather good, although we discovered the need to
select which part of the data shall be updated. If one only wants to change the
name servers of a domain but not the contacts, it could be regarded as a burden
if the submission of the contact data would be also required.

Regards,

Klaus

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 mBA1GgWi002313 for ; Wed, 10 Dec 2008 02:16:42 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBA1Ggsr009785 for ietf-provreg-outgoing; Wed, 10 Dec 2008 02:16:42 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from triglav.dotandco.com (triglav.dotandco.com [194.242.114.22]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id mBA1GgPX011773 for ; Wed, 10 Dec 2008 02:16:42 +0100 (MET)
Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by triglav.dotandco.com (8.13.8/8.13.8/Debian-3) with ESMTP id mBA1GfQw009867; Wed, 10 Dec 2008 02:16:41 +0100
Received: from localhost (localhost [[UNIX: localhost]]) by triglav.dotandco.com (8.13.8/8.13.8/Submit) id mBA1GfGl009866; Wed, 10 Dec 2008 02:16:41 +0100
X-Authentication-Warning: triglav.dotandco.com: patrick set sender to [email-masked] using -f
Date: Wed, 10 Dec 2008 02:16:41 +0100
From: Patrick Mevzek
To: [email-masked]
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
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.13 (2006-08-11)
X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (triglav.dotandco.com [127.0.0.1]); Wed, 10 Dec 2008 02:16:41 +0100 (CET)
Sender: [email-masked]
Precedence: bulk

James Gould 2008-12-09 18:29
> In reviewing the DNSSEC EPP Extension (RFC 4310) I noticed one usability
> issue that I would like to get feedback from the existing implementations of
> the extension.
>
> The specification allows adding (), removing (), and
> changing () DS data, but according to the XML schema they canąt
> be done at the same time. Below is from the RFC 4210 XML schema for the
> :

As others have said I think the whole "issue" is the same for all
update operations on various objects, not only DNSkey materials.

I think that by allowing more flexibility with all operations
possible at the same time, it only create confusion with no big
benefit at the end.

Specifically, I think the most frequent use case for DNS material
would be to add *OR* remove a key, and not at the same time if we are
after smooth transitions.
Change of a key detail may be useful but should not happen too often
in practice.

So having only either one add or one chg or one rem block in a
domain:update for DNSkey material seem fine to me, and I would not be
in favor of mixing.

I also observe (without hard numbers) that use cases depend on object
types.
I would say that for status values it seems more logical to have
mainly add and rem operations (and again probably very few with add
and rem together in a single call), where for nameservers the chg
operation may be more frequent (even if not possible by core EPP
RFCs, it is done by some registries).
As for contact, I would say that it derives a lot from the fact that
very few registries seem to allow really multiple contacts of the
same type, and if they do I think very few registrars use that
feature. Hence in that case add or rem operations are probably the
more logical one for contacts during domain update.

For me, no mix at all would be the simpler case, both on registry
side and registrar side: that way there is nothing to think about
what will happen if we do add+rem at the same type for the same info
(otherwise it depends on registry policies and in some case it will
be a noop as add+rem will be seen as opposite, where sometimes in
other registries or other cases it will be a removal since it comes
last), and registrars still have all power to do what they want, they
just, if really needed, do multiple domain:update calls one after the
following and each one with either an add, a rem or a chg. And this
can be encapsulated on their side as a global operation in an higher
API.

I also observe that, for the same object types, some registries allow
*only* chg, others allow *only* add and/or rem and some allow all
3 ... which create even more confusion.

--
Patrick Mevzek

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 mBA0iSDh023106 for ; Wed, 10 Dec 2008 01:44:28 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mBA0iS2a028487 for ietf-provreg-outgoing; Wed, 10 Dec 2008 01:44:28 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from triglav.dotandco.com (triglav.dotandco.com [194.242.114.22]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id mBA0iRoS009330 for ; Wed, 10 Dec 2008 01:44:27 +0100 (MET)
Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by triglav.dotandco.com (8.13.8/8.13.8/Debian-3) with ESMTP id mBA0iQhj032541; Wed, 10 Dec 2008 01:44:26 +0100
Received: from localhost (localhost [[UNIX: localhost]]) by triglav.dotandco.com (8.13.8/8.13.8/Submit) id mBA0iPqH032540; Wed, 10 Dec 2008 01:44:25 +0100
X-Authentication-Warning: triglav.dotandco.com: patrick set sender to [email-masked] using -f
Date: Wed, 10 Dec 2008 01:44:25 +0100
From: Patrick Mevzek
To: [email-masked]
Subject: Re: [ietf-provreg] Draft about client side implementation experiences
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]>
Organization: Dot And Co
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (triglav.dotandco.com [127.0.0.1]); Wed, 10 Dec 2008 01:44:26 +0100 (CET)
Sender: [email-masked]
Precedence: bulk

Patrick Mevzek 2008-12-09 19:46
> I would like to give you notice of a draft I've written with my
> experiences as implementor of EPP client side, and specifically on
> many extensions done by registries now switching over to EPP.
>
> The document is available here for now:
> http://www.deepcore.org/ietf/draft-mevzek-epp-implementor-experience-00.txt

I forgot to mention that the presentation I've done in ICANN Caďro
ccNSO technical day meeting may be useful, at least the first part
dealing with EPP, its deployment, and various local registry
extensions.

You can see an outline of it at
http://www.dotandco.com/services/software/Net-DRI/docs/netdri-icann-cairo-ccnso-techday-200811.pdf
Presentation itself at
http://www.dotandco.com/services/software/Net-DRI/docs/netdri-icann-cairo-ccnso-techday-200811.html
(needs Javascript, as it is done with S5)

--
Patrick Mevzek

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 mB9NHpUV011233 for ; Wed, 10 Dec 2008 00:17:51 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mB9NHpIs013196 for ietf-provreg-outgoing; Wed, 10 Dec 2008 00:17:51 +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 mB9NHofP015248 for ; Wed, 10 Dec 2008 00:17:51 +0100 (MET)
X-IronPort-AV: E=Sophos;i="4.33,743,1220227200"; d="scan'208";a="28160687"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 09 Dec 2008 23:17:50 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mB9NHohQ017672; Wed, 10 Dec 2008 00:17:50 +0100
Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB9NHodu012338; Tue, 9 Dec 2008 23:17:50 GMT
Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Dec 2008 00:17:50 +0100
Received: from host-78-64-7-95.homerun.telia.com ([10.61.80.201]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Dec 2008 00:17:49 +0100
Cc: "Hollenbeck, Scott" ,
Message-Id:
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=
To: "Gould, James"
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
Date: Wed, 10 Dec 2008 00:17:48 +0100
References: <[email-masked]>
X-Mailer: Apple Mail (2.929.2)
X-OriginalArrivalTime: 09 Dec 2008 23:17:49.0680 (UTC) FILETIME=[5A608F00:01C95A54]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4447; t=1228864670; x=1229728670; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[email-masked]; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20
|Subject:=20Re=3A=20[ietf-provreg]=20DNSSEC=20EPP=20Extensi on=20(RFC=204310)=20Usability=20Question |Sender:=20; bh=A/wjdf1OzQ1EBEKBsTKY2GH7LD9o1CXtFBkWPM8q/Pc=; b=SsQj1U+u/y4zIy0JjE9qux1sNLHOjHKQUF55yV5T2Oy7//J+JuEpbSkccv nKdHr+G/mdzfwWIO7ZkgvXmrq5frH3Hm72MasKh5bu9EUSxBAuMxHlvOnyjX LMQX8czxL9;
Authentication-Results: ams-dkim-2; header.From=[email-masked]; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id mB9NHpfP015205
Sender: [email-masked]
Precedence: bulk

On 9 dec 2008, at 18.56, Gould, James wrote:
> Scott,
>
> I believe that would be up to the server policy to define the mix of
> updates that are valid. The protocol could support a mix unless
> there is some specific reason why it shouldn't. A similar use case
> could apply to the domain mapping where an update includes an add
> and remove of the same status or name server.
>
In Sweden I have either done just add and remove. Never mixed. That
seems to me be a possible source for confusion.

Patrik
>
>
> Jim
> James F. Gould
>
> Pricipal Software Engineer
> VeriSign Inc.
>
>
> From: Hollenbeck, Scott
> To: Gould, James; [email-masked]
> Sent: Tue Dec 09 12:49:04 2008
> Subject: RE: [ietf-provreg] DNSSEC EPP Extension (RFC 4310)
> Usability Question
>
> Jim, I think I might have just remembered a use case that makes the
> a problem. Imagine if it were possible to create a
> command that looks like this:
>
> xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"
> xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0
> secDNS-1.0.xsd">
>
> 12345
>
>
>
> 12345
> 3
> 1
> 49FD46E6C4B45C55D4AC
>
>
>
>
> Is the server supposed to remove or change the data associated with
> keyTag 12345? With the existing schema there's no ambiguity.
> -Scott-
>
>
>
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of James Gould
> Sent: Tuesday, December 09, 2008 12:04 PM
> To: [email-masked]
> Subject: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability
> Question
>
> In reviewing the DNSSEC EPP Extension (RFC 4310) I noticed one
> usability issue that I would like to get feedback from the existing
> implementations of the extension.
>
> The specification allows adding (), removing
> (), and changing () DS data, but according
> to the XML schema they can’t be done at the same time. Below is
> from the RFC 4210 XML schema for the :
>
>
>
>
>
>
>
>
>
>
> To allow for a mix of add, chg, and rem, should the XML schema model
> in the Domain Mapping (RFC 4931) updateType XML schema definition be
> used? I updated the DNSSEC XML schema below to match the definition
> of the Domain Mapping, to support the mix of add, chg, and rem:
>
>
>
>
>
>
>
>
>
>
> Has any of the current implementations come across this issue?
>
> --
>
>
> 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.

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 mB9LK8ta018509 for ; Tue, 9 Dec 2008 22:20:08 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mB9LK82r012521 for ietf-provreg-outgoing; Tue, 9 Dec 2008 22:20:08 +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 mB9LK73O010461 for ; Tue, 9 Dec 2008 22:20:08 +0100 (MET)
Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 839D866; Tue, 9 Dec 2008 22:20:07 +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 0LYbSF0nKxPN; Tue, 9 Dec 2008 22:20:05 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 6396A65; Tue, 9 Dec 2008 22:20:05 +0100 (MEZ)
Received: from [127.0.0.1] (klaus@localhost [127.0.0.1]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id mB9LK432004695; Tue, 9 Dec 2008 22:20:04 +0100 (MEZ)
Message-ID: <[email-masked]>
Date: Tue, 09 Dec 2008 22:19:56 +0100
From: Klaus Malorny
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081204 Shredder/3.0b2pre
MIME-Version: 1.0
To: "Hollenbeck, Scott"
CC: "Gould, James" , [email-masked]
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
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

On 2008-12-09 20:07, Hollenbeck, Scott wrote:
> Ah, but there's a significant difference: adding and removing the same
> status or name server produces no change in end state. The order in
> which a keyTag is changed and removed in one command significant. It can
> either produce an error (remove followed by change) or a state change
> (change followed by remove). That seems like a bad situation that the
> protocol should prevent.
>
> -Scott-
>

Hi Scott,

being nitpicky, adding and removing the same status value in one request is
actually undefined, since the status value not only consists of its name, but of
a human readable text also. So if there is a status

put on hold because of name infringement

and I submit an update request containing

put on hold because of excessive spamming

what shall the result be? It is undefined to which of the two (the existing or
added status value) the removal applies to and which shall survive.

For that reason, our EPP implementation generally disallows the addition and
deletion of the very same name server/status/IP address or whatever in one
request. The respective DNSSEC EPP Extension could handle this in the same way,
i.e. a certain key tag may appear only in one of the three sections within one
request, otherwise the request would fail. Although I don't think there is a
need to update RFC 4310, I think such kind of constraints in the EPP specs
should be a little bit more relaxed to make it more flexible. I just want to
remind of the issue in RFC 3731, where the requirement of the domain:update
request to have at least one , or element caused either
headaches or protocol bending in the context of EPP extensions (fortunately,
this was later fixed in RFC 4931).

Regards,

Klaus

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 mB9J7ZlE019543 for ; Tue, 9 Dec 2008 20:07:35 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mB9J7ZMZ029319 for ietf-provreg-outgoing; Tue, 9 Dec 2008 20:07:35 +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 mB9J7X5X017537 for ; Tue, 9 Dec 2008 20:07:34 +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 mB9J2VAm001834 for ; Tue, 9 Dec 2008 14:02:31 -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, 9 Dec 2008 19:07:33 +0000
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_01C95A31.6359C406"
Subject: RE: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
Date: Tue, 9 Dec 2008 14:07:35 -0500
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
Thread-Index: AclaIC0qOpmEAamYBUig9GPbzl4KmQABR6+gAACJP9UAAl580A==
References: <[email-masked]>
From: "Hollenbeck, Scott"
To: "Gould, James" ,
X-OriginalArrivalTime: 09 Dec 2008 19:07:33.0117 (UTC) FILETIME=[63CEE2D0:01C95A31]
Sender: [email-masked]
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C95A31.6359C406
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Ah, but there's a significant difference: adding and removing the same
status or name server produces no change in end state. The order in
which a keyTag is changed and removed in one command significant. It
can either produce an error (remove followed by change) or a state
change (change followed by remove). That seems like a bad situation
that the protocol should prevent.

-Scott-=20

=20

________________________________

From: Gould, James=20
Sent: Tuesday, December 09, 2008 12:56 PM
To: Hollenbeck, Scott; [email-masked]'
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310)
Usability Question
=09
=09

Scott,
=09
I believe that would be up to the server policy to define the
mix of updates that are valid. The protocol could support a mix unless
there is some specific reason why it shouldn't. A similar use case could
apply to the domain mapping where an update includes an add and remove
of the same status or name server.
=09
Jim=20
James F. Gould=20
=09
Pricipal Software Engineer=20
VeriSign Inc.

=09
________________________________

From: Hollenbeck, Scott=20
To: Gould, James; [email-masked]=20
Sent: Tue Dec 09 12:49:04 2008
Subject: RE: [ietf-provreg] DNSSEC EPP Extension (RFC 4310)
Usability Question=20
=09

=09

Jim, I think I might have just remembered a use case that makes
the a problem. Imagine if it were possible to create a
command that looks like this:
=20

12345

12345
3
1
49FD46E6C4B45C55D4AC

=20
Is the server supposed to remove or change the data associated
with keyTag 12345? With the existing schema there's no ambiguity.

-Scott-=20

=20

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of James Gould
Sent: Tuesday, December 09, 2008 12:04 PM
To: [email-masked]
Subject: [ietf-provreg] DNSSEC EPP Extension (RFC 4310)
Usability Question
=09
=09
In reviewing the DNSSEC EPP Extension (RFC 4310) I
noticed one usability issue that I would like to get feedback from the
existing implementations of the extension. =20
=09
The specification allows adding (), removing
(), and changing () DS data, but according to
the XML schema they can't be done at the same time. Below is from the
RFC 4210 XML schema for the :
=09

=09
To allow for a mix of add, chg, and rem, should the XML
schema model in the Domain Mapping (RFC 4931) updateType XML schema
definition be used? I updated the DNSSEC XML schema below to match the
definition of the Domain Mapping, to support the mix of add, chg, and
rem:
=09

=09
Has any of the current implementations come across this
issue? =20
=09
--=20
=09
=09
JG=20
=09
-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063
=09
=20
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166
=09
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.
=09

------_=_NextPart_001_01C95A31.6359C406
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

DNSSEC EPP Extension (RFC 4310) Usability =
Question

Ah, but there's a significant difference: =
adding and=20
removing the same status or name server produces no change in end =
state. =20
The order in which a keyTag is changed and removed in one command=20
significant.  It can either produce an error (remove followed by =
change) or=20
a state change (change followed by remove).  That seems like a bad=20
situation that the protocol should prevent.

-Scott-

From: Gould, James =

Sent: Tuesday,=20
December 09, 2008 12:56 PM
To: Hollenbeck, Scott;=20
[email-masked]'
Subject: Re: [ietf-provreg] DNSSEC =
EPP=20
Extension (RFC 4310) Usability Question

Scott,

I believe =
that would be up=20
to the server policy to define the mix of updates that are valid. The =
protocol=20
could support a mix unless there is some specific reason why it =
shouldn't. A=20
similar use case could apply to the domain mapping where an update =
includes an=20
add and remove of the same status or name server.

Jim
James =
F.=20
Gould

Pricipal Software Engineer
VeriSign Inc.

From: Hollenbeck, Scott =

To: Gould,=20
James; [email-masked]
Sent: =
Tue Dec=20
09 12:49:04 2008
Subject: RE: [ietf-provreg] DNSSEC EPP =
Extension=20
(RFC 4310) Usability Question

Jim, I think I might =
have just=20
remembered a use case that makes the <sequence> a =
problem. =20
Imagine if it were possible to create a =
command that=20
looks like this:

<secDNS:update
=20
xmlns:secDNS=3D"urn:ietf:params:xml:ns:secDNS-1.0"
=20
xsi:schemaLocation=3D"urn:ietf:params:xml:ns:secDNS-1.0=20
secDNS-1.0.xsd">
=20
<secDNS:rem>
=20
<secDNS:keyTag>12345</secDNS:keyTag>
=20
</secDNS:rem>
=20
<secDNS:chg>
=20
<secDNS:dsData>
=20
=
<secDNS:keyTag>12345</secDNS:keyTag>
&nb=
sp;   <secDNS:alg>3</secDNS:alg>
&nbs=
p;    =20
=
<secDNS:digestType>1</secDNS:digestType>
=
;   =20
=
<secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
=
=20
</secDNS:dsData>
=
</secDNS:chg>

</secDNS:update>

Is the server supposed =
to remove or=20
change the data associated with keyTag 12345?  With the existing =
schema=20
there's no ambiguity.

-Scott-

From: =
[email-masked]=20
[mailto:[email-masked]] On Behalf Of James=20
Gould
Sent: Tuesday, December 09, 2008 12:04 =
PM
To:=20
[email-masked]
Subject: [ietf-provreg] DNSSEC EPP =
Extension=20
(RFC 4310) Usability Question

In reviewing the DNSSEC EPP Extension (RFC =
4310) I=20
noticed one usability issue that I would like to get feedback from =
the=20
existing implementations of the extension.

The =
specification=20
allows adding (<secDNS:add>), removing (<secDNS:rem>), =
and=20
changing (<secDNS:chg>) DS data, but according to the XML =
schema they=20
can’t be done at the same time.  Below is from the RFC =
4210 XML schema=20
for the <secDNS:update>:

<complexType=20
=
name=3D"updateType">
<cho=
ice>
<elemen=
t=20
name=3D"add"=20
=
type=3D"secDNS:dsType"/>
=
<element=20
name=3D"chg"=20
=
type=3D"secDNS:dsType"/>
=
<element=20
name=3D"rem"=20
=
type=3D"secDNS:remType"/>
&l=
t;/choice>
<attribute=20
name=3D"urgent" type=3D"boolean"=20
=
default=3D"false"/>
</complexType&=
gt;

To allow for a mix of add, chg, and =
rem, should=20
the XML schema model in the Domain Mapping (RFC 4931) updateType XML =
schema=20
definition be used?  I updated the DNSSEC XML schema below to =
match the=20
definition of the Domain Mapping, to support the mix of add, chg, =
and=20
rem:

=20
<complexType=20
=
name=3D"updateType">
<seq=
uence>
<elem=
ent=20
name=3D"add" type=3D"secDNS:dsType" =
minOccurs=3D”0”=20
=
/>
<elemen=
t=20
name=3D"chg" type=3D"secDNS:dsType" =
minOccurs=3D”0”=20
=
/>
<elemen=
t=20
name=3D"rem" type=3D"secDNS:remType" =
minOccurs=3D”0”=20
=
/>
</sequence>
=
<attribute=20
name=3D"urgent" type=3D"boolean"=20
=
default=3D"false"/>
</complexType&=
gt;

Has any of the current implementations =
come=20
across this issue?

--=20

JG

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

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

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

------_=_NextPart_001_01C95A31.6359C406--

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 mB9IcKmS011366 for ; Tue, 9 Dec 2008 19:38:20 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mB9IcKwx014588 for ietf-provreg-outgoing; Tue, 9 Dec 2008 19:38:20 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from triglav.dotandco.com (triglav.dotandco.com [194.242.114.22]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id mB9IcKfU023588 for ; Tue, 9 Dec 2008 19:38:20 +0100 (MET)
Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by triglav.dotandco.com (8.13.8/8.13.8/Debian-3) with ESMTP id mB9IcJgg001162 for ; Tue, 9 Dec 2008 19:38:19 +0100
Received: from localhost (localhost [[UNIX: localhost]]) by triglav.dotandco.com (8.13.8/8.13.8/Submit) id mB9IcJ1X001161 for [email-masked]; Tue, 9 Dec 2008 19:38:19 +0100
X-Authentication-Warning: triglav.dotandco.com: patrick set sender to [email-masked] using -f
Date: Tue, 9 Dec 2008 19:38:19 +0100
From: Patrick Mevzek
To: [email-masked]
Subject: [ietf-provreg] Draft about client side implementation experiences
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Organization: Dot And Co
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (triglav.dotandco.com [127.0.0.1]); Tue, 09 Dec 2008 19:38:19 +0100 (CET)
Sender: [email-masked]
Precedence: bulk

(Sorry if you get multiple versions of this announcement, I seem to
trigger some mailing-list server rules working against me)

Hello,

I hope the time for this is right.

I would like to give you notice of a draft I've written with my
experiences as implementor of EPP client side, and specifically on
many extensions done by registries now switching over to EPP.

The document is available here for now:
http://www.deepcore.org/ietf/draft-mevzek-epp-implementor-experience-00.txt

If anyone thinks this work is useful and should be pursued, I will
work more on it to polish it, add all references and so on at which
time all suggestions would be welcome, including on structure since
that would be my first I-D.

For now, I'm more expecting general comments, here or in private,
if the timeframe as well as the structure and objectives
of this document are right or not.

Thanks in avance for your possible review and feedback.

--
Patrick Mevzek

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 mB9HuM86020357 for ; Tue, 9 Dec 2008 18:56:22 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mB9HuMli008354 for ietf-provreg-outgoing; Tue, 9 Dec 2008 18:56:22 +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 mB9HuLet029628 for ; Tue, 9 Dec 2008 18:56:21 +0100 (MET)
Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id mB9HpI35031152 for ; Tue, 9 Dec 2008 12:51:18 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Dec 2008 12:56:20 -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_01C95A27.70BFCABE"
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
Date: Tue, 9 Dec 2008 12:56:19 -0500
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
Thread-Index: AclaIC0qOpmEAamYBUig9GPbzl4KmQABR6+gAACJP9U=
From: "Gould, James"
To: "Hollenbeck, Scott" ,
X-OriginalArrivalTime: 09 Dec 2008 17:56:20.0447 (UTC) FILETIME=[71192EF0:01C95A27]
Sender: [email-masked]
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C95A27.70BFCABE
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: base64

U2NvdHQsDQoNCkkgYmVsaWV2ZSB0aGF0IHdvdWxkIGJlIHVwIHRvIHRoZSBzZXJ2ZXIgcG9saWN5
IHRvIGRlZmluZSB0aGUgbWl4IG9mIHVwZGF0ZXMgdGhhdCBhcmUgdmFsaWQuIFRoZSBwcm90b2Nv
bCBjb3VsZCBzdXBwb3J0IGEgbWl4IHVubGVzcyB0aGVyZSBpcyBzb21lIHNwZWNpZmljIHJlYXNv
biB3aHkgaXQgc2hvdWxkbid0LiBBIHNpbWlsYXIgdXNlIGNhc2UgY291bGQgYXBwbHkgdG8gdGhl
IGRvbWFpbiBtYXBwaW5nIHdoZXJlIGFuIHVwZGF0ZSBpbmNsdWRlcyBhbiBhZGQgYW5kIHJlbW92
ZSBvZiB0aGUgc2FtZSBzdGF0dXMgb3IgbmFtZSBzZXJ2ZXIuDQoNCkppbSANCkphbWVzIEYuIEdv
dWxkIA0KDQpQcmljaXBhbCBTb2Z0d2FyZSBFbmdpbmVlciANClZlcmlTaWduIEluYy4NCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRnJvbTogSG9sbGVuYmVjaywgU2NvdHQg
DQpUbzogR291bGQsIEphbWVzOyBpZXRmLXByb3ZyZWdAY2FmYXguc2UgDQpTZW50OiBUdWUgRGVj
IDA5IDEyOjQ5OjA0IDIwMDgNClN1YmplY3Q6IFJFOiBbaWV0Zi1wcm92cmVnXSBETlNTRUMgRVBQ
IEV4dGVuc2lvbiAoUkZDIDQzMTApIFVzYWJpbGl0eSBRdWVzdGlvbiANCg0KDQpKaW0sIEkgdGhp
bmsgSSBtaWdodCBoYXZlIGp1c3QgcmVtZW1iZXJlZCBhIHVzZSBjYXNlIHRoYXQgbWFrZXMgdGhl
IDxzZXF1ZW5jZT4gYSBwcm9ibGVtLiAgSW1hZ2luZSBpZiBpdCB3ZXJlIHBvc3NpYmxlIHRvIGNy
ZWF0ZSBhIGNvbW1hbmQgdGhhdCBsb29rcyBsaWtlIHRoaXM6DQogDQo8c2VjRE5TOnVwZGF0ZQ0K
ICAgeG1sbnM6c2VjRE5TPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnNlY0ROUy0xLjAiDQogICB4
c2k6c2NoZW1hTG9jYXRpb249InVybjppZXRmOnBhcmFtczp4bWw6bnM6c2VjRE5TLTEuMCBzZWNE
TlMtMS4wLnhzZCI+DQogICA8c2VjRE5TOnJlbT4NCiAgICAgPHNlY0ROUzprZXlUYWc+MTIzNDU8
L3NlY0ROUzprZXlUYWc+DQogICA8L3NlY0ROUzpyZW0+DQogICA8c2VjRE5TOmNoZz4NCiAgICAg
PHNlY0ROUzpkc0RhdGE+DQogICAgICAgPHNlY0ROUzprZXlUYWc+MTIzNDU8L3NlY0ROUzprZXlU
YWc+DQogICAgICAgPHNlY0ROUzphbGc+Mzwvc2VjRE5TOmFsZz4NCiAgICAgICA8c2VjRE5TOmRp
Z2VzdFR5cGU+MTwvc2VjRE5TOmRpZ2VzdFR5cGU+DQogICAgICAgPHNlY0ROUzpkaWdlc3Q+NDlG
RDQ2RTZDNEI0NUM1NUQ0QUM8L3NlY0ROUzpkaWdlc3Q+DQogICAgIDwvc2VjRE5TOmRzRGF0YT4N
CiAgIDwvc2VjRE5TOmNoZz4NCjwvc2VjRE5TOnVwZGF0ZT4NCiANCklzIHRoZSBzZXJ2ZXIgc3Vw
cG9zZWQgdG8gcmVtb3ZlIG9yIGNoYW5nZSB0aGUgZGF0YSBhc3NvY2lhdGVkIHdpdGgga2V5VGFn
IDEyMzQ1PyAgV2l0aCB0aGUgZXhpc3Rpbmcgc2NoZW1hIHRoZXJlJ3Mgbm8gYW1iaWd1aXR5Lg0K
DQotU2NvdHQtIA0KDQogDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K
CUZyb206IG93bmVyLWlldGYtcHJvdnJlZ0BjYWZheC5zZSBbbWFpbHRvOm93bmVyLWlldGYtcHJv
dnJlZ0BjYWZheC5zZV0gT24gQmVoYWxmIE9mIEphbWVzIEdvdWxkDQoJU2VudDogVHVlc2RheSwg
RGVjZW1iZXIgMDksIDIwMDggMTI6MDQgUE0NCglUbzogaWV0Zi1wcm92cmVnQGNhZmF4LnNlDQoJ
U3ViamVjdDogW2lldGYtcHJvdnJlZ10gRE5TU0VDIEVQUCBFeHRlbnNpb24gKFJGQyA0MzEwKSBV
c2FiaWxpdHkgUXVlc3Rpb24NCgkNCgkNCglJbiByZXZpZXdpbmcgdGhlIEROU1NFQyBFUFAgRXh0
ZW5zaW9uIChSRkMgNDMxMCkgSSBub3RpY2VkIG9uZSB1c2FiaWxpdHkgaXNzdWUgdGhhdCBJIHdv
dWxkIGxpa2UgdG8gZ2V0IGZlZWRiYWNrIGZyb20gdGhlIGV4aXN0aW5nIGltcGxlbWVudGF0aW9u
cyBvZiB0aGUgZXh0ZW5zaW9uLiAgDQoJDQoJVGhlIHNwZWNpZmljYXRpb24gYWxsb3dzIGFkZGlu
ZyAoPHNlY0ROUzphZGQ+KSwgcmVtb3ZpbmcgKDxzZWNETlM6cmVtPiksIGFuZCBjaGFuZ2luZyAo
PHNlY0ROUzpjaGc+KSBEUyBkYXRhLCBidXQgYWNjb3JkaW5nIHRvIHRoZSBYTUwgc2NoZW1hIHRo
ZXkgY2Fu4oCZdCBiZSBkb25lIGF0IHRoZSBzYW1lIHRpbWUuICBCZWxvdyBpcyBmcm9tIHRoZSBS
RkMgNDIxMCBYTUwgc2NoZW1hIGZvciB0aGUgPHNlY0ROUzp1cGRhdGU+Og0KCQ0KCSAgICA8Y29t
cGxleFR5cGUgbmFtZT0idXBkYXRlVHlwZSI+DQoJICAgICAgPGNob2ljZT4NCgkgICAgICAgIDxl
bGVtZW50IG5hbWU9ImFkZCIgdHlwZT0ic2VjRE5TOmRzVHlwZSIvPg0KCSAgICAgICAgIDxlbGVt
ZW50IG5hbWU9ImNoZyIgdHlwZT0ic2VjRE5TOmRzVHlwZSIvPg0KCSAgICAgICAgIDxlbGVtZW50
IG5hbWU9InJlbSIgdHlwZT0ic2VjRE5TOnJlbVR5cGUiLz4NCgkgICAgICA8L2Nob2ljZT4NCgkg
ICAgICA8YXR0cmlidXRlIG5hbWU9InVyZ2VudCIgdHlwZT0iYm9vbGVhbiIgZGVmYXVsdD0iZmFs
c2UiLz4NCgkgICAgIDwvY29tcGxleFR5cGU+DQoJDQoJVG8gYWxsb3cgZm9yIGEgbWl4IG9mIGFk
ZCwgY2hnLCBhbmQgcmVtLCBzaG91bGQgdGhlIFhNTCBzY2hlbWEgbW9kZWwgaW4gdGhlIERvbWFp
biBNYXBwaW5nIChSRkMgNDkzMSkgdXBkYXRlVHlwZSBYTUwgc2NoZW1hIGRlZmluaXRpb24gYmUg
dXNlZD8gIEkgdXBkYXRlZCB0aGUgRE5TU0VDIFhNTCBzY2hlbWEgYmVsb3cgdG8gbWF0Y2ggdGhl
IGRlZmluaXRpb24gb2YgdGhlIERvbWFpbiBNYXBwaW5nLCB0byBzdXBwb3J0IHRoZSBtaXggb2Yg
YWRkLCBjaGcsIGFuZCByZW06DQoJDQoJICAgICAgPGNvbXBsZXhUeXBlIG5hbWU9InVwZGF0ZVR5
cGUiPg0KCSAgICAgIDxzZXF1ZW5jZT4NCgkgICAgICAgIDxlbGVtZW50IG5hbWU9ImFkZCIgdHlw
ZT0ic2VjRE5TOmRzVHlwZSIgbWluT2NjdXJzPeKAnTDigJ0gLz4NCgkgICAgICAgICA8ZWxlbWVu
dCBuYW1lPSJjaGciIHR5cGU9InNlY0ROUzpkc1R5cGUiIG1pbk9jY3Vycz3igJ0w4oCdIC8+DQoJ
ICAgICAgICAgPGVsZW1lbnQgbmFtZT0icmVtIiB0eXBlPSJzZWNETlM6cmVtVHlwZSIgbWluT2Nj
dXJzPeKAnTDigJ0gLz4NCgkgICAgICA8L3NlcXVlbmNlPg0KCSAgICAgIDxhdHRyaWJ1dGUgbmFt
ZT0idXJnZW50IiB0eXBlPSJib29sZWFuIiBkZWZhdWx0PSJmYWxzZSIvPg0KCSAgICAgPC9jb21w
bGV4VHlwZT4NCgkNCglIYXMgYW55IG9mIHRoZSBjdXJyZW50IGltcGxlbWVudGF0aW9ucyBjb21l
IGFjcm9zcyB0aGlzIGlzc3VlPyAgDQoJDQoJLS0gDQoJDQoJDQoJSkcgDQoJDQoJLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCUphbWVzIEYu
IEdvdWxkDQoJUHJpbmNpcGFsIFNvZnR3YXJlIEVuZ2luZWVyDQoJVmVyaVNpZ24gTmFtaW5nIFNl
cnZpY2VzDQoJamdvdWxkQHZlcmlzaWduLmNvbQ0KCURpcmVjdDogNzAzLjk0OC4zMjcxDQoJTW9i
aWxlOiA3MDMuNjI4LjcwNjMNCgkNCgkgDQoJMjEzNDUgUmlkZ2V0b3AgQ2lyY2xlDQoJTFMyLTIt
MQ0KCUR1bGxlcywgVkEgMjAxNjYNCgkNCglOb3RpY2UgdG8gUmVjaXBpZW50OiAgVGhpcyBlLW1h
aWwgY29udGFpbnMgY29uZmlkZW50aWFsLCBwcm9wcmlldGFyeSBhbmQvb3IgUmVnaXN0cnkgIFNl
bnNpdGl2ZSBpbmZvcm1hdGlvbiBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSByZWNpcGllbnQgYW5k
LCB0aHVzIG1heSBub3QgYmUgIHJldHJhbnNtaXR0ZWQsIHJlcHJvZHVjZWQgb3IgZGlzY2xvc2Vk
IHdpdGhvdXQgdGhlIHByaW9yIHdyaXR0ZW4gY29uc2VudCBvZiAgVmVyaVNpZ24gTmFtaW5nIGFu
ZCBEaXJlY3RvcnkgU2VydmljZXMuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCAgdGhpcyBlLW1haWwg
bWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5
ICB0ZWxlcGhvbmUgb3IgcmVwbHkgZS1tYWlsIGFuZCBkZXN0cm95IHRoZSBvcmlnaW5hbCBtZXNz
YWdlIHdpdGhvdXQgbWFraW5nIGEgIGNvcHkuICBUaGFuayB5b3UuDQoJDQoNCg==

------_=_NextPart_001_01C95A27.70BFCABE
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT5ETlNTRUMgRVBQIEV4dGVuc2lvbiAoUkZDIDQzMTAp
IFVzYWJpbGl0eSBRdWVzdGlvbjwvVElUTEU+DQo8TUVUQSBodHRwLWVxdWl2PUNvbnRlbnQtVHlw
ZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPg0KPE1FVEEgY29udGVudD0i
TVNIVE1MIDYuMDAuNjAwMC4xNjczNSIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+PHA+
PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD4NClNjb3R0LDxicj48YnI+SSBiZWxp
ZXZlIHRoYXQgd291bGQgYmUgdXAgdG8gdGhlIHNlcnZlciBwb2xpY3kgdG8gZGVmaW5lIHRoZSBt
aXggb2YgdXBkYXRlcyB0aGF0IGFyZSB2YWxpZC4gIFRoZSBwcm90b2NvbCBjb3VsZCBzdXBwb3J0
IGEgbWl4IHVubGVzcyB0aGVyZSBpcyBzb21lIHNwZWNpZmljIHJlYXNvbiB3aHkgaXQgc2hvdWxk
bid0LiAgQSBzaW1pbGFyIHVzZSBjYXNlIGNvdWxkIGFwcGx5IHRvIHRoZSBkb21haW4gbWFwcGlu
ZyB3aGVyZSBhbiB1cGRhdGUgaW5jbHVkZXMgYW4gYWRkIGFuZCByZW1vdmUgb2YgdGhlIHNhbWUg
c3RhdHVzIG9yIG5hbWUgc2VydmVyLjxicj48YnI+SmltDTxicj5KYW1lcyBGLiBHb3VsZA08YnI+
DTxicj5QcmljaXBhbCBTb2Z0d2FyZSBFbmdpbmVlcg08YnI+VmVyaVNpZ24gSW5jLjwvZm9udD48
L3A+DQo8cD48aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXIgdGFiaW5kZXg9LTE+
DQo8Zm9udCBmYWNlPVRhaG9tYSBzaXplPTI+DQo8Yj5Gcm9tPC9iPjogSG9sbGVuYmVjaywgU2Nv
dHQNPGJyPjxiPlRvPC9iPjogR291bGQsIEphbWVzOyBpZXRmLXByb3ZyZWdAY2FmYXguc2UgPGll
dGYtcHJvdnJlZ0BjYWZheC5zZT4NPGJyPjxiPlNlbnQ8L2I+OiBUdWUgRGVjIDA5IDEyOjQ5OjA0
IDIwMDg8YnI+PGI+U3ViamVjdDwvYj46IFJFOiBbaWV0Zi1wcm92cmVnXSBETlNTRUMgRVBQIEV4
dGVuc2lvbiAoUkZDIDQzMTApIFVzYWJpbGl0eSBRdWVzdGlvbg08YnI+PC9mb250PjwvcD4NCg0K
PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MDYzNTk0MDE3LTA5MTIyMDA4PjxG
T05UIGZhY2U9IkNvdXJpZXIgTmV3IiANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPkppbSwgSSB0aGlu
ayBJIG1pZ2h0IGhhdmUmbmJzcDtqdXN0IHJlbWVtYmVyZWQmbmJzcDthIHVzZSANCmNhc2UgdGhh
dCBtYWtlcyB0aGUgJmx0O3NlcXVlbmNlJmd0OyBhIHByb2JsZW0uJm5ic3A7IDwvRk9OVD48L1NQ
QU4+PFNQQU4gDQpjbGFzcz0wNjM1OTQwMTctMDkxMjIwMDg+PEZPTlQgZmFjZT0iQ291cmllciBO
ZXciIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkltYWdpbmUgDQppZiBpdCB3ZXJlIHBvc3NpYmxlIHRv
IGNyZWF0ZSBhIGNvbW1hbmQgdGhhdCBsb29rcyBsaWtlIA0KdGhpczo8L0ZPTlQ+PC9TUEFOPjwv
RElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MDYzNTk0MDE3LTA5MTIy
MDA4PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9O
VD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFz
cz0wNjM1OTQwMTctMDkxMjIwMDg+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIA0KY29sb3I9IzAw
MDBmZiBzaXplPTI+Jmx0O3NlY0ROUzp1cGRhdGU8QlI+Jm5ic3A7Jm5ic3A7IA0KeG1sbnM6c2Vj
RE5TPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnNlY0ROUy0xLjAiPEJSPiZuYnNwOyZuYnNwOyAN
CnhzaTpzY2hlbWFMb2NhdGlvbj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzZWNETlMtMS4wIA0K
c2VjRE5TLTEuMC54c2QiJmd0OzxCUj4mbmJzcDsmbmJzcDsgDQombHQ7c2VjRE5TOnJlbSZndDs8
QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJmx0O3NlY0ROUzprZXlUYWcmZ3Q7MTIzNDUm
bHQ7L3NlY0ROUzprZXlUYWcmZ3Q7PEJSPiZuYnNwOyZuYnNwOyANCiZsdDsvc2VjRE5TOnJlbSZn
dDs8QlI+Jm5ic3A7Jm5ic3A7IA0KJmx0O3NlY0ROUzpjaGcmZ3Q7PEJSPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyANCiZsdDtzZWNETlM6ZHNEYXRhJmd0OzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgDQombHQ7c2VjRE5TOmtleVRhZyZndDsxMjM0NSZsdDsvc2VjRE5T
OmtleVRhZyZndDs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jmx0O3NlY0ROUzphbGcmZ3Q7MyZsdDsvc2VjRE5TOmFsZyZndDs8QlI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJmx0O3NlY0ROUzpkaWdlc3RUeXBlJmd0OzEmbHQ7L3Nl
Y0ROUzpkaWdlc3RUeXBlJmd0OzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgDQombHQ7c2VjRE5TOmRpZ2VzdCZndDs0OUZENDZFNkM0QjQ1QzU1RDRBQyZsdDsvc2VjRE5T
OmRpZ2VzdCZndDs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJmx0Oy9zZWNETlM6ZHNE
YXRhJmd0OzxCUj4mbmJzcDsmbmJzcDsgJmx0Oy9zZWNETlM6Y2hnJmd0OzwvRk9OVD48L1NQQU4+
PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0wNjM1OTQwMTctMDkx
MjIwMDg+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIA0KY29sb3I9IzAwMDBmZiBzaXplPTI+Jmx0
Oy9zZWNETlM6dXBkYXRlJmd0OzwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxp
Z249bGVmdD48U1BBTiBjbGFzcz0wNjM1OTQwMTctMDkxMjIwMDg+PEZPTlQgZmFjZT0iQ291cmll
ciBOZXciIA0KY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4N
CjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTA2MzU5NDAxNy0wOTEyMjAwOD48
Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj5JcyB0aGUgc2Vy
dmVyIHN1cHBvc2VkIHRvIHJlbW92ZSBvciBjaGFuZ2UgdGhlIGRhdGEgDQphc3NvY2lhdGVkIHdp
dGgga2V5VGFnIDEyMzQ1PyZuYnNwOyBXaXRoIHRoZSBleGlzdGluZyBzY2hlbWEgdGhlcmUncyBu
byANCmFtYmlndWl0eS48L0ZPTlQ+PC9TUEFOPjwvRElWPjwhLS0gQ29udmVydGVkIGZyb20gdGV4
dC9wbGFpbiBmb3JtYXQgLS0+DQo8UD48Rk9OVCBzaXplPTI+LVNjb3R0LTwvRk9OVD4gPC9QPg0K
PERJVj4mbmJzcDs8L0RJVj48QlI+DQo8QkxPQ0tRVU9URSANCnN0eWxlPSJQQURESU5HLUxFRlQ6
IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwZmYgMnB4IHNvbGlkOyBN
QVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFu
Zz1lbi11cyBkaXI9bHRyIGFsaWduPWxlZnQ+DQogIDxIUiB0YWJJbmRleD0tMT4NCiAgPEZPTlQg
ZmFjZT1UYWhvbWEgc2l6ZT0yPjxCPkZyb206PC9CPiBvd25lci1pZXRmLXByb3ZyZWdAY2FmYXgu
c2UgDQogIFttYWlsdG86b3duZXItaWV0Zi1wcm92cmVnQGNhZmF4LnNlXSA8Qj5PbiBCZWhhbGYg
T2YgPC9CPkphbWVzIA0KICBHb3VsZDxCUj48Qj5TZW50OjwvQj4gVHVlc2RheSwgRGVjZW1iZXIg
MDksIDIwMDggMTI6MDQgUE08QlI+PEI+VG86PC9CPiANCiAgaWV0Zi1wcm92cmVnQGNhZmF4LnNl
PEJSPjxCPlN1YmplY3Q6PC9CPiBbaWV0Zi1wcm92cmVnXSBETlNTRUMgRVBQIEV4dGVuc2lvbiAN
CiAgKFJGQyA0MzEwKSBVc2FiaWxpdHkgUXVlc3Rpb248QlI+PC9GT05UPjxCUj48L0RJVj4NCiAg
PERJVj48L0RJVj48Rk9OVCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFs
Ij48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTFwdCI+SW4gcmV2aWV3aW5nIHRoZSBETlNT
RUMgRVBQIEV4dGVuc2lvbiAoUkZDIDQzMTApIEkgDQogIG5vdGljZWQgb25lIHVzYWJpbGl0eSBp
c3N1ZSB0aGF0IEkgd291bGQgbGlrZSB0byBnZXQgZmVlZGJhY2sgZnJvbSB0aGUgDQogIGV4aXN0
aW5nIGltcGxlbWVudGF0aW9ucyBvZiB0aGUgZXh0ZW5zaW9uLiAmbmJzcDs8QlI+PEJSPlRoZSBz
cGVjaWZpY2F0aW9uIA0KICBhbGxvd3MgYWRkaW5nICgmbHQ7c2VjRE5TOmFkZCZndDspLCByZW1v
dmluZyAoJmx0O3NlY0ROUzpyZW0mZ3Q7KSwgYW5kIA0KICBjaGFuZ2luZyAoJmx0O3NlY0ROUzpj
aGcmZ3Q7KSBEUyBkYXRhLCBidXQgYWNjb3JkaW5nIHRvIHRoZSBYTUwgc2NoZW1hIHRoZXkgDQog
IGNhbiYjODIxNzt0IGJlIGRvbmUgYXQgdGhlIHNhbWUgdGltZS4gJm5ic3A7QmVsb3cgaXMgZnJv
bSB0aGUgUkZDIDQyMTAgWE1MIHNjaGVtYSANCiAgZm9yIHRoZSAmbHQ7c2VjRE5TOnVwZGF0ZSZn
dDs6PEJSPjxCUj48L1NQQU4+PC9GT05UPjxGT05UIHNpemU9Mj48Rk9OVCANCiAgZmFjZT0iQ291
cmllciwgQ291cmllciBOZXciPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7Y29tcGxleFR5cGUgDQogIG5hbWU9InVwZGF0ZVR5cGUi
Jmd0OzxCUj48Qj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7Y2hvaWNl
Jmd0OzxCUj48L0I+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jmx0O2VsZW1lbnQgDQogIG5hbWU9ImFkZCIgDQogIHR5cGU9InNlY0ROUzpkc1R5cGUiLyZn
dDs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jmx0O2VsZW1lbnQgDQogIG5hbWU9ImNoZyIgDQogIHR5cGU9InNlY0ROUzpkc1R5cGUiLyZn
dDs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jmx0O2VsZW1lbnQgDQogIG5hbWU9InJlbSIgDQogIHR5cGU9InNlY0ROUzpyZW1UeXBlIi8m
Z3Q7PEJSPjxCPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDsvY2hvaWNl
Jmd0OzxCUj48L0I+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0O2F0dHJp
YnV0ZSANCiAgbmFtZT0idXJnZW50IiB0eXBlPSJib29sZWFuIiANCiAgZGVmYXVsdD0iZmFsc2Ui
LyZndDs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0Oy9jb21wbGV4VHlwZSZn
dDs8QlI+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PEZPTlQgDQogIGZhY2U9IkNhbGlicmksIFZlcmRh
bmEsIEhlbHZldGljYSwgQXJpYWwiPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDExcHQiPjxCUj5U
byANCiAgYWxsb3cgZm9yIGEgbWl4IG9mIGFkZCwgY2hnLCBhbmQgcmVtLCBzaG91bGQgdGhlIFhN
TCBzY2hlbWEgbW9kZWwgaW4gdGhlIA0KICBEb21haW4gTWFwcGluZyAoUkZDIDQ5MzEpIHVwZGF0
ZVR5cGUgWE1MIHNjaGVtYSBkZWZpbml0aW9uIGJlIHVzZWQ/ICZuYnNwO0kgDQogIHVwZGF0ZWQg
dGhlIEROU1NFQyBYTUwgc2NoZW1hIGJlbG93IHRvIG1hdGNoIHRoZSBkZWZpbml0aW9uIG9mIHRo
ZSBEb21haW4gDQogIE1hcHBpbmcsIHRvIHN1cHBvcnQgdGhlIG1peCBvZiBhZGQsIGNoZywgYW5k
IA0KICByZW06PEJSPjxCUj4mbmJzcDsmbmJzcDs8L1NQQU4+PC9GT05UPjxGT05UIHNpemU9Mj48
Rk9OVCANCiAgZmFjZT0iQ291cmllciwgQ291cmllciBOZXciPjxTUEFOIHN0eWxlPSJGT05ULVNJ
WkU6IDEwcHQiPiANCiAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0O2NvbXBsZXhUeXBlIA0KICBuYW1l
PSJ1cGRhdGVUeXBlIiZndDs8QlI+PEI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jmx0O3NlcXVlbmNlJmd0OzxCUj48L0I+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0O2VsZW1lbnQgDQogIG5hbWU9ImFkZCIgdHlwZT0ic2VjRE5T
OmRzVHlwZSIgPEI+bWluT2NjdXJzPSYjODIyMTswJiM4MjIxOzwvQj4gDQogIC8mZ3Q7PEJSPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDtl
bGVtZW50IA0KICBuYW1lPSJjaGciIHR5cGU9InNlY0ROUzpkc1R5cGUiIDxCPm1pbk9jY3Vycz0m
IzgyMjE7MCYjODIyMTs8L0I+IA0KICAvJmd0OzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7ZWxlbWVudCANCiAgbmFtZT0icmVtIiB0
eXBlPSJzZWNETlM6cmVtVHlwZSIgPEI+bWluT2NjdXJzPSYjODIyMTswJiM4MjIxOzwvQj4gDQog
IC8mZ3Q7PEJSPjxCPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDsvc2Vx
dWVuY2UmZ3Q7PEJSPjwvQj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7
YXR0cmlidXRlIA0KICBuYW1lPSJ1cmdlbnQiIHR5cGU9ImJvb2xlYW4iIA0KICBkZWZhdWx0PSJm
YWxzZSIvJmd0OzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7L2NvbXBsZXhU
eXBlJmd0OzxCUj48L1NQQU4+PC9GT05UPjwvRk9OVD48Rk9OVCANCiAgZmFjZT0iQ2FsaWJyaSwg
VmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEx
cHQiPjxCUj5IYXMgYW55IG9mIHRoZSBjdXJyZW50IGltcGxlbWVudGF0aW9ucyBjb21lIGFjcm9z
cyANCiAgdGhpcyBpc3N1ZT8gJm5ic3A7PEJSPjwvU1BBTj48L0ZPTlQ+PEZPTlQgc2l6ZT0xPjxG
T05UIA0KICBmYWNlPSJWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48U1BBTiBzdHlsZT0iRk9O
VC1TSVpFOiA5cHQiPjxCUj4tLSANCiAgPEJSPjxCUj48QlI+SkcgPEJSPjxCUj48L1NQQU4+PC9G
T05UPjxGT05UIGNvbG9yPSM4MDAwMDA+PEZPTlQgDQogIGZhY2U9QXJpYWw+PFNQQU4gDQogIHN0
eWxlPSJGT05ULVNJWkU6IDcuNXB0Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tPEJSPjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvRk9OVD48Rk9O
VCANCiAgZmFjZT1BcmlhbD48Rk9OVCBjb2xvcj0jN2YwMDAwPjxGT05UIHNpemU9Mj48U1BBTiAN
CiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+PEI+SmFtZXMgRi4gR291bGQ8QlI+PC9CPjwvU1BB
Tj48L0ZPTlQ+PC9GT05UPjxGT05UIA0KICBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTog
MTBwdCI+PEI+PEZPTlQgY29sb3I9IzRjNGM0Yz5QcmluY2lwYWwgU29mdHdhcmUgDQogIEVuZ2lu
ZWVyPEJSPjwvRk9OVD48L0I+PEZPTlQgY29sb3I9IzRjNGM0Yz5WZXJpU2lnbiBOYW1pbmcgDQog
IFNlcnZpY2VzPEJSPjwvRk9OVD48L1NQQU4+PC9GT05UPjxGT05UIGNvbG9yPSMxMTAwZWY+PEZP
TlQgc2l6ZT0xPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiA5cHQiPjxBIA0KICBocmVmPSJq
Z291bGRAdmVyaXNpZ24uY29tIj5qZ291bGRAdmVyaXNpZ24uY29tPC9BPjxCUj48L1NQQU4+PC9G
T05UPjwvRk9OVD48Rk9OVCANCiAgc2l6ZT0xPjxGT05UIGNvbG9yPSM0YzRjNGM+PFNQQU4gc3R5
bGU9IkZPTlQtU0laRTogNy41cHQiPjxCPkRpcmVjdDo8L0I+IA0KICA3MDMuOTQ4LjMyNzE8QlI+
PEI+TW9iaWxlOjwvQj4gNzAzLjYyOC43MDYzPEJSPjwvU1BBTj48L0ZPTlQ+PFNQQU4gDQogIHN0
eWxlPSJGT05ULVNJWkU6IDcuNXB0Ij48QlI+Jm5ic3A7PEJSPjxGT05UIGNvbG9yPSM0YzRjNGM+
MjEzNDUgUmlkZ2V0b3AgDQogIENpcmNsZTxCUj5MUzItMi0xPEJSPkR1bGxlcywgVkEgMjAxNjY8
QlI+PC9GT05UPjxCUj48Rk9OVCANCiAgY29sb3I9IzdmMDAwMD48Qj48ST5Ob3RpY2UgdG8gUmVj
aXBpZW50OiAmbmJzcDs8L0k+PC9CPjwvRk9OVD48L1NQQU4+PEk+PFNQQU4gDQogIHN0eWxlPSJG
T05ULVNJWkU6IDlwdCI+VGhpcyBlLW1haWwgY29udGFpbnMgY29uZmlkZW50aWFsLCBwcm9wcmll
dGFyeSBhbmQvb3IgDQogIFJlZ2lzdHJ5ICZuYnNwO1NlbnNpdGl2ZSBpbmZvcm1hdGlvbiBpbnRl
bmRlZCBzb2xlbHkgZm9yIHRoZSByZWNpcGllbnQgYW5kLCANCiAgdGh1cyBtYXkgbm90IGJlICZu
YnNwO3JldHJhbnNtaXR0ZWQsIHJlcHJvZHVjZWQgb3IgZGlzY2xvc2VkIHdpdGhvdXQgdGhlIHBy
aW9yIA0KICB3cml0dGVuIGNvbnNlbnQgb2YgJm5ic3A7VmVyaVNpZ24gTmFtaW5nIGFuZCBEaXJl
Y3RvcnkgU2VydmljZXMuICZuYnNwOzxCPklmIA0KICB5b3UgaGF2ZSByZWNlaXZlZCAmbmJzcDt0
aGlzIGUtbWFpbCBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgDQog
IGltbWVkaWF0ZWx5IGJ5ICZuYnNwO3RlbGVwaG9uZSBvciByZXBseSBlLW1haWwgYW5kIGRlc3Ry
b3kgdGhlIG9yaWdpbmFsIA0KICBtZXNzYWdlIHdpdGhvdXQgbWFraW5nIGEgJm5ic3A7Y29weS48
L0I+ICZuYnNwO1RoYW5rIA0KICB5b3UuPC9TUEFOPjwvST48L0ZPTlQ+PC9GT05UPjxGT05UIA0K
ICBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48U1BBTiANCnN0eWxl
PSJGT05ULVNJWkU6IDExcHQiPjxCUj48L0JMT0NLUVVPVEU+PC9TUEFOPjwvRk9OVD48L0JPRFk+
PC9IVE1MPg0K

------_=_NextPart_001_01C95A27.70BFCABE--

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 mB9Hn3pH005203 for ; Tue, 9 Dec 2008 18:49:03 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mB9Hn3x2011382 for ietf-provreg-outgoing; Tue, 9 Dec 2008 18:49:03 +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 mB9Hn2Aj002127 for ; Tue, 9 Dec 2008 18:49:02 +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 mB9Hib28012126 for ; Tue, 9 Dec 2008 12:44:37 -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, 9 Dec 2008 17:49:01 +0000
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_01C95A26.6B3B9CF9"
Subject: RE: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
Date: Tue, 9 Dec 2008 12:49:04 -0500
Message-ID: <[email-masked]>
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
Thread-Index: AclaIC0qOpmEAamYBUig9GPbzl4KmQABR6+g
References:
From: "Hollenbeck, Scott"
To: "Gould, James" ,
X-OriginalArrivalTime: 09 Dec 2008 17:49:01.0662 (UTC) FILETIME=[6B8FE7E0:01C95A26]
Sender: [email-masked]
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C95A26.6B3B9CF9
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Jim, I think I might have just remembered a use case that makes the
a problem. Imagine if it were possible to create a command
that looks like this:
=20

12345

12345
3
1
49FD46E6C4B45C55D4AC

=20
Is the server supposed to remove or change the data associated with
keyTag 12345? With the existing schema there's no ambiguity.

-Scott-=20

=20

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of James Gould
Sent: Tuesday, December 09, 2008 12:04 PM
To: [email-masked]
Subject: [ietf-provreg] DNSSEC EPP Extension (RFC 4310)
Usability Question
=09
=09
In reviewing the DNSSEC EPP Extension (RFC 4310) I noticed one
usability issue that I would like to get feedback from the existing
implementations of the extension. =20
=09
The specification allows adding (), removing
(), and changing () DS data, but according to
the XML schema they can't be done at the same time. Below is from the
RFC 4210 XML schema for the :
=09

=09
To allow for a mix of add, chg, and rem, should the XML schema
model in the Domain Mapping (RFC 4931) updateType XML schema definition
be used? I updated the DNSSEC XML schema below to match the definition
of the Domain Mapping, to support the mix of add, chg, and rem:
=09

=09
Has any of the current implementations come across this issue? =20
=09
--=20
=09
=09
JG=20
=09
-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063
=09
=20
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166
=09
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.
=09

------_=_NextPart_001_01C95A26.6B3B9CF9
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

DNSSEC EPP Extension (RFC 4310) Usability =
Question

Jim, I think I might have just =
remembered a use=20
case that makes the <sequence> a problem.  =
Imagine=20
if it were possible to create a command that looks like=20
this:

<secDNS:update
=20
xmlns:secDNS=3D"urn:ietf:params:xml:ns:secDNS-1.0"
=20
xsi:schemaLocation=3D"urn:ietf:params:xml:ns:secDNS-1.0=20
secDNS-1.0.xsd">
=20
<secDNS:rem>
=20
<secDNS:keyTag>12345</secDNS:keyTag>
=20
</secDNS:rem>
=20
<secDNS:chg>
=20
<secDNS:dsData>
=20
<secDNS:keyTag>12345</secDNS:keyTag>
&nb=
sp;   <secDNS:alg>3</secDNS:alg>
&nbs=
p;    =20
<secDNS:digestType>1</secDNS:digestType>
=
;   =20
<secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
=
=20
</secDNS:dsData>
=
</secDNS:chg>

</secDNS:update>

Is the server supposed to remove or change the =
data=20
associated with keyTag 12345?  With the existing schema there's no=20
ambiguity.

-Scott-

From: [email-masked]=20
[mailto:[email-masked]] On Behalf Of James=20
Gould
Sent: Tuesday, December 09, 2008 12:04 =
PM
To:=20
[email-masked]
Subject: [ietf-provreg] DNSSEC EPP =
Extension=20
(RFC 4310) Usability Question

In reviewing the DNSSEC EPP Extension (RFC =
4310) I=20
noticed one usability issue that I would like to get feedback from the =

existing implementations of the extension.

The =
specification=20
allows adding (<secDNS:add>), removing (<secDNS:rem>), and =

changing (<secDNS:chg>) DS data, but according to the XML schema =
they=20
can’t be done at the same time.  Below is from the RFC 4210 =
XML schema=20
for the <secDNS:update>:

<complexType=20
=
name=3D"updateType">
<cho=
ice>
<elemen=
t=20
name=3D"add"=20
=
type=3D"secDNS:dsType"/>
=
<element=20
name=3D"chg"=20
=
type=3D"secDNS:dsType"/>
=
<element=20
name=3D"rem"=20
=
type=3D"secDNS:remType"/>
&l=
t;/choice>
<attribute=20
name=3D"urgent" type=3D"boolean"=20
=
default=3D"false"/>
</complexType&=
gt;

To=20
allow for a mix of add, chg, and rem, should the XML schema model in =
the=20
Domain Mapping (RFC 4931) updateType XML schema definition be used? =
I=20
updated the DNSSEC XML schema below to match the definition of the =
Domain=20
Mapping, to support the mix of add, chg, and=20
rem:

=20
<complexType=20
=
name=3D"updateType">
<seq=
uence>
<elem=
ent=20
name=3D"add" type=3D"secDNS:dsType" minOccurs=3D”0” =

=
/>
<elemen=
t=20
name=3D"chg" type=3D"secDNS:dsType" minOccurs=3D”0” =

=
/>
<elemen=
t=20
name=3D"rem" type=3D"secDNS:remType" =
minOccurs=3D”0”=20
=
/>
</sequence>
=
<attribute=20
name=3D"urgent" type=3D"boolean"=20
=
default=3D"false"/>
</complexType&=
gt;

Has any of the current implementations =
come across=20
this issue?

--=20

JG

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

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

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

------_=_NextPart_001_01C95A26.6B3B9CF9--

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 mB9H4PkC018661 for ; Tue, 9 Dec 2008 18:04:25 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id mB9H4Pfl009228 for ietf-provreg-outgoing; Tue, 9 Dec 2008 18:04:25 +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 mB9H4ObZ017118 for ; Tue, 9 Dec 2008 18:04:25 +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 mB9GxxOC010329 for ; Tue, 9 Dec 2008 11:59:59 -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, 9 Dec 2008 12:04:23 -0500
Received: from 10.131.29.236 ([10.131.29.236]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Tue, 9 Dec 2008 17:04:22 +0000
User-Agent: Microsoft-Entourage/12.14.0.081024
Date: Tue, 09 Dec 2008 12:04:20 -0500
Subject: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
From: James Gould
To:
Message-ID:
Thread-Topic: DNSSEC EPP Extension (RFC 4310) Usability Question
Thread-Index: AclaIC0qOpmEAamYBUig9GPbzl4KmQ==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3311669061_6430164"
X-OriginalArrivalTime: 09 Dec 2008 17:04:23.0950 (UTC) FILETIME=[2F857AE0:01C95A20]
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_3311669061_6430164
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

In reviewing the DNSSEC EPP Extension (RFC 4310) I noticed one usability
issue that I would like to get feedback from the existing implementations o=
f
the extension. =20

The specification allows adding (), removing (), an=
d
changing () DS data, but according to the XML schema they can=B9t
be done at the same time. Below is from the RFC 4210 XML schema for the
:

=20
To allow for a mix of add, chg, and rem, should the XML schema model in the
Domain Mapping (RFC 4931) updateType XML schema definition be used? I
updated the DNSSEC XML schema below to match the definition of the Domain
Mapping, to support the mix of add, chg, and rem:

=20
Has any of the current implementations come across this issue?

--=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_3311669061_6430164
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

DNSSEC EPP Extension (RFC 4310) Usability Question

In reviewing the DNSSEC EPP Extension (RFC 4310) I noticed one usability i=
ssue that I would like to get feedback from the existing implementations of =
the extension.

The specification allows adding (<secDNS:add>), removing (<secDNS:=
rem>), and changing (<secDNS:chg>) DS data, but according to the XM=
L schema they can’t be done at the same time.  Below is from the =
RFC 4210 XML schema for the <secDNS:update>:

<complexType name=3D"updateT=
ype">

<choice>

<element name=3D"=
;add" type=3D"secDNS:dsType"/>

<element name=3D&quo=
t;chg" type=3D"secDNS:dsType"/>

<element name=3D&quo=
t;rem" type=3D"secDNS:remType"/>

</choice>

<attribute name=3D"urgent&qu=
ot; type=3D"boolean" default=3D"false"/>

</complexType>

To allow for a mix of add, chg, and rem, should the XML schema model in the=
Domain Mapping (RFC 4931) updateType XML schema definition be used?  I=
updated the DNSSEC XML schema below to match the definition of the Domain M=
apping, to support the mix of add, chg, and rem:

=
<complexType name=3D"u=
pdateType">

<sequence>

<element name=3D"=
;add" type=3D"secDNS:dsType" minOccurs=3D”0” /=

<element name=3D&quo=
t;chg" type=3D"secDNS:dsType" minOccurs=3D”0” =
/>

<element name=3D&quo=
t;rem" type=3D"secDNS:remType" minOccurs=3D”0”=
/>

</sequence>

<attribute name=3D"urgent&qu=
ot; type=3D"boolean" default=3D"false"/>

</complexType>

Has any of the current implementations come across this issue?

--

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