Subject: Dear [email-masked] 74% OFF on Pfizer.

From: VIAGRA ® Pfizer Inc.<[email-masked]>
Date: Mon, 30 Nov 2009 16:51:32 -0800 (PST)

Click here to view as a web page.

Unsubscribe |
Change e-mail address |
Privacy Policy |
About Us

Copyright © 2009 axfum Inc. All rights reserved.

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nAPJQieV026470 for ; Wed, 25 Nov 2009 20:26:44 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nAPJQi0r017433 for ietf-provreg-outgoing; Wed, 25 Nov 2009 20:26:44 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nAPJQgQ7016337 for ; Wed, 25 Nov 2009 20:26:43 +0100 (MET)
Message-Id: <[email-masked]>
From: Howard Eland
To: EPP Provreg
In-Reply-To:
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: [ietf-provreg] Is there a 4310-bis document?
Date: Wed, 25 Nov 2009 13:26:36 -0600
References:
X-Mailer: Apple Mail (2.936)
X-Authenticated: True
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id nAPJQhQ7012315
Sender: [email-masked]
Precedence: bulk

Thanks for this, JG. I'll not have a chance to review before the US
holiday, but I will next week.

-Howard

On Nov 25, 2009, at 9:25 AM, James Gould wrote:

> All,
>
> I’ve attached a proposed XML schema based on hitting on points 1, 2,
> 3, and
> 5 from the list below. Points 4 and 6 will be addressed in the
> draft.
> Please review the XML schema and let me know if there are any issues.
>
> 1. Maintains XML schema backward compatibility
> 2. Support the ability to add and remove in the same command
> 3. Support the ability to specify either keyTag or all of the dsData
> attributes for a remove.
> 4. Add clarity around the chg functioning as a replace.
> 5. Add support for a keyData or a dsData interface for Registries that
> intend to manage the DS data generation. I intend to have the XML
> schema
> support both, but to specify that the server MUST support only one
> or the
> other.
> 6. Add a SHOULD statement around the server returning an error for
> wildcard
> deletes to address one of the main concerns around unexpected side
> effects
> of the rem matching multiple DS records with the same keyTag.
>
> Are there any other points that need to be addressed?
>
> I made the dsData (DS Data Interface) and keyData (Key Data Interface)
> mutually exclusive, so by the XML schema there is no mixing of the two
> interfaces while maintaining backward compatibility with RFC 4310.
> I'm
> really looking for feedback from the registries planning to support
> the Key
> Data Interface. I'm assuming that with the Key Data Interface that
> no DS
> data is passed (command or response) since it's being completely
> managed by
> the server. Adding DS data to the Key Data Interface adds
> complexities
> since the server could create multiple DS records for an individual
> key. I
> also assume that the server must choose either the DS Data Interface
> or the
> Key Data Interface to make the protocol clear to the clients.
> Supporting
> the Key Data Interface is a significant change to the draft so I
> want to
> ensure that it is meeting the requirements for those who plan on
> using it.
>
> Thanks,
>
> --
>
>
> JG
>
> -------------------------------------------------------
> James F. Gould
> Principal Software Engineer
> VeriSign Naming Services
> [email-masked]
> Direct: 703.948.3271
> Mobile: 703.628.7063
>
>
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>
> Notice to Recipient: This e-mail contains confidential, proprietary
> and/or
> Registry Sensitive information intended solely for the recipient
> and, thus
> may not be retransmitted, reproduced or disclosed without the prior
> written
> consent of VeriSign Naming and Directory Services. If you have
> received
> this e-mail message in error, please notify the sender immediately by
> telephone or reply e-mail and destroy the original message without
> making a
> copy. Thank you.
>
>
>
> From: James Gould
> Date: Mon, 23 Nov 2009 13:46:15 -0500
> To: Andrew Sullivan , EPP Provreg >
> Conversation: [ietf-provreg] Is there a 4310-bis document?
> Subject: Re: [ietf-provreg] Is there a 4310-bis document?
>
> Andrew,
>
> I can take the task of creating a draft update based on a compromise
> discussed on this list that meets the following points. Can you
> forward me
> the draft XML that you created?
>
> 1. Maintains XML schema backward compatibility
> 2. Support the ability to add and remove in the same command
> 3. Support the ability to specify either keyTag or all of the dsData
> attributes for a remove.
> 4. Add clarity around the chg functioning as a replace.
> 5. Add support for a keyData or a dsData interface for Registries that
> intend to manage the DS data generation. I intend to have the XML
> schema
> support both, but to specify that the server MUST support only one
> or the
> other.
> 6. Add a SHOULD statement around the server returning an error for
> wildcard
> deletes to address one of the main concerns around unexpected side
> effects
> of the rem matching multiple DS records with the same keyTag.
>
> I believe the best route is to keep the interface as close as
> possible to
> RFC 4310, but with updates to address the main interface issues.
> There are
> systems in Production and will be in Production shortly that should
> have a
> smooth migration path to the updated draft.
>
> Any suggestions that the list has with any of these items, please
> let me
> know. Once I have the draft created I’ll send it out the list for
> review.
>
> Thanks,
>
> --
>
>
> JG
>
> -------------------------------------------------------
> James F. Gould
> Principal Software Engineer
> VeriSign Naming Services
> [email-masked]
> Direct: 703.948.3271
> Mobile: 703.628.7063
>
>
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>
> Notice to Recipient: This e-mail contains confidential, proprietary
> and/or
> Registry Sensitive information intended solely for the recipient
> and, thus
> may not be retransmitted, reproduced or disclosed without the prior
> written
> consent of VeriSign Naming and Directory Services. If you have
> received
> this e-mail message in error, please notify the sender immediately by
> telephone or reply e-mail and destroy the original message without
> making a
> copy. Thank you.
>
>
>
> From: Andrew Sullivan
> Date: Mon, 23 Nov 2009 12:48:33 -0500
> To: EPP Provreg
> Subject: Re: [ietf-provreg] Is there a 4310-bis document?
>
> On Mon, Nov 23, 2009 at 10:18:15AM -0500, Edward Lewis wrote:
>> I'm curious...is anyone preparing a document?
>
> I have a -00 draft (I mailed it at least once to the list), but it
> didn't meet several people's needs. My conclusion was that the draft
> needed almost a complete rewrite, and this is no longer just an update
> but a complete new specification. I haven't had a chance to go back
> to it. If someone is dying to take over, I have XML that can be used.
> I'm happy to have my name dropped from the list in that case.
>
>> (consider it). Considering others are in production, is it a given
>> that
>> there will be backwards compatibility?
>
> There will not be schema compatibility if we go the way currently
> proposed. If we go that way, it might be that old clients will work
> fine with new servers. James seemed to suggest at one point that
> during a transition period, the way to get there would just be for
> servers or clients or both to ignore parts of the new protocol. This
> answer makes my teeth hurt, but maybe we can get something cleaner.
>
> A
>
> --
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> =-=-=-
> List run by majordomo software. For (Un-)subscription and similar
> details
> send "help" to [email-masked]
>
>
>
>

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nAPFPwqD024041 for ; Wed, 25 Nov 2009 16:25:58 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nAPFPwm6015991 for ietf-provreg-outgoing; Wed, 25 Nov 2009 16:25:58 +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 nAPFPvaH004163 for ; Wed, 25 Nov 2009 16:25:58 +0100 (MET)
Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id nAPFMsnV013450; Wed, 25 Nov 2009 10:22:54 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 10:25:56 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Nov 2009 15:25:55 +0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Wed, 25 Nov 2009 10:25:50 -0500
Subject: Re: [ietf-provreg] Is there a 4310-bis document?
From: James Gould
To: Andrew Sullivan , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] Is there a 4310-bis document?
Thread-Index: AcpsaLMqgJIhsAXzRqCLdK3J/Sr8MgABIj9bAF2VWLk=
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/mixed; boundary="B_3341989553_2444978"
X-OriginalArrivalTime: 25 Nov 2009 15:25:56.0207 (UTC) FILETIME=[9539AFF0:01CA6DE3]
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_3341989553_2444978
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

All,

I=B9ve attached a proposed XML schema based on hitting on points 1, 2, 3, and
5 from the list below. Points 4 and 6 will be addressed in the draft.
Please review the XML schema and let me know if there are any issues.

1. Maintains XML schema backward compatibility
2. Support the ability to add and remove in the same command
3. Support the ability to specify either keyTag or all of the dsData
attributes for a remove.
4. Add clarity around the chg functioning as a replace.
5. Add support for a keyData or a dsData interface for Registries that
intend to manage the DS data generation. I intend to have the XML schema
support both, but to specify that the server MUST support only one or the
other. =20
6. Add a SHOULD statement around the server returning an error for wildcard
deletes to address one of the main concerns around unexpected side effects
of the rem matching multiple DS records with the same keyTag.

Are there any other points that need to be addressed?

I made the dsData (DS Data Interface) and keyData (Key Data Interface)
mutually exclusive, so by the XML schema there is no mixing of the two
interfaces while maintaining backward compatibility with RFC 4310. I'm
really looking for feedback from the registries planning to support the Key
Data Interface. I'm assuming that with the Key Data Interface that no DS
data is passed (command or response) since it's being completely managed by
the server. Adding DS data to the Key Data Interface adds complexities
since the server could create multiple DS records for an individual key. I
also assume that the server must choose either the DS Data Interface or the
Key Data Interface to make the protocol clear to the clients. Supporting
the Key Data Interface is a significant change to the draft so I want to
ensure that it is meeting the requirements for those who plan on using it.

Thanks, =20

--=20

JG=20

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

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

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

From: James Gould
Date: Mon, 23 Nov 2009 13:46:15 -0500
To: Andrew Sullivan , EPP Provreg
Conversation: [ietf-provreg] Is there a 4310-bis document?
Subject: Re: [ietf-provreg] Is there a 4310-bis document?

Andrew,

I can take the task of creating a draft update based on a compromise
discussed on this list that meets the following points. Can you forward me
the draft XML that you created?

1. Maintains XML schema backward compatibility
2. Support the ability to add and remove in the same command
3. Support the ability to specify either keyTag or all of the dsData
attributes for a remove.
4. Add clarity around the chg functioning as a replace.
5. Add support for a keyData or a dsData interface for Registries that
intend to manage the DS data generation. I intend to have the XML schema
support both, but to specify that the server MUST support only one or the
other. =20
6. Add a SHOULD statement around the server returning an error for wildcard
deletes to address one of the main concerns around unexpected side effects
of the rem matching multiple DS records with the same keyTag.

I believe the best route is to keep the interface as close as possible to
RFC 4310, but with updates to address the main interface issues. There are
systems in Production and will be in Production shortly that should have a
smooth migration path to the updated draft.

Any suggestions that the list has with any of these items, please let me
know. Once I have the draft created I=B9ll send it out the list for review.

Thanks,

--=20

JG=20

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

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

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

From: Andrew Sullivan
Date: Mon, 23 Nov 2009 12:48:33 -0500
To: EPP Provreg
Subject: Re: [ietf-provreg] Is there a 4310-bis document?

On Mon, Nov 23, 2009 at 10:18:15AM -0500, Edward Lewis wrote:
> I'm curious...is anyone preparing a document?

I have a -00 draft (I mailed it at least once to the list), but it
didn't meet several people's needs. My conclusion was that the draft
needed almost a complete rewrite, and this is no longer just an update
but a complete new specification. I haven't had a chance to go back
to it. If someone is dying to take over, I have XML that can be used.
I'm happy to have my name dropped from the list in that case.

> (consider it). Considering others are in production, is it a given that
> there will be backwards compatibility?

There will not be schema compatibility if we go the way currently
proposed. If we go that way, it might be that old clients will work
fine with new servers. James seemed to suggest at one point that
during a transition period, the way to get there would just be for
servers or clients or both to ignore parts of the new protocol. This
answer makes my teeth hurt, but maybe we can get something cleaner.

A

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

--B_3341989553_2444978
Content-type: application/octet-stream; name="secDNS-1.0.xsd"
Content-disposition: attachment;
filename="secDNS-1.0.xsd"
Content-transfer-encoding: base64

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNjaGVtYSAKCXRhcmdl
dE5hbWVzcGFjZT0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzZWNETlMtMS4wIiAKCXhtbG5z
OnNlY0ROUz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzZWNETlMtMS4wIiAKCXhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgCgllbGVtZW50Rm9ybURlZmF1bHQ9
InF1YWxpZmllZCI+CgkKCTxhbm5vdGF0aW9uPgoJCTxkb2N1bWVudGF0aW9uPiAKCQkJRXh0
ZW5zaWJsZSBQcm92aXNpb25pbmcgUHJvdG9jb2wgdjEuMCAKCQkJZG9tYWluIG5hbWUgZXh0
ZW5zaW9uIHNjaGVtYSAKCQkJZm9yIHByb3Zpc2lvbmluZyBETlMgc2VjdXJpdHkgKEROU1NF
QykgZXh0ZW5zaW9ucy4KCQk8L2RvY3VtZW50YXRpb24+Cgk8L2Fubm90YXRpb24+CgkKCTwh
LS0gQ2hpbGQgZWxlbWVudHMgZm91bmQgaW4gRVBQIGNvbW1hbmRzLiAgLS0+Cgk8ZWxlbWVu
dCBuYW1lPSJjcmVhdGUiIHR5cGU9InNlY0ROUzpkc09yS2V5VHlwZSIvPgoJPGVsZW1lbnQg
bmFtZT0idXBkYXRlIiB0eXBlPSJzZWNETlM6dXBkYXRlVHlwZSIvPgoJCgk8IS0tIENoaWxk
IGVsZW1lbnRzIHN1cHBvcnRpbmcgZWl0aGVyIHRoZSBkc0RhdGEgb3IgdGhlIGtleURhdGEg
aW50ZXJmYWNlLiAgLS0+Cgk8Y29tcGxleFR5cGUgbmFtZT0iZHNPcktleVR5cGUiPgoJCTxj
aG9pY2U+CgkJCTxlbGVtZW50IG5hbWU9ImRzRGF0YSIgdHlwZT0ic2VjRE5TOmRzRGF0YVR5
cGUiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+CgkJCTxlbGVtZW50IG5hbWU9ImtleURhdGEi
IHR5cGU9InNlY0ROUzprZXlEYXRhVHlwZSIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4KCQk8
L2Nob2ljZT4KCTwvY29tcGxleFR5cGU+CgkKCTwhLS0gRGVmaW5pdGlvbiBmb3IgdGhlIG1h
eGltdW0gc2lnbmF0dXJlIGxpZmUgKG1heFNpZ0xpZmUpIC0tPgoJPHNpbXBsZVR5cGUgbmFt
ZT0ibWF4U2lnTGlmZVR5cGUiPgoJCTxyZXN0cmljdGlvbiBiYXNlPSJpbnQiPgoJCQk8bWlu
SW5jbHVzaXZlIHZhbHVlPSIxIi8+CgkJPC9yZXN0cmljdGlvbj4KCTwvc2ltcGxlVHlwZT4K
CQoJCgk8IS0tIENoaWxkIGVsZW1lbnRzIG9mIGRzRGF0YSB1c2VkIGZvciBkc0RhdGEgaW50
ZXJmYWNlIC0tPgoJPGNvbXBsZXhUeXBlIG5hbWU9ImRzRGF0YVR5cGUiPgoJCTxzZXF1ZW5j
ZT4KCQkJPGVsZW1lbnQgbmFtZT0ia2V5VGFnIiB0eXBlPSJ1bnNpZ25lZFNob3J0Ii8+CgkJ
CTxlbGVtZW50IG5hbWU9ImFsZyIgdHlwZT0idW5zaWduZWRCeXRlIi8+CgkJCTxlbGVtZW50
IG5hbWU9ImRpZ2VzdFR5cGUiIHR5cGU9InVuc2lnbmVkQnl0ZSIvPgoJCQk8ZWxlbWVudCBu
YW1lPSJkaWdlc3QiIHR5cGU9ImhleEJpbmFyeSIvPgoJCQk8ZWxlbWVudCBuYW1lPSJtYXhT
aWdMaWZlIiB0eXBlPSJzZWNETlM6bWF4U2lnTGlmZVR5cGUiIG1pbk9jY3Vycz0iMCIvPgoJ
CQk8ZWxlbWVudCBuYW1lPSJrZXlEYXRhIiB0eXBlPSJzZWNETlM6a2V5RGF0YVR5cGUiIG1p
bk9jY3Vycz0iMCIvPgoJCTwvc2VxdWVuY2U+Cgk8L2NvbXBsZXhUeXBlPgoJCgoJPCEtLSBD
aGlsZCBlbGVtZW50cyBvZiBrZXlEYXRhIHVzZWQgZm9yIGtleURhdGEgaW50ZXJmYWNlIGFu
ZCBvcHRpb25hbGx5IHdpdGggZHNEYXRhIGludGVyZmFjZSAtLT4KCTxjb21wbGV4VHlwZSBu
YW1lPSJrZXlEYXRhVHlwZSI+CgkJPHNlcXVlbmNlPgoJCQk8ZWxlbWVudCBuYW1lPSJmbGFn
cyIgdHlwZT0idW5zaWduZWRTaG9ydCIvPgoJCQk8ZWxlbWVudCBuYW1lPSJwcm90b2NvbCIg
dHlwZT0idW5zaWduZWRCeXRlIi8+CgkJCTxlbGVtZW50IG5hbWU9ImFsZyIgdHlwZT0idW5z
aWduZWRCeXRlIi8+CgkJCTxlbGVtZW50IG5hbWU9InB1YktleSIgdHlwZT0ic2VjRE5TOmtl
eVR5cGUiLz4KCQkJPGVsZW1lbnQgbmFtZT0ibWF4U2lnTGlmZSIgdHlwZT0ic2VjRE5TOm1h
eFNpZ0xpZmVUeXBlIiBtaW5PY2N1cnM9IjAiLz4KCQk8L3NlcXVlbmNlPgoJPC9jb21wbGV4
VHlwZT4KCQoJPCEtLSBEZWZpbml0aW9uIGZvciB0aGUgcHVibGljIGtleSAgIC0tPgoJPHNp
bXBsZVR5cGUgbmFtZT0ia2V5VHlwZSI+CgkJPHJlc3RyaWN0aW9uIGJhc2U9ImJhc2U2NEJp
bmFyeSI+CgkJCTxtaW5MZW5ndGggdmFsdWU9IjEiLz4KCQk8L3Jlc3RyaWN0aW9uPgoJPC9z
aW1wbGVUeXBlPgoJCgk8IS0tIENoaWxkIGVsZW1lbnRzIG9mIHRoZSA8dXBkYXRlPiBjb21t
YW5kLiAgLS0+Cgk8Y29tcGxleFR5cGUgbmFtZT0idXBkYXRlVHlwZSI+CiAgICAgICAgPGNo
b2ljZT4KICAgICAgICAgIDxlbGVtZW50IG5hbWU9ImNoZyIgdHlwZT0ic2VjRE5TOmRzT3JL
ZXlUeXBlIi8+CiAgICAgICAgICA8c2VxdWVuY2U+CiAgICAgICAgICAgIDxlbGVtZW50IG5h
bWU9ImFkZCIgdHlwZT0ic2VjRE5TOmRzT3JLZXlUeXBlIiBtaW5PY2N1cnM9IjAiLz4KICAg
ICAgICAgICAgPGVsZW1lbnQgbmFtZT0icmVtIiB0eXBlPSJzZWNETlM6cmVtVHlwZSIgbWlu
T2NjdXJzPSIwIi8+CiAgICAgICAgICA8L3NlcXVlbmNlPgogICAgICAgIDwvY2hvaWNlPgoJ
CTxhdHRyaWJ1dGUgbmFtZT0idXJnZW50IiB0eXBlPSJib29sZWFuIiBkZWZhdWx0PSJmYWxz
ZSIvPgoJPC9jb21wbGV4VHlwZT4KCQoJCgk8IS0tIENoaWxkIGVsZW1lbnRzIG9mIHRoZSA8
cmVtPiBjb21tYW5kLiAgLS0+Cgk8Y29tcGxleFR5cGUgbmFtZT0icmVtVHlwZSI+CiAgICAg
ICAgPGNob2ljZT4KICAgICAgICAgIDxlbGVtZW50IG5hbWU9ImtleVRhZyIgdHlwZT0idW5z
aWduZWRTaG9ydCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4KICAgICAgICAgIDxlbGVtZW50
IG5hbWU9ImRzRGF0YSIgdHlwZT0ic2VjRE5TOmRzRGF0YVR5cGUiIG1heE9jY3Vycz0idW5i
b3VuZGVkIi8+CiAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJrZXlEYXRhIiB0eXBlPSJzZWNE
TlM6a2V5RGF0YVR5cGUiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+CiAgICAgICAgPC9jaG9p
Y2U+Cgk8L2NvbXBsZXhUeXBlPgoJCgkKCTwhLS0gQ2hpbGQgcmVzcG9uc2UgZWxlbWVudHMu
ICAtLT4KCTxlbGVtZW50IG5hbWU9ImluZkRhdGEiIHR5cGU9InNlY0ROUzpkc09yS2V5VHlw
ZSIvPgoKPC9zY2hlbWE+Cg==
--B_3341989553_2444978--

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nANIkKpv003539 for ; Mon, 23 Nov 2009 19:46:20 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nANIkKB0020375 for ietf-provreg-outgoing; Mon, 23 Nov 2009 19:46:20 +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 nANIkJ3F003659 for ; Mon, 23 Nov 2009 19:46:19 +0100 (MET)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id nANIhJvB023002; Mon, 23 Nov 2009 13:43:20 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 18:46:18 +0000
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Mon, 23 Nov 2009 18:46:17 +0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Mon, 23 Nov 2009 13:46:15 -0500
Subject: Re: [ietf-provreg] Is there a 4310-bis document?
From: James Gould
To: Andrew Sullivan , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] Is there a 4310-bis document?
Thread-Index: AcpsaLMqgJIhsAXzRqCLdK3J/Sr8MgABIj9b
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3341828776_37544489"
X-OriginalArrivalTime: 23 Nov 2009 18:46:18.0435 (UTC) FILETIME=[3E349930:01CA6C6D]
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_3341828776_37544489
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Andrew,

I can take the task of creating a draft update based on a compromise
discussed on this list that meets the following points. Can you forward me
the draft XML that you created?

1. Maintains XML schema backward compatibility
2. Support the ability to add and remove in the same command
3. Support the ability to specify either keyTag or all of the dsData
attributes for a remove.
4. Add clarity around the chg functioning as a replace.
5. Add support for a keyData or a dsData interface for Registries that
intend to manage the DS data generation. I intend to have the XML schema
support both, but to specify that the server MUST support only one or the
other. =20
6. Add a SHOULD statement around the server returning an error for wildcard
deletes to address one of the main concerns around unexpected side effects
of the rem matching multiple DS records with the same keyTag.

I believe the best route is to keep the interface as close as possible to
RFC 4310, but with updates to address the main interface issues. There are
systems in Production and will be in Production shortly that should have a
smooth migration path to the updated draft.

Any suggestions that the list has with any of these items, please let me
know. Once I have the draft created I=B9ll send it out the list for review.

Thanks,

--=20

JG=20

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

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

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

From: Andrew Sullivan
Date: Mon, 23 Nov 2009 12:48:33 -0500
To: EPP Provreg
Subject: Re: [ietf-provreg] Is there a 4310-bis document?

On Mon, Nov 23, 2009 at 10:18:15AM -0500, Edward Lewis wrote:
> I'm curious...is anyone preparing a document?

I have a -00 draft (I mailed it at least once to the list), but it
didn't meet several people's needs. My conclusion was that the draft
needed almost a complete rewrite, and this is no longer just an update
but a complete new specification. I haven't had a chance to go back
to it. If someone is dying to take over, I have XML that can be used.
I'm happy to have my name dropped from the list in that case.

> (consider it). Considering others are in production, is it a given that
> there will be backwards compatibility?

There will not be schema compatibility if we go the way currently
proposed. If we go that way, it might be that old clients will work
fine with new servers. James seemed to suggest at one point that
during a transition period, the way to get there would just be for
servers or clients or both to ignore parts of the new protocol. This
answer makes my teeth hurt, but maybe we can get something cleaner.

A

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

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

Re: [ietf-provreg] Is there a 4310-bis document?

Andrew,

I can take the task of creating a draft update based on a compromise discus=
sed on this list that meets the following points.  Can you forward me t=
he draft XML that you created?

Maintains XML schema backward compatibility=20

Support the ability to add and remove in the same comman=
d

Support the ability to specify either keyTag or all of t=
he dsData attributes for a remove.=20

Add clarity around the chg functioning as a replace. &nb=
sp;

Add support for a keyData or a dsData interface for Regi=
stries that intend to manage the DS data generation.  I intend to have =
the XML schema support both, but to specify that the server MUST support onl=
y one or the other.

Add a SHOULD statement around the server returning an er=
ror for wildcard deletes to address one of the main concerns around unexpect=
ed side effects of the rem matching multiple DS records with the same keyTag=
.

I believe the best route is to keep the interface as close as possible to R=
FC 4310, but with updates to address the main interface issues.  There =
are systems in Production and will be in Production shortly that should have=
a smooth migration path to the updated draft.

Any suggestions that the list has with any of these items, please let me kn=
ow.  Once I have the draft created I’ll send it out the list for =
review.

Thanks,

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

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

From: Andrew Sullivan <[email-masked]>

Date: Mon, 23 Nov 2009 12:48:33 -0500

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

Subject: Re: [ietf-provreg] Is there a 4310-bis document?

On Mon, Nov 23, 2009 at 10:18:15AM -0500, Edward Lewis wrote:

> I'm curious...is anyone preparing a document?

I have a -00 draft (I mailed it at least once to the list), but it

didn't meet several people's needs.  My conclusion was that the draft<=
BR>
needed almost a complete rewrite, and this is no longer just an update

but a complete new specification.  I haven't had a chance to go back
to it.  If someone is dying to take over, I have XML that can be used.=

I'm happy to have my name dropped from the list in that case.

> (consider it).  Considering others are in production, is it a giv=
en that

> there will be backwards compatibility?

There will not be schema compatibility if we go the way currently

proposed.  If we go that way, it might be that old clients will work
fine with new servers.  James seemed to suggest at one point that

during a transition period, the way to get there would just be for

servers or clients or both to ignore parts of the new protocol.  This<=
BR>
answer makes my teeth hurt, but maybe we can get something cleaner.

A

--

Andrew Sullivan

[email-masked]

Shinkuro, Inc.

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

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

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

--B_3341828776_37544489--

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nANHmbKh011528 for ; Mon, 23 Nov 2009 18:48:37 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nANHmb4U002515 for ietf-provreg-outgoing; Mon, 23 Nov 2009 18:48:37 +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 nANHmaAo026704 for ; Mon, 23 Nov 2009 18:48:37 +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 DD2962FE8CA2 for ; Mon, 23 Nov 2009 17:48:35 +0000 (UTC)
Date: Mon, 23 Nov 2009 12:48:33 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] Is there a 4310-bis document?
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References:
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Mon, Nov 23, 2009 at 10:18:15AM -0500, Edward Lewis wrote:
> I'm curious...is anyone preparing a document?

I have a -00 draft (I mailed it at least once to the list), but it
didn't meet several people's needs. My conclusion was that the draft
needed almost a complete rewrite, and this is no longer just an update
but a complete new specification. I haven't had a chance to go back
to it. If someone is dying to take over, I have XML that can be used.
I'm happy to have my name dropped from the list in that case.

> (consider it). Considering others are in production, is it a given that
> there will be backwards compatibility?

There will not be schema compatibility if we go the way currently
proposed. If we go that way, it might be that old clients will work
fine with new servers. James seemed to suggest at one point that
during a transition period, the way to get there would just be for
servers or clients or both to ignore parts of the new protocol. This
answer makes my teeth hurt, but maybe we can get something cleaner.

A

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nANFINOR024696 for ; Mon, 23 Nov 2009 16:18:23 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nANFINnr008771 for ietf-provreg-outgoing; Mon, 23 Nov 2009 16:18:23 +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 nANFILq2027936 for ; Mon, 23 Nov 2009 16:18:22 +0100 (MET)
Received: from [10.31.200.222] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id nANFIIKu046028; Mon, 23 Nov 2009 10:18:18 -0500 (EST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References:
Date: Mon, 23 Nov 2009 10:18:15 -0500
To: EPP Provreg
From: Edward Lewis
Subject: [ietf-provreg] Is there a 4310-bis document?
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20
Sender: [email-masked]
Precedence: bulk

I'm curious...is anyone preparing a document?

I confess that I read the thread more or less ten days ago and have
forgotten the nuances. The first question is on backwards
compatibility. We have already implemented 4310, but, we aren't in
production with it. Although we would not want to redo this (As in
"how do you *want* to pay" want), if we had to for better stability
we could (consider it). Considering others are in production, is it
a given that there will be backwards compatibility?

Are the outstanding issues only related to being able to identify the
records needed to be changed? Or is there an issue that the client
needs to get feedback that the change has been
regsitered/made/propagated/served?

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

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nAKI0OUw025085 for ; Fri, 20 Nov 2009 19:00:24 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nAKI0Od2019268 for ietf-provreg-outgoing; Fri, 20 Nov 2009 19:00: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 nAKI0N5X005316 for ; Fri, 20 Nov 2009 19:00:24 +0100 (MET)
Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id nAKHhn60027769; Fri, 20 Nov 2009 12:43:49 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 13:00:22 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 Nov 2009 18:00:21 +0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Fri, 20 Nov 2009 13:00:17 -0500
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
From: James Gould
To: Klaus Malorny , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] Anyone working on 4310-bis?
Thread-Index: AcppPCo4tCIuYn/qSkmhpU7ey2EbSAAzybM8
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3341566820_35290387"
X-OriginalArrivalTime: 20 Nov 2009 18:00:22.0508 (UTC) FILETIME=[544E42C0:01CA6A0B]
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_3341566820_35290387
Content-type: text/plain;
charset="US-ASCII"
Content-transfer-encoding: 7bit

Klaus,

Interesting idea, but I believe that the client implementing a preset timer
is the simplest approach for both Registrar and Registry. The registry
could publish the global TTL set or allow for the TTL to be set
independently for each domain and publish the DNS latency SLA out-of-band.
Setting the TTL for a domain would be a good idea for a different EPP
extension. Creating a poll message for each update would be difficult for
the client to match up, since the poll messages are usually consumed
asynchronously using a single threaded session. Creating a poll message
would also be a challenge for the Registry since metrics would have to be
consolidated on a per domain basis across the DNS constellation. I would go
with the KISS approach on this one by using a preset timer on the client
side with reasonable and conservative estimates and optionally allow the
client to explicitly set the TTL for a domain in a separate EPP extension.

--

JG

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

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

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

From: Klaus Malorny
Date: Thu, 19 Nov 2009 11:51:48 -0500
To: EPP Provreg
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

Hi all,

I don't want to broaden the discussion even more, but I'd like to have your
comments on another question in the context of 4310-bis.

If a registrar issues a domain:update request which changes the DS data,
then
this is usually a part of the KSK rollover process. The rollover process
depends
on various timeouts, which rely on the TTLs of the DS records in the parent
zone
and the time of update of the DS records.

Both values -- the TTL of the DS records and the update time of the name
servers
-- are subject to the registry and are unavailable from the EPP point of
view.
Of course, one can simply poll the name servers of the parent zones and
check
whether the performed changes have become visible, or, even simpler, blindly
rely that it has happened after an ample amount of time.

On the other hand, if requested by the registrar, the EPP server *could*
send a
notification via the poll mechanism to the registrar, that the name servers
of
the registry now reflect the changes of a specific update that had been
processed successfully earlier. TTLs could be reported at the same time.

This could not only make sense in the context of DNSSEC, but also for name
server changes as well, and could also include create and delete requests,
if
need be.

Now, would you consider such a feature as useful, as a complete nonsense,
maybe
as something in-between? Would such a feature be worth the effort? If so,
should
it be included in 4310-bis?

Regards,

Klaus

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

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

Re: [ietf-provreg] Anyone working on 4310-bis?

Klaus,

Interesting idea, but I believe that the client implementing a preset timer=
is the simplest approach for both Registrar and Registry.  The registr=
y could publish the global TTL set or allow for the TTL to be set independen=
tly for each domain and publish the DNS latency SLA out-of-band.  Setti=
ng the TTL for a domain would be a good idea for a different EPP extension. =
Creating a poll message for each update would be difficult for the cli=
ent to match up, since the poll messages are usually consumed asynchronously=
using a single threaded session.  Creating a poll message would also b=
e a challenge for the Registry since metrics would have to be consolidated o=
n a per domain basis across the DNS constellation.  I would go with the=
KISS approach on this one by using a preset timer on the client side with r=
easonable and conservative estimates and optionally allow the client to expl=
icitly set the TTL for a domain in a separate EPP extension.   &nb=
sp;

--

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: Thu, 19 Nov 2009 11:51:48 -0500

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

Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

Hi all,

I don't want to broaden the discussion even more, but I'd like to have your=

comments on another question in the context of 4310-bis.

If a registrar issues a domain:update request which changes the DS data, th=
en

this is usually a part of the KSK rollover process. The rollover process de=
pends

on various timeouts, which rely on the TTLs of the DS records in the parent=
zone

and the time of update of the DS records.

Both values -- the TTL of the DS records and the update time of the name se=
rvers

-- are subject to the registry and are unavailable from the EPP point of vi=
ew.

Of course, one can simply poll the name servers of the parent zones and che=
ck

whether the performed changes have become visible, or, even simpler, blindl=
y

rely that it has happened after an ample amount of time.

On the other hand, if requested by the registrar, the EPP server *could* se=
nd a

notification via the poll mechanism to the registrar, that the name servers=
of

the registry now reflect the changes of a specific update that had been

processed successfully earlier. TTLs could be reported at the same time.

This could not only make sense in the context of DNSSEC, but also for name<=
BR>
server changes as well, and could also include create and delete requests, =
if

need be.

Now, would you consider such a feature as useful, as a complete nonsense, m=
aybe

as something in-between? Would such a feature be worth the effort? If so, s=
hould

it be included in 4310-bis?

Regards,

Klaus

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

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

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

--B_3341566820_35290387--

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nAJGpw8g000825 for ; Thu, 19 Nov 2009 17:51:58 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nAJGpwfQ021274 for ietf-provreg-outgoing; Thu, 19 Nov 2009 17:51:58 +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 nAJGpw7u011331 for ; Thu, 19 Nov 2009 17:51:58 +0100 (MET)
Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 933EC106; Thu, 19 Nov 2009 17:51:51 +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 wsqUV2NUNrfF; Thu, 19 Nov 2009 17:51:48 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id DF5CA104; Thu, 19 Nov 2009 17:51:47 +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 nAJGplSr007080; Thu, 19 Nov 2009 17:51:47 +0100 (MEZ)
Message-ID: <[email-masked]>
Date: Thu, 19 Nov 2009 17:51:48 +0100
From: Klaus Malorny
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.5) Gecko/20091118 Shredder/3.0.1pre
MIME-Version: 1.0
To: EPP Provreg
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
References:
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

Hi all,

I don't want to broaden the discussion even more, but I'd like to have your
comments on another question in the context of 4310-bis.

If a registrar issues a domain:update request which changes the DS data, then
this is usually a part of the KSK rollover process. The rollover process depends
on various timeouts, which rely on the TTLs of the DS records in the parent zone
and the time of update of the DS records.

Both values -- the TTL of the DS records and the update time of the name servers
-- are subject to the registry and are unavailable from the EPP point of view.
Of course, one can simply poll the name servers of the parent zones and check
whether the performed changes have become visible, or, even simpler, blindly
rely that it has happened after an ample amount of time.

On the other hand, if requested by the registrar, the EPP server *could* send a
notification via the poll mechanism to the registrar, that the name servers of
the registry now reflect the changes of a specific update that had been
processed successfully earlier. TTLs could be reported at the same time.

This could not only make sense in the context of DNSSEC, but also for name
server changes as well, and could also include create and delete requests, if
need be.

Now, would you consider such a feature as useful, as a complete nonsense, maybe
as something in-between? Would such a feature be worth the effort? If so, should
it be included in 4310-bis?

Regards,

Klaus

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nAGEZFgX012559 for ; Mon, 16 Nov 2009 15:35:15 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nAGEZFW9018892 for ietf-provreg-outgoing; Mon, 16 Nov 2009 15:35:15 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nAGEZD1m027735 for ; Mon, 16 Nov 2009 15:35:14 +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 nAGEWRlU029185; Mon, 16 Nov 2009 09:32:27 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 14:35:12 +0000
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Mon, 16 Nov 2009 14:35:11 +0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Mon, 16 Nov 2009 09:35:03 -0500
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
From: James Gould
To: Klaus Malorny
CC: EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] Anyone working on 4310-bis?
Thread-Index: AcpdjTwHD45722vAQVKNshp5XPZ7YgJPL+i5
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3341208905_27097341"
X-OriginalArrivalTime: 16 Nov 2009 14:35:12.0565 (UTC) FILETIME=[015B0650:01CA66CA]
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_3341208905_27097341
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Klaus,

Sorry for the late reply to your post, since you raise some good questions.
I believe that the clients should specify the dsData with the keyData for
optional validation for maximum flexibility to the client, but if there is
the need to support a keyData interface then the specification can support
it. =20

=B3So we would allow either to

* [DS]: specify only the DS data

* [KEY]: specify only the DNSKEY data; the registry would be responsible
to
generate DS record(s) from it

* [DS/KEY]: specify both DS and DNSKEY data; the registry would either
silently ignore the DS data and use the key data as in [KEY], or use
the DNSKEY to verify the correctness of the DS data. I wouldn't
recommend the first case, though.
=B3

The [DS] and [DS/KEY] models make sense, and the ladder interpretation of
[DS/KEY] seems like the better one, where it is really [DS] with the
optional use of the key data for validation. The server should support
either the [DS] / [DS/KEY] model or the [KEY] model and not both.

=B3In the section of an , how can a user remove an existing
entry?

* a [DS] entry could remove an existing [DS] or [DS/KEY] entry,
but it probably should not be able to remove a [KEY] entry
* a [KEY] entry could remove an existing [KEY], [DS/KEY] entry
or multiple [DS] entries (e.g. with different digest types),
but the latter is probably not recommended
* a [DS/KEY] entry could remove all three types
=B3

The [DS] entry should remove a single DS data record. If there are multipl=
e
DS data records with the same [KEY] the SHOULD not more then one DS
data records as a side effect. This is the wildcard scenario. I would
imagine with the [KEY] interface that the server is responsible for the
generation of the associated DS records, so a removal of a [KEY] entry
should remove all DS records for that [KEY] entry. [DS/KEY] doesn=B9t make
much sense on a since I view [DS/KEY] as [DS] with optional keyData
validation, which is not needed on a remove. It would be good if the serve=
r
returned an error if both the dsData and the keyData is passed on a t=
o
reduce confusion. =20

=B3I believe that the element should be removed from the group
definition and put directly into the sequence, so that it may be also
specified
in a key data only solution. Or shall it not be applicable in this case?
I.e.:
=B3

I=B9m not sure if the client specified maxSigLife makes much sense for the
[KEY] interface since the DS data becomes the responsibility of the server.
Do any of the registries looking to support the [KEY] interface have an
opinion on this one?

--=20

JG=20

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

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

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

From: Klaus Malorny
Date: Wed, 4 Nov 2009 15:06:57 -0500
Cc: EPP Provreg
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

On 04/11/09 14:31, Ulrich Wisser wrote:
>> So there are registries out there looking to support a keyData
>> interface for
>> DNSSEC, where the client would pass just the keyData on an add/rem/chg?
>> Would the DS data be returned in the info response?
>
> James, I've heard from several registries considering it. But I have no
> input about this from registrars. From a registry standpoint dealing
> with keys instead of ds records makes operations much simpler.
>
> We would not return DS data. .SE would put two DS records for each key
> in the zone file. So returning DS records would mean to return the key
> twice. With the proposed change we would return the key data in the info
> command.
>
> /Ulrich

Hi all,

sorry for flooding the list, but I prefer to keep issues separated.

I'd like to dig a little bit deeper on this dsData/keyData issue:

So we would allow either to

* [DS]: specify only the DS data

* [KEY]: specify only the DNSKEY data; the registry would be responsible
to
generate DS record(s) from it

* [DS/KEY]: specify both DS and DNSKEY data; the registry would either
silently ignore the DS data and use the key data as in [KEY], or use
the DNSKEY to verify the correctness of the DS data. I wouldn't
recommend the first case, though.

in and requests?

It would be upon the registry policy which of the three (including any
combination of them) would be accepted.

In the section of an , how can a user remove an existing
entry?

* a [DS] entry could remove an existing [DS] or [DS/KEY] entry,
but it probably should not be able to remove a [KEY] entry
* a [KEY] entry could remove an existing [KEY], [DS/KEY] entry
or multiple [DS] entries (e.g. with different digest types),
but the latter is probably not recommended
* a [DS/KEY] entry could remove all three types

Again, it would probably be the best to define the acceptable ways as a
registry
policy, wouldn't it?

For the request, I would like propose that the answer returns exactl=
y
the
data that has been specified in the / requests.

However, different answers could be imaginable:

* a [KEY] could be returned either as the respective [DS] entries
(maybe even in addition).
* [DS/KEY] could be returned as [DS] only.

One final thing:

I believe that the element should be removed from the group
definition and put directly into the sequence, so that it may be also
specified
in a key data only solution. Or shall it not be applicable in this case?
I.e.:

Regards,

Klaus

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

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

Re: [ietf-provreg] Anyone working on 4310-bis?

Klaus,

Sorry for the late reply to your post, since you raise some good questions.=
I believe that the clients should specify the dsData with the keyData=
for optional validation for maximum flexibility to the client, but if there=
is the need to support a keyData interface then the specification can suppo=
rt it.

“So we would allow either to

* [DS]: specify only the DS data

* [KEY]: specify only the DNSKEY data; the registry would be re=
sponsible to

generate DS record(s) from it

* [DS/KEY]: specify both DS and DNSKEY data; the registry would=
either

silently ignore the DS data and use the key data as=
in [KEY], or use

the DNSKEY to verify the correctness of the DS data=
. I wouldn't

recommend the first case, though.

“

The [DS] and [DS/KEY] models make sense, and the ladder interpretation of [=
DS/KEY] seems like the better one, where it is really [DS] with the optional=
use of the key data for validation.  The server should support either =
the [DS] / [DS/KEY] model or the [KEY] model and not both.

“In the <rem> section of an <update>, how can a user remo=
ve an existing entry?

* a [DS] entry could remove an existing [DS] or [DS/KEY] entry,

but it probably should not be able to remove a [KEY] entr=
y

* a [KEY] entry could remove an existing [KEY], [DS/KEY] entry

or multiple [DS] entries (e.g. with different digest type=
s),

but the latter is probably not recommended

* a [DS/KEY] entry could remove all three types

“

The [DS] entry should remove a single DS data record.  If there are mu=
ltiple DS data records with the same [KEY] the <rem> SHOULD not more t=
hen one DS data records as a side effect.  This is the wildcard scenari=
o.  I would imagine with the [KEY] interface that the server is respons=
ible for the generation of the associated DS records, so a removal of a [KEY=
] entry should remove all DS records for that [KEY] entry.  [DS/KEY] do=
esn’t make much sense on a <rem> since I view [DS/KEY] as [DS] w=
ith optional keyData validation, which is not needed on a remove.  It w=
ould be good if the server returned an error if both the dsData and the keyD=
ata is passed on a <rem> to reduce confusion.

“I believe that the <maxSigLife> element should be removed from=
the group

definition and put directly into the sequence, so that it may be also speci=
fied

in a key data only solution. Or shall it not be applicable in this case? I.=
e.:

“

I’m not sure if the client specified maxSigLife makes much sense for =
the [KEY] interface since the DS data becomes the responsibility of the serv=
er.  Do any of the registries looking to support the [KEY] interface ha=
ve an opinion on this one?

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

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

From: Klaus Malorny <[email-masked]>

Date: Wed, 4 Nov 2009 15:06:57 -0500

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

Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

On 04/11/09 14:31, Ulrich Wisser wrote:

>> So there are registries out there looking to support a keyData

>> interface for

>> DNSSEC, where the client would pass just the keyData on an add/rem=
/chg?

>> Would the DS data be returned in the info response?

> James, I've heard from several registries considering it. But I have n=
o

> input about this from registrars. From a registry standpoint dealing
> with keys instead of ds records makes operations much simpler.

> We would not return DS data. .SE would put two DS records for each key=

> in the zone file. So returning DS records would mean to return the key=

> twice. With the proposed change we would return the key data in the in=
fo

> command.

> /Ulrich

Hi all,

sorry for flooding the list, but I prefer to keep issues separated.

I'd like to dig a little bit deeper on this dsData/keyData issue:

So we would allow either to

* [DS]: specify only the DS data

* [KEY]: specify only the DNSKEY data; the registry would be re=
sponsible to

generate DS record(s) from it

* [DS/KEY]: specify both DS and DNSKEY data; the registry would=
either

silently ignore the DS data and use the key data as=
in [KEY], or use

the DNSKEY to verify the correctness of the DS data=
. I wouldn't

recommend the first case, though.

in <create> and <update> requests?

It would be upon the registry policy which of the three (including any

combination of them) would be accepted.

In the <rem> section of an <update>, how can a user remove an e=
xisting entry?

* a [DS] entry could remove an existing [DS] or [DS/KEY] entry,

but it probably should not be able to remove a [KEY] entr=
y

* a [KEY] entry could remove an existing [KEY], [DS/KEY] entry

or multiple [DS] entries (e.g. with different digest type=
s),

but the latter is probably not recommended

* a [DS/KEY] entry could remove all three types

Again, it would probably be the best to define the acceptable ways as a reg=
istry

policy, wouldn't it?

For the <info> request, I would like propose that the answer returns =
exactly the

data that has been specified in the <create>/<update> requests.=

However, different answers could be imaginable:

* a [KEY] could be returned either as the respective [DS] entries

(maybe even in addition).

* [DS/KEY] could be returned as [DS] only.

One final thing:

I believe that the <maxSigLife> element should be removed from the gr=
oup

definition and put directly into the sequence, so that it may be also speci=
fied

in a key data only solution. Or shall it not be applicable in this case? I.=
e.:

<complexType name=3D"dsDataType">

<sequence>

<group minOccurs=3D"0">

<sequence>

<element name=3D&quo=
t;keyTag"     type=3D"unsignedShort"/>
<element name=3D&quo=
t;alg"        type=3D"unsignedByt=
e"/>

<element name=3D&quo=
t;digestType" type=3D"unsignedByte"/>

<element name=3D&quo=
t;digest"     type=3D"hexBinary"/>

</sequence>

</group>

<element name=3D"maxSigLife" type=3D=
"secDNS:maxSigLifeType"

minOccurs=3D"0"/>

<element name=3D"keyData" type=3D&qu=
ot;secDNS:keyDataType"

minOccurs=3D"0"/>

</sequence>

</complexType>

Regards,

Klaus

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

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

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

--B_3341208905_27097341--

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA5DULfv029570 for ; Thu, 5 Nov 2009 14:30:21 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA5DULEQ028593 for ietf-provreg-outgoing; Thu, 5 Nov 2009 14:30:21 +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 nA5DUKis004684 for ; Thu, 5 Nov 2009 14:30:21 +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 nA5DEHcI013531; Thu, 5 Nov 2009 08:14:17 -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, 5 Nov 2009 13:30:20 +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: RE: [ietf-provreg] Anyone working on 4310-bis?
Date: Thu, 5 Nov 2009 08:30:19 -0500
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] Anyone working on 4310-bis?
thread-index: AcpeGOtDDQJHzrZDTAabqlbew+A5/gAARdVw
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
From: "Hollenbeck, Scott"
To: "Klaus Malorny"
Cc: "EPP Provreg"
X-OriginalArrivalTime: 05 Nov 2009 13:30:20.0080 (UTC) FILETIME=[1EB5B300:01CA5E1C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id nA5DULis026107
Sender: [email-masked]
Precedence: bulk

> -----Original Message-----
> From: Klaus Malorny [mailto:[email-masked]]
> Sent: Thursday, November 05, 2009 8:07 AM
> To: Hollenbeck, Scott
> Cc: EPP Provreg
> Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
>
> On 05/11/09 13:16, Hollenbeck, Scott wrote:
>
> > I'm referring to XML command structures for which an order can be
> > explicitly specified, such as elements within a sequence. It's
> > certainly not a new concept because the specifications have
> been this
> > way since the very beginning (the same quote can be found
> in RFC 3730
> > from 2004). If the order wasn't intended to be significant
> I wouldn't
> > have used sequences.
> >
> > Scott
> >
>
> Well, XML is not a not a command structure but a hierarchical
> syntax for documents, with XML Schema being one of multiple
> choices of overlaying it with rules. Anyway, for my taste
> tying the logic of a high level protocol that tightly to its
> transport representation is a design weakness, more
> abstraction would be a boon. But it is wasted time to argue
> -- it is nothing new that we have diametric opinions on
> certain topics...

"XML command structures" should be interpreted as "XML Schema used to
specify EPP commands". Sorry for not being more specific, but given
what we're talking about I didn't think my meaning was unclear.

In this context, more abstraction makes for just the kind of uncertainty
("what happens if you do a before an or vice-versa?") that
we're seeing on the list right now. You're certainly correct in
suggesting that there are situations where more abstraction is
beneficial, but a lack of specificity in this particular situation
(add/rem processing order) can lead to non-deterministic behavior.
*That's* a weakness.

Scott

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA5D7Mwn028036 for ; Thu, 5 Nov 2009 14:07:22 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA5D7MDu019146 for ietf-provreg-outgoing; Thu, 5 Nov 2009 14:07:22 +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 nA5D7MLg005304 for ; Thu, 5 Nov 2009 14:07:22 +0100 (MET)
Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 168561A4; Thu, 5 Nov 2009 14:07:22 +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 BEQw4lZXw2kv; Thu, 5 Nov 2009 14:07:16 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 56CA51A2; Thu, 5 Nov 2009 14:07:16 +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 nA5D7F6I021353; Thu, 5 Nov 2009 14:07:16 +0100 (MEZ)
Message-ID: <[email-masked]>
Date: Thu, 05 Nov 2009 14:07:15 +0100
From: Klaus Malorny
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.6pre) Gecko/20091104 Shredder/3.0pre
MIME-Version: 1.0
To: "Hollenbeck, Scott"
CC: EPP Provreg
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

On 05/11/09 13:16, Hollenbeck, Scott wrote:

> I'm referring to XML command structures for which an order can be
> explicitly specified, such as elements within a sequence. It's
> certainly not a new concept because the specifications have been this
> way since the very beginning (the same quote can be found in RFC 3730
> from 2004). If the order wasn't intended to be significant I wouldn't
> have used sequences.
>
> Scott
>

Well, XML is not a not a command structure but a hierarchical syntax for
documents, with XML Schema being one of multiple choices of overlaying it with
rules. Anyway, for my taste tying the logic of a high level protocol that
tightly to its transport representation is a design weakness, more abstraction
would be a boon. But it is wasted time to argue -- it is nothing new that we
have diametric opinions on certain topics...

Regards,

Klaus

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA5CGwim001085 for ; Thu, 5 Nov 2009 13:16:58 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA5CGwqr008589 for ietf-provreg-outgoing; Thu, 5 Nov 2009 13:16:58 +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 nA5CGvKo017779 for ; Thu, 5 Nov 2009 13:16:57 +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 nA5CEUv5022344; Thu, 5 Nov 2009 07:14:31 -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, 5 Nov 2009 07:17:11 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [ietf-provreg] Anyone working on 4310-bis?
Date: Thu, 5 Nov 2009 07:16:55 -0500
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] Anyone working on 4310-bis?
thread-index: AcpdjhdWpdLsvXpuSYyri+490u0OwgAgfavA
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
From: "Hollenbeck, Scott"
To: "Klaus Malorny"
Cc: "EPP Provreg"
X-OriginalArrivalTime: 05 Nov 2009 12:17:11.0581 (UTC) FILETIME=[E6F5E4D0:01CA5E11]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id nA5CGvKo024866
Sender: [email-masked]
Precedence: bulk

> -----Original Message-----
> From: Klaus Malorny [mailto:[email-masked]]
> Sent: Wednesday, November 04, 2009 3:34 PM
> To: Hollenbeck, Scott
> Cc: Andrew Sullivan; EPP Provreg
> Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
>
> On 04/11/09 21:05, Hollenbeck, Scott wrote:
>
> > Section 2 of 5730 very clearly states that "Commands are
> processed by
> > a server in the order they are received from a client." If
> an
> > is received before a it should be processed first.
> >
> > Scott
> >
>
> Hi Scott,
>
> up to now I interpreted the term "command" in this sentence
> in respect to the "epp:commandType" in the
> "urn:ietf:params:xml:ns:epp-1.0" name space as an atomic
> piece of work. The definition as low level sequences of
> characters forming text contents, attributes, elements,
> comments, processing instructions and so on, representing
> individual tiny commands within the big one, is a fairly new
> and dubious concept to me, especially as the XML infoset[1]
> does not regard the order of attributes in the document as
> relevant and parsers and generators are free to change it.
>
> But thanks for clarification.
>
> Regards,
>
> Klaus
>
>
> [1] http://www.w3.org/TR/xml-infoset Appendix D, 10.

I'm referring to XML command structures for which an order can be
explicitly specified, such as elements within a sequence. It's
certainly not a new concept because the specifications have been this
way since the very beginning (the same quote can be found in RFC 3730
from 2004). If the order wasn't intended to be significant I wouldn't
have used sequences.

Scott

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA4LiPUL027609 for ; Wed, 4 Nov 2009 22:44:25 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA4LiPIq018759 for ietf-provreg-outgoing; Wed, 4 Nov 2009 22:44:25 +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 nA4LiO0T026249 for ; Wed, 4 Nov 2009 22:44:24 +0100 (MET)
Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id nA4LSMpD008735; Wed, 4 Nov 2009 16:28:22 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 16:44:23 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Wed, 4 Nov 2009 21:44:22 +0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Wed, 04 Nov 2009 16:44:17 -0500
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
From: James Gould
To: Andrew Sullivan , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] Anyone working on 4310-bis?
Thread-Index: AcpdZgtkF/s0+HN0To6B7th+HS3ZLgAMenik
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: text/plain; charset="EUC-KR"
X-OriginalArrivalTime: 04 Nov 2009 21:44:23.0426 (UTC) FILETIME=[F91B9620:01CA5D97]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id nA4LiP0T004526
Sender: [email-masked]
Precedence: bulk

Andrew,

I answer your questions below. I believe the only contention point that we
have is the handling the wildcard rem keyTag which I've responded to below.
Is there any objections to the proposed XML schema updates, since this is
the key to me? We can work out the details of the text changes made to the
specification.

¡°What do you mean by this exactly? It seems that you are proposing
changing the schema in such a way that the schema is not actually
backward compatible, because you want to make it protocol-impossible
for someone to delete all DS data just by using the keyTag. I think
that requires that the schemas are formally incompatible. Doesn't it?¡±

A client that implements the existing version of the specification will not
fail due to XML schema validation if interfacing with a server that supports
the new specification. It will be up to the server to decide when to apply
the dsKey wildcard policy to comply with the latest specification, but from
a client interface perspective the proposed XML schema is fully backward
compatible. Clients should be notified with an error message if they were
not specific enough to remove an individual DS record. If the client does
not have an issue with multiple DS with the same keyTag for a domain, then
the new specification will work for them even if they provide just the
keyTag on a remove.

¡°I think I don't know what "primary interface" means in the above. If
you mean that the I-D should say something like "A server MUST accept
either dsData or keyData, and SHOULD NOT accept both," it makes sense
to me.¡±

I mean ¡°primary interface¡± to indicate the significant (primary) fields used
for transform commands. The current specification uses dsData as the
primary interface with keyData as optional to support additional server-side
validation, which should continue to be supported. To support keyData as
the primary interface I¡¯m assuming that the dsData SHOULD NOT be provided.
If the client specifies dsData or dsData and keyData then they are
implementing the dsData primary interface, and if the client just specifies
the keyData then they are implementing the keyData primary interface. The
server MUST NOT mix both dsData as the primary interface as well as keyData
as the primary interface. Of course the server could decide to not fully
follow the new specification during a migration period just like with the
dsKey wildcard policy.

¡°Nobody has yet responded to my contention that this is a policy
matter, and shouldn't be required by the protocol. You don't happen
to have a deployed system using 4310 yet, so it isn't a concern to
you, but it seems to me that there are people who do have such
deployed systems, and the above requirement effectively requires them
to have a flag day. Why does that need to be a protocol mandate, when
we can do it with registry policy?¡±

I believe that this is one of the issues with the current specification that
requires a remedy. We could have a system deployed prior to agreement and
implementation of the updated specification, so we could be impacted by
this. It can be up to the server when to fully support the latest
specification (the flag day), but I foresee confusion with the Registrars if
some servers by Registry policy support the keyTag rem without returning an
error when more then one DS record is impacted. Our current plan is to
remove all matching DS records on a keyTag rem using the current
specification, so we will have a flag day if we plan on deploying with the
current specification prior to supporting the new specification. Maybe it
makes sense to define an either or option in the specification in support
the keyTag rem or the dsData rem, where there is a period of time the server
will support both for migration. Either that or we can weaken the text of
the specification to SHOULD instead of MUST, but I really believe it is bad
behavior for the server to support the wildcard keyTag rem if the dsData rem
is supported.

¡°I think the I-D I circulated already contains such language.¡±

I don¡¯t believe that ¡°The element is used to replace existing
DS information with new DS information¡± is clear enough since it could mean
replace the attributes associated with the existing matching DS information
by keyTag with the new attributes. It would be clearer to state something
like "The element is used to replace all existing DS
information with new DS information. For example, if three DS records exist
and the includes two elements that the three DS
records will be replaced with the two elements.". We
debated the interpretation of the sentence in implementing 4310, so it would
help to add a little bit more clarity.

"Why? In the mainline EPP specification, if you remove and add the
same name servers in a single command, it doesn't cause an error. (I
know this because misguided registrars used to do it all the time in
an effort to get the "primary" name server "listed first".) It's a
waste of bandwidth, but since EPP is idempotent it should have no
effect, right?"

I just want to put to rest the thread on how the add and rem is processed on
the server side. I really don't believe this should be an issue, but if a
few lines of text will help clear any concerns around supporting add and rem
together I'm fine with it. Our server will return an error if the client
attempts to add and remove the same name server. I don't want anything in
the specification stating something like "the removes need to be processed
prior to the adds" to address this corner case.

"These are already errors, I think, no?"

Yes, it might be overkill to state the obvious, but just to make sure it's
clear how the add and rem are used together. If everyone is fine with
adding support for using the add and rem together without any additional
explanatory text, I'm fine with it.

--

JG

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

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

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

From: Andrew Sullivan
Date: Wed, 4 Nov 2009 10:21:19 -0500
To: EPP Provreg
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

On Wed, Nov 04, 2009 at 09:43:23AM -0500, James Gould wrote:
> All,
>
> Before we continue to go around in circles, can I propose an option that
> addresses most of everyone©ös concerns, where the following would be met?
>
> 1. XML schema is backward compatible

What do you mean by this exactly? It seems that you are proposing
changing the schema in such a way that the schema is not actually
backward compatible, because you want to make it protocol-impossible
for someone to delete all DS data just by using the keyTag. I think
that requires that the schemas are formally incompatible. Doesn't it?

> 4. Support for a dsData and keyData primary interface. Only one primary
> interface should be supported by the server.

I think I don't know what "primary interface" means in the above. If
you mean that the I-D should say something like "A server MUST accept
either dsData or keyData, and SHOULD NOT accept both," it makes sense
to me.

> 5. Remove support for the wildcard delete of dsData in the rem by just using
> the keyTag with a clear statement (i.e. Server must return error if the
> keyTag matches multiple DS records) in the specification. From my
> perspective and I believe a couple others this is a key issue that must be
> addressed.

Nobody has yet responded to my contention that this is a policy
matter, and shouldn't be required by the protocol. You don't happen
to have a deployed system using 4310 yet, so it isn't a concern to
you, but it seems to me that there are people who do have such
deployed systems, and the above requirement effectively requires them
to have a flag day. Why does that need to be a protocol mandate, when
we can do it with registry policy?

> 6. Clarity in the specification on the use of the chg as a replace or a
> ©øchange all©÷.

I think the I-D I circulated already contains such language.

> 7. Clarity around the corner case of a client attempting to add and remove
> the same dsData or keyData in a single command. This must result in an
> error from the server.

Why? In the mainline EPP specification, if you remove and add the
same name servers in a single command, it doesn't cause an error. (I
know this because misguided registrars used to do it all the time in
an effort to get the "primary" name server "listed first".) It's a
waste of bandwidth, but since EPP is idempotent it should have no
effect, right?

> Additionally an error must be returned if the client
> tries to remove dsData or keyData that does not exist or tries to add dsData
> or keyData that already exists.

These are already errors, I think, no?

A

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

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA4KXggM019167 for ; Wed, 4 Nov 2009 21:33:42 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA4KXgkJ005948 for ietf-provreg-outgoing; Wed, 4 Nov 2009 21:33:42 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from kmx10a.knipp.de (clust3a-eth0-0.bbone.knipp.de [195.253.6.83]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA4KXg9a004243 for ; Wed, 4 Nov 2009 21:33:42 +0100 (MET)
Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 01BAA1A2; Wed, 4 Nov 2009 21:33:36 +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 ntmTcVxGlsVz; Wed, 4 Nov 2009 21:33:30 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 6078C1A0; Wed, 4 Nov 2009 21:33:30 +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 nA4KXTn8026306; Wed, 4 Nov 2009 21:33:29 +0100 (MEZ)
Message-ID: <[email-masked]>
Date: Wed, 04 Nov 2009 21:33:30 +0100
From: Klaus Malorny
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.6pre) Gecko/20091104 Shredder/3.0pre
MIME-Version: 1.0
To: "Hollenbeck, Scott"
CC: Andrew Sullivan , EPP Provreg
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

On 04/11/09 21:05, Hollenbeck, Scott wrote:

> Section 2 of 5730 very clearly states that "Commands are processed by a
> server in the order they are received from a client." If an is
> received before a it should be processed first.
>
> Scott
>

Hi Scott,

up to now I interpreted the term "command" in this sentence in respect to the
"epp:commandType" in the "urn:ietf:params:xml:ns:epp-1.0" name space as an
atomic piece of work. The definition as low level sequences of characters
forming text contents, attributes, elements, comments, processing instructions
and so on, representing individual tiny commands within the big one, is a fairly
new and dubious concept to me, especially as the XML infoset[1] does not regard
the order of attributes in the document as relevant and parsers and generators
are free to change it.

But thanks for clarification.

Regards,

Klaus

[1] http://www.w3.org/TR/xml-infoset Appendix D, 10.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA4K78Mc005234 for ; Wed, 4 Nov 2009 21:07:08 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA4K78ej000656 for ietf-provreg-outgoing; Wed, 4 Nov 2009 21:07: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 nA4K78Jp026925 for ; Wed, 4 Nov 2009 21:07:08 +0100 (MET)
Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id E694016A; Wed, 4 Nov 2009 21:07:01 +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 4wMWmvqHMhFr; Wed, 4 Nov 2009 21:06:56 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 6714416B; Wed, 4 Nov 2009 21:06:56 +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 nA4K6uNI022708; Wed, 4 Nov 2009 21:06:56 +0100 (MEZ)
Message-ID: <[email-masked]>
Date: Wed, 04 Nov 2009 21:06:57 +0100
From: Klaus Malorny
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.6pre) Gecko/20091104 Shredder/3.0pre
MIME-Version: 1.0
CC: [email-masked]
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
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 04/11/09 14:31, Ulrich Wisser wrote:
>> So there are registries out there looking to support a keyData
>> interface for
>> DNSSEC, where the client would pass just the keyData on an add/rem/chg?
>> Would the DS data be returned in the info response?
>
> James, I've heard from several registries considering it. But I have no
> input about this from registrars. From a registry standpoint dealing
> with keys instead of ds records makes operations much simpler.
>
> We would not return DS data. .SE would put two DS records for each key
> in the zone file. So returning DS records would mean to return the key
> twice. With the proposed change we would return the key data in the info
> command.
>
> /Ulrich

Hi all,

sorry for flooding the list, but I prefer to keep issues separated.

I'd like to dig a little bit deeper on this dsData/keyData issue:

So we would allow either to

* [DS]: specify only the DS data

* [KEY]: specify only the DNSKEY data; the registry would be responsible to
generate DS record(s) from it

* [DS/KEY]: specify both DS and DNSKEY data; the registry would either
silently ignore the DS data and use the key data as in [KEY], or use
the DNSKEY to verify the correctness of the DS data. I wouldn't
recommend the first case, though.

in and requests?

It would be upon the registry policy which of the three (including any
combination of them) would be accepted.

In the section of an , how can a user remove an existing entry?

* a [DS] entry could remove an existing [DS] or [DS/KEY] entry,
but it probably should not be able to remove a [KEY] entry
* a [KEY] entry could remove an existing [KEY], [DS/KEY] entry
or multiple [DS] entries (e.g. with different digest types),
but the latter is probably not recommended
* a [DS/KEY] entry could remove all three types

Again, it would probably be the best to define the acceptable ways as a registry
policy, wouldn't it?

For the request, I would like propose that the answer returns exactly the
data that has been specified in the / requests.

However, different answers could be imaginable:

* a [KEY] could be returned either as the respective [DS] entries
(maybe even in addition).
* [DS/KEY] could be returned as [DS] only.

One final thing:

I believe that the element should be removed from the group
definition and put directly into the sequence, so that it may be also specified
in a key data only solution. Or shall it not be applicable in this case? I.e.:

Regards,

Klaus

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA4K5cBv006083 for ; Wed, 4 Nov 2009 21:05:38 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA4K5coq019962 for ietf-provreg-outgoing; Wed, 4 Nov 2009 21:05:38 +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 nA4K5bZ2004041 for ; Wed, 4 Nov 2009 21:05:37 +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 nA4JnZa2003985; Wed, 4 Nov 2009 14:49:35 -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); Wed, 4 Nov 2009 20:05:36 +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: RE: [ietf-provreg] Anyone working on 4310-bis?
Date: Wed, 4 Nov 2009 15:05:34 -0500
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] Anyone working on 4310-bis?
thread-index: AcpdiTxN+Ip/cKHmRg6HYXT0lFgJpAAACexg
References: <[email-masked]> <[email-masked]> <[email-masked]>
From: "Hollenbeck, Scott"
To: "Klaus Malorny" , "Andrew Sullivan" , "EPP Provreg"
X-OriginalArrivalTime: 04 Nov 2009 20:05:36.0310 (UTC) FILETIME=[2C457560:01CA5D8A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id nA4K5bZ2010502
Sender: [email-masked]
Precedence: bulk

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Klaus Malorny
> Sent: Wednesday, November 04, 2009 2:36 PM
> To: Andrew Sullivan; EPP Provreg
> Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
>
> On 04/11/09 16:21, Andrew Sullivan wrote:
>
> >> 7. Clarity around the corner case of a client attempting
> to add and
> >> remove the same dsData or keyData in a single command. This must
> >> result in an error from the server.
> >
> > Why? In the mainline EPP specification, if you remove and add the
> > same name servers in a single command, it doesn't cause an
> error. (I
> > know this because misguided registrars used to do it all
> the time in
> > an effort to get the "primary" name server "listed first".) It's a
> > waste of bandwidth, but since EPP is idempotent it should have no
> > effect, right?
> >
>
> Hi Andrew,
>
> I am quite sure that RFC 5731 and its predecessors do not
> define how to handle this case and that the problem is left
> as an exercise to the implementor. As I regard this as a flaw
> in the protocol, I would appreciate a statement in 4310bis
> regarding such a state.

Section 2 of 5730 very clearly states that "Commands are processed by a
server in the order they are received from a client." If an is
received before a it should be processed first.

Scott

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA4JaTVK019312 for ; Wed, 4 Nov 2009 20:36:29 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA4JaTeB027400 for ietf-provreg-outgoing; Wed, 4 Nov 2009 20:36: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 nA4JaTVo018989 for ; Wed, 4 Nov 2009 20:36:29 +0100 (MET)
Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id C104018B; Wed, 4 Nov 2009 20:36:22 +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 l6a0bJ59Ye3y; Wed, 4 Nov 2009 20:36:17 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 2A4B118A; Wed, 4 Nov 2009 20:36: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 nA4JaGEs018712; Wed, 4 Nov 2009 20:36:16 +0100 (MEZ)
Message-ID: <[email-masked]>
Date: Wed, 04 Nov 2009 20:36:17 +0100
From: Klaus Malorny
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.6pre) Gecko/20091104 Shredder/3.0pre
MIME-Version: 1.0
To: Andrew Sullivan , EPP Provreg
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
References: <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

On 04/11/09 16:21, Andrew Sullivan wrote:

>> 7. Clarity around the corner case of a client attempting to add and remove
>> the same dsData or keyData in a single command. This must result in an
>> error from the server.
>
> Why? In the mainline EPP specification, if you remove and add the
> same name servers in a single command, it doesn't cause an error. (I
> know this because misguided registrars used to do it all the time in
> an effort to get the "primary" name server "listed first".) It's a
> waste of bandwidth, but since EPP is idempotent it should have no
> effect, right?
>

Hi Andrew,

I am quite sure that RFC 5731 and its predecessors do not define how to handle
this case and that the problem is left as an exercise to the implementor. As I
regard this as a flaw in the protocol, I would appreciate a statement in 4310bis
regarding such a state.

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA4JQr5J018140 for ; Wed, 4 Nov 2009 20:26:53 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA4JQrsf008042 for ietf-provreg-outgoing; Wed, 4 Nov 2009 20:26:53 +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 nA4JQrWe003312 for ; Wed, 4 Nov 2009 20:26:53 +0100 (MET)
Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id A25F418B; Wed, 4 Nov 2009 20:26:46 +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 1qUg54SiPJr2; Wed, 4 Nov 2009 20:26:41 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 2264918A; Wed, 4 Nov 2009 20:26:40 +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 nA4JQdeE017232; Wed, 4 Nov 2009 20:26:40 +0100 (MEZ)
Message-ID: <[email-masked]>
Date: Wed, 04 Nov 2009 20:26:40 +0100
From: Klaus Malorny
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.6pre) Gecko/20091104 Shredder/3.0pre
MIME-Version: 1.0
To: Ulrich Wisser
CC: [email-masked]
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

On 04/11/09 14:31, Ulrich Wisser wrote:
>>>> 3. Support for the combination of add and rem
>>> Yes, provided the text clearly states that only one outcome can
>>> occur. This can mean doing all adds first, or all removes first. Of
>>> course, all adds can occur in any order, as can all removes. Allowing
>>> policy to dictate how this works would be mean that registrars would
>>> have to support both.
>>
>> I don't think I understand your remark here. I thought the idea was
>> that we make this a sequence, such that the outcome is whatever that
>> sequence of operations would be. No?
>
> But the sequence in the schema does allow only one kind of sequence. It
> will always be add/rem or rem/add. The schema doesn't allow you to
> choose which one to put first. And therefor the order of execution will
> be fixed.
>
> But if we go for the new dsData/keydata changes for the rem command I
> can't see that we would need rem/add and add/rem. Either scheme allows
> all reasonable updates. As dsData identifies exactly on ds record and
> keydata exactly one key adding and removing the same ds record/key in
> one epp command could be considered unreasonable, couldn't it?
>
> /Ulrich

Hi all,

just an attempt to clarify:

The XML Schema *only* defines the order of the elements in the XML
file. It *does not* impose any implicit processing order. A protocol can define
any processing order it likes.

Also, there is one and/or element at most in a request. However,
within each of them, multiple elements may occur to represent multiple DS
records (or keys, if you will).

Personally, I really don't care about the order in the XML document, but I
prefer the perform the removals first and then the additions. Ulrich's way to
reject a request if a DS record appears both in and would be also
acceptable to me, but it makes the implementation a little bit more complex if
the in the section is retained -- in this case, the DS data has
to be checked against these elements as well.

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA4FLNwI000367 for ; Wed, 4 Nov 2009 16:21:23 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA4FLNFg015345 for ietf-provreg-outgoing; Wed, 4 Nov 2009 16:21:23 +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 nA4FLNqi027242 for ; Wed, 4 Nov 2009 16:21:23 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 83A152FE8CDC for ; Wed, 4 Nov 2009 15:21:21 +0000 (UTC)
Date: Wed, 4 Nov 2009 10:21:19 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To:
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Wed, Nov 04, 2009 at 09:43:23AM -0500, James Gould wrote:
> All,
>
> Before we continue to go around in circles, can I propose an option that
> addresses most of everyoneÂ¹s concerns, where the following would be met?
>
> 1. XML schema is backward compatible

What do you mean by this exactly? It seems that you are proposing
changing the schema in such a way that the schema is not actually
backward compatible, because you want to make it protocol-impossible
for someone to delete all DS data just by using the keyTag. I think
that requires that the schemas are formally incompatible. Doesn't it?

> 4. Support for a dsData and keyData primary interface. Only one primary
> interface should be supported by the server.

I think I don't know what "primary interface" means in the above. If
you mean that the I-D should say something like "A server MUST accept
either dsData or keyData, and SHOULD NOT accept both," it makes sense
to me.

> 5. Remove support for the wildcard delete of dsData in the rem by just using
> the keyTag with a clear statement (i.e. Server must return error if the
> keyTag matches multiple DS records) in the specification. From my
> perspective and I believe a couple others this is a key issue that must be
> addressed.

Nobody has yet responded to my contention that this is a policy
matter, and shouldn't be required by the protocol. You don't happen
to have a deployed system using 4310 yet, so it isn't a concern to
you, but it seems to me that there are people who do have such
deployed systems, and the above requirement effectively requires them
to have a flag day. Why does that need to be a protocol mandate, when
we can do it with registry policy?

> 6. Clarity in the specification on the use of the chg as a replace or a
> Â³change allÂ².

I think the I-D I circulated already contains such language.

> 7. Clarity around the corner case of a client attempting to add and remove
> the same dsData or keyData in a single command. This must result in an
> error from the server.

Why? In the mainline EPP specification, if you remove and add the
same name servers in a single command, it doesn't cause an error. (I
know this because misguided registrars used to do it all the time in
an effort to get the "primary" name server "listed first".) It's a
waste of bandwidth, but since EPP is idempotent it should have no
effect, right?

> Additionally an error must be returned if the client
> tries to remove dsData or keyData that does not exist or tries to add dsData
> or keyData that already exists.

These are already errors, I think, no?

A

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA4EhTBB001668 for ; Wed, 4 Nov 2009 15:43:29 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA4EhTYd011663 for ietf-provreg-outgoing; Wed, 4 Nov 2009 15:43:29 +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 nA4EhSjt011194 for ; Wed, 4 Nov 2009 15:43:29 +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 nA4ERRhu022566; Wed, 4 Nov 2009 09:27:27 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 09:44:00 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Wed, 4 Nov 2009 14:43:26 +0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Wed, 04 Nov 2009 09:43:23 -0500
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
From: James Gould
To: Andrew Sullivan , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] Anyone working on 4310-bis?
Thread-Index: AcpdWTjSZEnWcJBiSGeNdJmOt6nwHQAA+/lD
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
X-OriginalArrivalTime: 04 Nov 2009 14:44:00.0273 (UTC) FILETIME=[3EEFE010:01CA5D5D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id nA4EhTjt028933
Sender: [email-masked]
Precedence: bulk

All,

Before we continue to go around in circles, can I propose an option that
addresses most of everyone¹s concerns, where the following would be met?

1. XML schema is backward compatible
2. Support for add and rem in the same command
3. Support for passing all four dsData attributes on a rem
4. Support for a dsData and keyData primary interface. Only one primary
interface should be supported by the server.
5. Remove support for the wildcard delete of dsData in the rem by just using
the keyTag with a clear statement (i.e. Server must return error if the
keyTag matches multiple DS records) in the specification. From my
perspective and I believe a couple others this is a key issue that must be
addressed.
6. Clarity in the specification on the use of the chg as a replace or a
³change all².
7. Clarity around the corner case of a client attempting to add and remove
the same dsData or keyData in a single command. This must result in an
error from the server. Additionally an error must be returned if the client
tries to remove dsData or keyData that does not exist or tries to add dsData
or keyData that already exists.

Option 2 from my prior e-mail should satisfy all of these along with some
additional text clarity in the specification.

Option 2 - Combination of Klaus¹s and Ulrich¹s proposals, where the dsData
information is made optional to support the keyData interface:

--

JG

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

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

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

From: Andrew Sullivan
Date: Wed, 4 Nov 2009 08:52:53 -0500
To: EPP Provreg
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

On Wed, Nov 04, 2009 at 02:30:39PM +0100, Ulrich Wisser wrote:
>
> In that light I propose we drop backward compatibility.

This sounds like what we are proposing is a completely new extension.
Is that right?

A

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

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA4Dqver009658 for ; Wed, 4 Nov 2009 14:52:57 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA4Dqv41009529 for ietf-provreg-outgoing; Wed, 4 Nov 2009 14:52:57 +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 nA4DquBO018876 for ; Wed, 4 Nov 2009 14:52:56 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 5E7A52FE8CDC for ; Wed, 4 Nov 2009 13:52:55 +0000 (UTC)
Date: Wed, 4 Nov 2009 08:52:53 -0500
From: Andrew Sullivan
To: [email-masked]
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , [email-masked]
References: <[email-masked]> <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Wed, Nov 04, 2009 at 02:30:39PM +0100, Ulrich Wisser wrote:
>
> In that light I propose we drop backward compatibility.

This sounds like what we are proposing is a completely new extension.
Is that right?

A

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA4DVw1R021198 for ; Wed, 4 Nov 2009 14:31:58 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA4DVvH2004891 for ietf-provreg-outgoing; Wed, 4 Nov 2009 14:31:57 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from lvps87-230-32-221.dedicated.hosteurope.de (mail.publisher.de [87.230.32.221]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA4DVu0e011317 for ; Wed, 4 Nov 2009 14:31:56 +0100 (MET)
Received: (qmail 22273 invoked from network); 4 Nov 2009 13:31:56 +0000
Received: from gw.iis.se (HELO ulrich-wissers-macbook-pro.local) (212.247.14.38) by mail.publisher.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 4 Nov 2009 13:31:56 +0000
Message-ID: <[email-masked]>
Date: Wed, 04 Nov 2009 14:31:53 +0100
From: Ulrich Wisser
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: [email-masked]
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
References:
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

> So there are registries out there looking to support a keyData interface for
> DNSSEC, where the client would pass just the keyData on an add/rem/chg?
> Would the DS data be returned in the info response?

James, I've heard from several registries considering it. But I have no
input about this from registrars. From a registry standpoint dealing
with keys instead of ds records makes operations much simpler.

We would not return DS data. .SE would put two DS records for each key
in the zone file. So returning DS records would mean to return the key
twice. With the proposed change we would return the key data in the info
command.

/Ulrich

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA4DVh7k001815 for ; Wed, 4 Nov 2009 14:31:43 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA4DVhRI020981 for ietf-provreg-outgoing; Wed, 4 Nov 2009 14:31:43 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from lvps87-230-32-221.dedicated.hosteurope.de (mail.publisher.de [87.230.32.221]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA4DVgKT019602 for ; Wed, 4 Nov 2009 14:31:42 +0100 (MET)
Received: (qmail 22259 invoked from network); 4 Nov 2009 13:31:42 +0000
Received: from gw.iis.se (HELO ulrich-wissers-macbook-pro.local) (212.247.14.38) by mail.publisher.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 4 Nov 2009 13:31:42 +0000
Message-ID: <[email-masked]>
Date: Wed, 04 Nov 2009 14:31:39 +0100
From: Ulrich Wisser
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: [email-masked]
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
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

>>> 3. Support for the combination of add and rem
>> Yes, provided the text clearly states that only one outcome can occur.
>> This can mean doing all adds first, or all removes first. Of course, all
>> adds can occur in any order, as can all removes. Allowing policy to
>> dictate how this works would be mean that registrars would have to
>> support both.
>
> I don't think I understand your remark here. I thought the idea was
> that we make this a sequence, such that the outcome is whatever that
> sequence of operations would be. No?

But the sequence in the schema does allow only one kind of sequence. It
will always be add/rem or rem/add. The schema doesn't allow you to
choose which one to put first. And therefor the order of execution will
be fixed.

But if we go for the new dsData/keydata changes for the rem command I
can't see that we would need rem/add and add/rem. Either scheme allows
all reasonable updates. As dsData identifies exactly on ds record and
keydata exactly one key adding and removing the same ds record/key in
one epp command could be considered unreasonable, couldn't it?

/Ulrich

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA4DVOjc026294 for ; Wed, 4 Nov 2009 14:31:24 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA4DVO0j025364 for ietf-provreg-outgoing; Wed, 4 Nov 2009 14:31:24 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from lvps87-230-32-221.dedicated.hosteurope.de (mail.publisher.de [87.230.32.221]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA4DVNMr021372 for ; Wed, 4 Nov 2009 14:31:23 +0100 (MET)
Received: (qmail 22244 invoked from network); 4 Nov 2009 13:31:23 +0000
Received: from gw.iis.se (HELO ulrich-wissers-macbook-pro.local) (212.247.14.38) by mail.publisher.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 4 Nov 2009 13:31:23 +0000
Message-ID: <[email-masked]>
Date: Wed, 04 Nov 2009 14:30:39 +0100
From: Ulrich Wisser
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: [email-masked]
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
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

After going through our epp server code I believe we should go for the
*not* backward compatible changes. In my opinion supporting another
extension on the server side is if not trivial at least very easy.
Server operators are always free to support the old namespace as long as
necessary but anybody doing a new implementation would get it right from
the beginning.

Andrew, if we change the namespace version number servers can support
the old way without any changes to the clients and the new (proper) way
at the same time.

In that light I propose we drop backward compatibility.

/Ulrich

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA3MKoiD001694 for ; Tue, 3 Nov 2009 23:20:50 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA3MKoOo008011 for ietf-provreg-outgoing; Tue, 3 Nov 2009 23:20:50 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA3MKoqw010624 for ; Tue, 3 Nov 2009 23:20:50 +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 80EDD2FE8CDC for ; Tue, 3 Nov 2009 22:20:49 +0000 (UTC)
Date: Tue, 3 Nov 2009 17:20:47 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Tue, Nov 03, 2009 at 03:32:37PM -0600, Howard Eland wrote:
>
> From this perspective, the only reason to continue to support :chg would
> be because others are currently using it.
> Because of this, I support the deprecation of :chg for DS records.

The conclusion seems not to follow from the premise. We do not know
whether anyone is using chg. If we remove support, then we might
break someone who doesn't know to follow the list of a long-closed WG.
What benefit is there in removing support?

> I've read Andrew's argument about keeping only the keyTag as part of the
> rem, but I'm concerned about making the text and XML correct with
> supporting only a keyTag IFF it removes one DS record, ELSE returns an
> error that specifies the problem, and possibly suggests adding all other
> parameters.

Why do we need to do this? If registries want to make a policy that
they won't accept changes with only the keyTag, I think we ought to
make it possible to do that. I don't see any reason at all that the
protocol should require one behaviour or another, however. And again,
without allowing keyTag-only operation, we're forcing on anyone who
has already implemented 4310 a flag day cutover: on that day, all the
old clients need to stop. No?

>> 3. Support for the combination of add and rem
>
> Yes, provided the text clearly states that only one outcome can occur.
> This can mean doing all adds first, or all removes first. Of course, all
> adds can occur in any order, as can all removes. Allowing policy to
> dictate how this works would be mean that registrars would have to
> support both.

I don't think I understand your remark here. I thought the idea was
that we make this a sequence, such that the outcome is whatever that
sequence of operations would be. No?

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA3LWgZQ004378 for ; Tue, 3 Nov 2009 22:32:42 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA3LWgG2022875 for ietf-provreg-outgoing; Tue, 3 Nov 2009 22:32:42 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA3LWe9P028763 for ; Tue, 3 Nov 2009 22:32:41 +0100 (MET)
Message-Id: <[email-masked]>
From: Howard Eland
To: EPP Provreg
In-Reply-To:
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
Date: Tue, 3 Nov 2009 15:32:37 -0600
References:
X-Mailer: Apple Mail (2.936)
X-Authenticated: True
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id nA3LWf9P019876
Sender: [email-masked]
Precedence: bulk

Sorry, I did not answer this yesterday.

On Nov 2, 2009, at 9:46 AM, James Gould wrote:

> Howard,
>
> So if we “go to the well once” without backward compatibility
> support, the
> schema would do the following:
>
> 1. Remove support for the chg

So I did some sleuthing to try and figure out the logic of how and why
chg was implemented in the first place, and I _think_ I've got it. I
believe that chg was used when attributes should always have a value
of some sort. I went back through 4931, then back to 3731, looking
specifically at AuthInfo. While all of these say that a
can be used in :chg, I note that in the XML there's a comment about
adding the null value, which makes me think that at some point a null
was not allowed, thus requiring a chg command. I also note that in
5733, the chg requires at least one child element to update contacts.

I think an argument can be made that :chg is an atomic method for
replacing all DS records with new ones, without ever having a (albeit
temporary) state in the DNS where a DS doesn't exist. This however is
solving the wrong problem: while there's always a DS in the zone, what
we ultimately care about is client validation. The most extreme case
I can come up with is an emergency KSK rollover. Should this occur,
one can easily argue that removing the old DS records (rendering the
zone invalid for a neg TTL potentially) and immediately (even within
the same update) adding is as good as an replace (where, while the
replace is processing, a validator could query and receive the bad DS
record for a full TTL).

From this perspective, the only reason to continue to support :chg
would be because others are currently using it.
Because of this, I support the deprecation of :chg for DS records.

> 2. Remove support for rem with just keyTag

Not sure how this is different from (4), but I'm OK with this.

I've read Andrew's argument about keeping only the keyTag as part of
the rem, but I'm concerned about making the text and XML correct with
supporting only a keyTag IFF it removes one DS record, ELSE returns an
error that specifies the problem, and possibly suggests adding all
other parameters.

I do think we'll see quite a few registrants that send in the same
keyTag w/ different digest types. I am seeing a _lot_ of interest for
this, from both test registrants as well as registrars, and it'll be
more prevalent with the uptake of SHA-256.

> 3. Support for the combination of add and rem

Yes, provided the text clearly states that only one outcome can
occur. This can mean doing all adds first, or all removes first. Of
course, all adds can occur in any order, as can all removes. Allowing
policy to dictate how this works would be mean that registrars would
have to support both.

> 4. Specify all of the DS information (keyTag, alg, digestType, and
> digest)
> on an add and rem.

Yes - this needs to happen to ensure only a single DS is affected.

>
> As far as supporting a keyData interface and dsData interface to the
> clients
> , I believe that client-side software (SDK’s and utilities) should be
> available for the client to generate the DS instead of pushing it to
> the
> server-side. With the dsData interface, the client has maximum
> flexibility,
> the load is distributed to the client-side, and the registries can
> provide
> one consistent interface. It would be good to hear from the
> Registrars
> related to supporting two different models across the DNSSEC
> registries.

While registrar input is certainly important, I think it's really up
to the registries that are authoritative for the DS record. While I
may not use this out of the gate, it's certainly an interesting idea,
and it seems like something others said they would like to see.

-Howard

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA3HQeRN009632 for ; Tue, 3 Nov 2009 18:26:40 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA3HQeND029032 for ietf-provreg-outgoing; Tue, 3 Nov 2009 18:26:40 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA3HQd0B001081 for ; Tue, 3 Nov 2009 18:26:39 +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 E725E2FE8CDC for ; Tue, 3 Nov 2009 17:26:38 +0000 (UTC)
Date: Tue, 3 Nov 2009 12:26:37 -0500
From: Andrew Sullivan
To: [email-masked]
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , [email-masked]
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Mon, Nov 02, 2009 at 11:08:44AM +0100, Ulrich Wisser wrote:
> Why would the RFC have to define an order of execution? Can't that be
> left to registry policy decision? As long as the order is consistent of
> course.

It has to be the order in which the commands are sent, otherwise it's
possible for someone to send the command removing all DS records with
a given keyTag, and then to add a new one with the same keyTag
(thereby effecting the wholesale replacement of a given DS) and
actually have the server process it as add,remove. The upshot would
be, of course, that there would be no DS at that owner name, which is
not the client's intention.

A

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA3GNAdq012009 for ; Tue, 3 Nov 2009 17:23:10 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA3GNA8d020903 for ietf-provreg-outgoing; Tue, 3 Nov 2009 17:23:10 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA3GN99u003704 for ; Tue, 3 Nov 2009 17:23:09 +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 1783C2FE8CDC for ; Tue, 3 Nov 2009 16:23:09 +0000 (UTC)
Date: Tue, 3 Nov 2009 11:23:07 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To:
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Tue, Nov 03, 2009 at 11:03:20AM -0500, James Gould wrote:
> Andrew,
>
> I understand that it can be made up to registry policy, but I want to ensure
> that we donâ€™t make it more difficult for the clients to interface with
> servers applying different interface policies (support for chg, support for
> just keyTag, support for add and rem, and support for keyData interface)
> with potentially little extra value. Supporting add and rem in a single
> command pretty much deprecates chg and supporting rem with all DS attributes
> pretty much deprecates the use of just the keyTag.

The latter is certainly not true: by policy one could decide to allow
simple keyTag uses, since in just about every case the keyTag is
actually going to be enough. There is a problem when one is changing
algorithms, for instance, but that doesn't happen very often.

The key thing in preparing the protocol is not to make it as simple as
possible, but to make it as simple as possible without excluding any
reasonable operational model. Competent experts in the field can
legitimately disagree about what is a "reasonable operational model",
and I'm particularly keen not to change anything that just breaks
deployed and running code in the interests of simplicity.

> Support for both the dsData and keyData interfaces is a fundamental
> different interface similar to the difference between hostAttr and hostObj
> in the domain specification, so I donâ€™t support adding extra options to the
> specification that can lead to confusion if there is not a compelling reason
> to do so. For our registries the dsData interface is sufficient, so I would
> like to understand the real driver behind the keyData interface and whether
> this is being driven by Registrars.

I agree it's different, but there is a strong data-source argument
that the registry is the correct generator of the DS record, because
the DS is authoritative in the parent side. This is different from
the usual NS case, where the record is identical on both sides of the
zone cut.

A

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA3G3SgC012171 for ; Tue, 3 Nov 2009 17:03:28 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA3G3SIx029991 for ietf-provreg-outgoing; Tue, 3 Nov 2009 17:03:28 +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 nA3G3Qf6013534 for ; Tue, 3 Nov 2009 17:03:27 +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 nA3FlR23025639; Tue, 3 Nov 2009 10:47:27 -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, 3 Nov 2009 16:03:25 +0000
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Tue, 3 Nov 2009 16:03:24 +0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Tue, 03 Nov 2009 11:03:20 -0500
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
From: James Gould
To: Andrew Sullivan , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] Anyone working on 4310-bis?
Thread-Index: Acpcmk4g8wq+vs5eRLSFL5dRSqH9VgABNto4
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3340091002_11223713"
X-OriginalArrivalTime: 03 Nov 2009 16:03:25.0674 (UTC) FILETIME=[2CEC9CA0:01CA5C9F]
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_3340091002_11223713
Content-type: text/plain;
charset="EUC-KR"
Content-transfer-encoding: quoted-printable

Andrew,

I understand that it can be made up to registry policy, but I want to ensur=
e
that we don=A1=AFt make it more difficult for the clients to interface with
servers applying different interface policies (support for chg, support for
just keyTag, support for add and rem, and support for keyData interface)
with potentially little extra value. Supporting add and rem in a single
command pretty much deprecates chg and supporting rem with all DS attribute=
s
pretty much deprecates the use of just the keyTag. I don=A1=AFt have heartburn
to leaving the deprecated elements in the specification for backward
compatibility, but that would be the only reason they should be left in.
Support for both the dsData and keyData interfaces is a fundamental
different interface similar to the difference between hostAttr and hostObj
in the domain specification, so I don=A1=AFt support adding extra options to th=
e
specification that can lead to confusion if there is not a compelling reaso=
n
to do so. For our registries the dsData interface is sufficient, so I woul=
d
like to understand the real driver behind the keyData interface and whether
this is being driven by Registrars.

--=20

JG=20

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

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

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

From: Andrew Sullivan
Date: Tue, 3 Nov 2009 10:04:22 -0500
To: EPP Provreg
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

On Mon, Nov 02, 2009 at 11:46:00AM -0400, James Gould wrote:
> Howard,
>
> So if we =A9=F8go to the well once=A9=F7 without backward compatibility support, =
the
> schema would do the following:
>
> 1. Remove support for the chg
> 2. Remove support for rem with just keyTag

I see no reason whatever to make those changes in the protocol. That
is a conflation of policy and protocol. There might be good reasons
for server operators not to allow such combinations, and therefore I
think we should make it possible for a server operator to refuse such
operations. But we shouldn't remove them from the protocol.

> 3. Support for the combination of add and rem

This seems fine to me, and when I update the draft the next time I'll
make the change so that this is possible. Now that I understand how
sequence works, this is an obvious improvement.

> 4. Specify all of the DS information (keyTag, alg, digestType, and digest=
)
> on an add and rem.

I am willing to make this change. Obviously, using all of them is
redundant (if we start having hash collisions, there's going to be
bigger problems with DNSSEC than getting the DS record into the parent
via EPP), but the symmetry might make the coding easier, and it's not
that much more data. That said, I don't think we need to require this
(see above).

> As far as supporting a keyData interface and dsData interface to the clie=
nts
> , I believe that client-side software (SDK=A9=F6s and utilities) should be
> available for the client to generate the DS instead of pushing it to the
> server-side. With the dsData interface, the client has maximum flexibili=
ty,
> the load is distributed to the client-side, and the registries can provid=
e
> one consistent interface. It would be good to hear from the Registrars
> related to supporting two different models across tkeyhe DNSSEC registrie=
s.

Well, there's nothing wrong with adding the feature to the protocol as
such. The question is really whether anybody really wants this.

A

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

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

Re: [ietf-provreg] Anyone working on 4310-bis?

Andrew,

I understand that it can be made up to registry policy, but I want to ensur=
e that we don’t make it more difficult for the clients to interface wi=
th servers applying different interface policies (support for chg, support f=
or just keyTag, support for add and rem, and support for keyData interface) =
with potentially little extra value.  Supporting add and rem in a singl=
e command pretty much deprecates chg and supporting rem with all DS attribut=
es pretty much deprecates the use of just the keyTag.  I don’t ha=
ve heartburn to leaving the deprecated elements in the specification for bac=
kward compatibility, but that would be the only reason they should be left i=
n.  Support for both the dsData and keyData interfaces is a fundamental=
different interface similar to the difference between hostAttr and hostObj =
in the domain specification, so I don’t support adding extra options t=
o the specification that can lead to confusion if there is not a compelling =
reason to do so.  For our registries the dsData interface is sufficient=
, so I would like to understand the real driver behind the keyData interface=
and whether this is being driven by Registrars.

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

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

From: Andrew Sullivan <[email-masked]>

Date: Tue, 3 Nov 2009 10:04:22 -0500

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

Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

On Mon, Nov 02, 2009 at 11:46:00AM -0400, James Gould wrote:

> Howard,

> So if we ³go to the well once² without backward compatibilit=
y support, the

> schema would do the following:

> 1. Remove support for the chg

> 2. Remove support for rem with just keyTag

I see no reason whatever to make those changes in the protocol.  That<=
BR>
is a conflation of policy and protocol.  There might be good reasons
for server operators not to allow such combinations, and therefore I

think we should make it possible for a server operator to refuse such

operations.  But we shouldn't remove them from the protocol.

> 3. Support for the combination of add and rem

This seems fine to me, and when I update the draft the next time I'll

make the change so that this is possible.  Now that I understand how
sequence works, this is an obvious improvement.

> 4. Specify all of the DS information (keyTag, alg, digestType, and dig=
est)

> on an add and rem.

I am willing to make this change.  Obviously, using all of them is

redundant (if we start having hash collisions, there's going to be

bigger problems with DNSSEC than getting the DS record into the parent

via EPP), but the symmetry might make the coding easier, and it's not

that much more data.  That said, I don't think we need to require this=

(see above).

> As far as supporting a keyData interface and dsData interface to the c=
lients

> , I believe that client-side software (SDK¹s and utilities) shoul=
d be

> available for the client to generate the DS instead of pushing it to t=
he

> server-side.  With the dsData interface, the client has maximum f=
lexibility,

> the load is distributed to the client-side, and the registries can pro=
vide

> one consistent interface.  It would be good to hear from the Regi=
strars

> related to supporting two different models across tkeyhe DNSSEC regist=
ries.

Well, there's nothing wrong with adding the feature to the protocol as

such.  The question is really whether anybody really wants this.

A

--

Andrew Sullivan

[email-masked]

Shinkuro, Inc.

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

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

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

--B_3340091002_11223713--

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA3F4Pl8009536 for ; Tue, 3 Nov 2009 16:04:25 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA3F4P0Z001232 for ietf-provreg-outgoing; Tue, 3 Nov 2009 16:04:25 +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 nA3F4OUs027634 for ; Tue, 3 Nov 2009 16:04:25 +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 3FEF12FE8CDC for ; Tue, 3 Nov 2009 15:04:24 +0000 (UTC)
Date: Tue, 3 Nov 2009 10:04:22 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To:
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Mon, Nov 02, 2009 at 11:46:00AM -0400, James Gould wrote:
> Howard,
>
> So if we Â³go to the well onceÂ² without backward compatibility support, the
> schema would do the following:
>
> 1. Remove support for the chg
> 2. Remove support for rem with just keyTag

I see no reason whatever to make those changes in the protocol. That
is a conflation of policy and protocol. There might be good reasons
for server operators not to allow such combinations, and therefore I
think we should make it possible for a server operator to refuse such
operations. But we shouldn't remove them from the protocol.

> 3. Support for the combination of add and rem

This seems fine to me, and when I update the draft the next time I'll
make the change so that this is possible. Now that I understand how
sequence works, this is an obvious improvement.

> 4. Specify all of the DS information (keyTag, alg, digestType, and digest)
> on an add and rem.

I am willing to make this change. Obviously, using all of them is
redundant (if we start having hash collisions, there's going to be
bigger problems with DNSSEC than getting the DS record into the parent
via EPP), but the symmetry might make the coding easier, and it's not
that much more data. That said, I don't think we need to require this
(see above).

> As far as supporting a keyData interface and dsData interface to the clients
> , I believe that client-side software (SDKÂ¹s and utilities) should be
> available for the client to generate the DS instead of pushing it to the
> server-side. With the dsData interface, the client has maximum flexibility,
> the load is distributed to the client-side, and the registries can provide
> one consistent interface. It would be good to hear from the Registrars
> related to supporting two different models across the DNSSEC registries.

Well, there's nothing wrong with adding the feature to the protocol as
such. The question is really whether anybody really wants this.

A

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA3EsJgT017311 for ; Tue, 3 Nov 2009 15:54:19 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA3EsJRw004881 for ietf-provreg-outgoing; Tue, 3 Nov 2009 15:54:19 +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 nA3EsJUQ006923 for ; Tue, 3 Nov 2009 15:54:19 +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 4BAD62FE8CDC for ; Tue, 3 Nov 2009 14:54:18 +0000 (UTC)
Date: Tue, 3 Nov 2009 09:54:15 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Mon, Nov 02, 2009 at 09:45:03AM -0600, Howard Eland wrote:
> Another reason I like this option is that it gives the registry the
> ability to maintain some consistency in not only the DS record RDATA,
> but also the DS record TTL.

What is the value in having similar TTLs on the DS in the parent and
the DNSKEY in the child?

A

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA2GkBI5015289 for ; Mon, 2 Nov 2009 17:46:11 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA2GkBYi028337 for ietf-provreg-outgoing; Mon, 2 Nov 2009 17:46:11 +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 nA2GkAx2012641 for ; Mon, 2 Nov 2009 17:46:10 +0100 (MET)
Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id nA2GUCnc027317; Mon, 2 Nov 2009 11:30:12 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 11:46:08 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Mon, 2 Nov 2009 16:46:07 +0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Mon, 02 Nov 2009 11:46:00 -0400
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
From: James Gould
To: Howard Eland
CC: Ulrich Wisser , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] Anyone working on 4310-bis?
Thread-Index: Acpb03dTS7dtUHyYQeudtT3f6ymPiwACH2uJ
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
X-OriginalArrivalTime: 02 Nov 2009 16:46:08.0284 (UTC) FILETIME=[F9F21DC0:01CA5BDB]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id nA2GkBx2018917
Sender: [email-masked]
Precedence: bulk

Howard,

So if we ³go to the well once² without backward compatibility support, the
schema would do the following:

1. Remove support for the chg
2. Remove support for rem with just keyTag
3. Support for the combination of add and rem
4. Specify all of the DS information (keyTag, alg, digestType, and digest)
on an add and rem.

As far as supporting a keyData interface and dsData interface to the clients
, I believe that client-side software (SDK¹s and utilities) should be
available for the client to generate the DS instead of pushing it to the
server-side. With the dsData interface, the client has maximum flexibility,
the load is distributed to the client-side, and the registries can provide
one consistent interface. It would be good to hear from the Registrars
related to supporting two different models across the DNSSEC registries.

I updated the options for the schema updates below:

Option 1 - Proposal from Klaus that is backward compatible, supports
combined add and rem, and supports rem with the four ds attributes as
elements:

Option 2 - Combination of Klaus¹s and Ulrich¹s proposals, where the dsData
information is made optional to support the keyData interface:

Option 3 - Simplified interface that is not backward compatible but is
consistent with the rest of the EPP specs. Updates consist of just add and
rem of dsType data:

Option 4 - Simplified interface that is not backward compatible but is
consistent with the rest of the EPP specs but with support for a keyData
interface, which makes the daData optional.

I personally like the simplicity of option 3 if we don't have to worry about
backward compatibility. Option 4 would be needed if there is a set of
registries that have a compelling reason to support the keyData interface.
For our registries we should be able to deal with a non-backward compatible
change as long as we move quickly to an agreement. Our registries will most
likely support only the dsData interface. I propose that the version number
of the namespace and schema be changed to reflect the non-backward
compatible change. I would see this as a urn:ietf:params:xml:ns:secDNS-2.0
and secDNS-2.0.xsd.

--

JG

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

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

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

From: Howard Eland
Date: Mon, 2 Nov 2009 10:45:03 -0500
To: James Gould
Cc: Ulrich Wisser , EPP Provreg
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

All,

I am in favor of "going to the well once". I know there's been
reluctance to change some things because of backwards compatibility
and current implementation issues. However, I feel that if the
current document is broken enough to effect these changes, then we
should do everything we can to make it right. It is in exactly this
spirit that I conceded to requiring the entire dsData set on remove,
rather than just the digest.

On the two different DNS models: I am in favor of this, on one
condition: the text has got to make sure that we preserve the
authority of the data elements. By this I mean that while it's
permissible to send in the DNSKEY data, the registry itself MUST NOT
publish and / or sign this record in the DNS, if they are not
authoritative for it.

Interestingly enough, this is one reason why I like this option -
because the parent _is_ authoritative for the DS record. The same
comment should be made to the owner of the child zone as well (that
they are not authoritative for the DS record) - although I don't think
it can be as strong.

Another reason I like this option is that it gives the registry the
ability to maintain some consistency in not only the DS record RDATA,
but also the DS record TTL.

-Howard

On Nov 2, 2009, at 8:03 AM, James Gould wrote:

> Ulrich,
>
> So there are registries out there looking to support a keyData
> interface for
> DNSSEC, where the client would pass just the keyData on an add/rem/
> chg?
> Would the DS data be returned in the info response? Was providing a
> keyData
> interface for DNSSEC requested by the Registrars to ease in the
> implementation? I¹m not sure if having the registries supporting two
> different models like the hostAttr and hostObj models of the domain
> specification adds value or causes more complexity for the
> Registrars. I'm
> assuming that the Registry should support one model or the other and
> not
> both. If there is a compelling reason for supporting two different
> models,
> then I believe that a combination of Klaus¹s and Ulrich¹s schema
> changes
> makes sense, but I would like to hear from others related to the
> advantage
> of supporting two DNSSEC models (dsData and keyData).
>
> In summary, below is the XML schema snippet from Klaus:
>
>
>
>
>
>
>
>
>
> minOccurs="0"/>
>
> minOccurs="0"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Below is the XML schema snippet that includes both Klaus¹s and
> Ulrich¹s
> proposals:
>
>
>
>
>
>
>
>
> minOccurs="0"/>
>
> minOccurs="0"/>
>
>
>
>
>
>
>
>
>
>
>
>
> minOccurs="0"/>
>
> minOccurs="0"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> I agree that if we're not concerned about backward compatibility
> that the
> chg can be removed since supporting add and rem of multiple DS
> records is
> consistent with the other EPP specifications and removes the need
> for chg.
> I'm on the fence about this since I like backward compatibility but
> I also
> like removing confusion around the use of chg if add and rem can be
> used in
> its place.
>
> --
>
>
> JG
>
> -------------------------------------------------------
> James F. Gould
> Principal Software Engineer
> VeriSign Naming Services
> [email-masked]
> Direct: 703.948.3271
> Mobile: 703.628.7063
>
>
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>
> Notice to Recipient: This e-mail contains confidential, proprietary
> and/or
> Registry Sensitive information intended solely for the recipient
> and, thus
> may not be retransmitted, reproduced or disclosed without the prior
> written
> consent of VeriSign Naming and Directory Services. If you have
> received
> this e-mail message in error, please notify the sender immediately by
> telephone or reply e-mail and destroy the original message without
> making a
> copy. Thank you.
>
>
>
> From: Ulrich Wisser
> Date: Mon, 2 Nov 2009 05:08:03 -0500
> To: EPP Provreg
> Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
>
> Andrew Sullivan wrote:
>> On Wed, Oct 28, 2009 at 12:45:54PM +0100, Ulrich Wisser wrote:
>>
>>> The add command (as well as update) uses the secDNS:dsDataType.
>>> Which
>>> makes keytag, alg, digestType and digest mandatory. I know
>>> that .SE and
>>> other registries considered to become a "fat" registry and take in
>>> the
>>> public keys instead of the ds records. The DS records would be
>>> computed
>>> from the public keys according to registry policies.
>>> This case is not covered by 4310.
>>
>> While this is true, 4310 does provide an OPTIONAL
>> element. Registry policy could require this. Then you could get the
>> DS and the DNSKEY at the same time, and you could even check to be
>> sure the DS they're providing actually matches the DNSKEY they're
>> providing (and use that as a first-line test to make sure their plan
>> is sane. If they can't generate the right DS, they are as likely to
>> have other problems as not, and it could well be that you want to
>> stop
>> doing anything until it's sorted). No?
>
> I agree and this is not a big issue. I just thought that while we are
> changing the XML schema anyway, this change wouldn't be to troublesome
> either. I believe
>
>
>
>
>
>
>
>
> minOccurs="0"/>
>
> minOccurs="0"/>
>
>
>
> would do the trick and still be backward compatible, wouldn't it?
>
> /Ulrich
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> =-=-=-
> List run by majordomo software. For (Un-)subscription and similar
> details
> send "help" to [email-masked]
>
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> =-=-=-
> List run by majordomo software. For (Un-)subscription and similar
> details
> send "help" to [email-masked]
>

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA2Fj8j1028655 for ; Mon, 2 Nov 2009 16:45:08 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA2Fj8eh012308 for ietf-provreg-outgoing; Mon, 2 Nov 2009 16:45:08 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA2Fj7cg009988 for ; Mon, 2 Nov 2009 16:45:07 +0100 (MET)
Cc: Ulrich Wisser , EPP Provreg
Message-Id: <[email-masked]>
From: Howard Eland
To: James Gould
In-Reply-To:
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
Date: Mon, 2 Nov 2009 09:45:03 -0600
References:
X-Mailer: Apple Mail (2.936)
X-Authenticated: True
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id nA2Fj8cg017823
Sender: [email-masked]
Precedence: bulk

All,

I am in favor of "going to the well once". I know there's been
reluctance to change some things because of backwards compatibility
and current implementation issues. However, I feel that if the
current document is broken enough to effect these changes, then we
should do everything we can to make it right. It is in exactly this
spirit that I conceded to requiring the entire dsData set on remove,
rather than just the digest.

On the two different DNS models: I am in favor of this, on one
condition: the text has got to make sure that we preserve the
authority of the data elements. By this I mean that while it's
permissible to send in the DNSKEY data, the registry itself MUST NOT
publish and / or sign this record in the DNS, if they are not
authoritative for it.

Interestingly enough, this is one reason why I like this option -
because the parent _is_ authoritative for the DS record. The same
comment should be made to the owner of the child zone as well (that
they are not authoritative for the DS record) - although I don't think
it can be as strong.

Another reason I like this option is that it gives the registry the
ability to maintain some consistency in not only the DS record RDATA,
but also the DS record TTL.

-Howard

On Nov 2, 2009, at 8:03 AM, James Gould wrote:

> Ulrich,
>
> So there are registries out there looking to support a keyData
> interface for
> DNSSEC, where the client would pass just the keyData on an add/rem/
> chg?
> Would the DS data be returned in the info response? Was providing a
> keyData
> interface for DNSSEC requested by the Registrars to ease in the
> implementation? I’m not sure if having the registries supporting two
> different models like the hostAttr and hostObj models of the domain
> specification adds value or causes more complexity for the
> Registrars. I'm
> assuming that the Registry should support one model or the other and
> not
> both. If there is a compelling reason for supporting two different
> models,
> then I believe that a combination of Klaus’s and Ulrich’s schema
> changes
> makes sense, but I would like to hear from others related to the
> advantage
> of supporting two DNSSEC models (dsData and keyData).
>
> In summary, below is the XML schema snippet from Klaus:
>
>
>
>
>
>
>
>
>
> minOccurs="0"/>
>
> minOccurs="0"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Below is the XML schema snippet that includes both Klaus’s and
> Ulrich’s
> proposals:
>
>
>
>
>
>
>
>
> minOccurs="0"/>
>
> minOccurs="0"/>
>
>
>
>
>
>
>
>
>
>
>
>
> minOccurs="0"/>
>
> minOccurs="0"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> I agree that if we're not concerned about backward compatibility
> that the
> chg can be removed since supporting add and rem of multiple DS
> records is
> consistent with the other EPP specifications and removes the need
> for chg.
> I'm on the fence about this since I like backward compatibility but
> I also
> like removing confusion around the use of chg if add and rem can be
> used in
> its place.
>
> --
>
>
> JG
>
> -------------------------------------------------------
> James F. Gould
> Principal Software Engineer
> VeriSign Naming Services
> [email-masked]
> Direct: 703.948.3271
> Mobile: 703.628.7063
>
>
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>
> Notice to Recipient: This e-mail contains confidential, proprietary
> and/or
> Registry Sensitive information intended solely for the recipient
> and, thus
> may not be retransmitted, reproduced or disclosed without the prior
> written
> consent of VeriSign Naming and Directory Services. If you have
> received
> this e-mail message in error, please notify the sender immediately by
> telephone or reply e-mail and destroy the original message without
> making a
> copy. Thank you.
>
>
>
> From: Ulrich Wisser
> Date: Mon, 2 Nov 2009 05:08:03 -0500
> To: EPP Provreg
> Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
>
> Andrew Sullivan wrote:
>> On Wed, Oct 28, 2009 at 12:45:54PM +0100, Ulrich Wisser wrote:
>>
>>> The add command (as well as update) uses the secDNS:dsDataType.
>>> Which
>>> makes keytag, alg, digestType and digest mandatory. I know
>>> that .SE and
>>> other registries considered to become a "fat" registry and take in
>>> the
>>> public keys instead of the ds records. The DS records would be
>>> computed
>>> from the public keys according to registry policies.
>>> This case is not covered by 4310.
>>
>> While this is true, 4310 does provide an OPTIONAL
>> element. Registry policy could require this. Then you could get the
>> DS and the DNSKEY at the same time, and you could even check to be
>> sure the DS they're providing actually matches the DNSKEY they're
>> providing (and use that as a first-line test to make sure their plan
>> is sane. If they can't generate the right DS, they are as likely to
>> have other problems as not, and it could well be that you want to
>> stop
>> doing anything until it's sorted). No?
>
> I agree and this is not a big issue. I just thought that while we are
> changing the XML schema anyway, this change wouldn't be to troublesome
> either. I believe
>
>
>
>
>
>
>
>
> minOccurs="0"/>
>
> minOccurs="0"/>
>
>
>
> would do the trick and still be backward compatible, wouldn't it?
>
> /Ulrich
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> =-=-=-
> List run by majordomo software. For (Un-)subscription and similar
> details
> send "help" to [email-masked]
>
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> =-=-=-
> List run by majordomo software. For (Un-)subscription and similar
> details
> send "help" to [email-masked]
>

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA2F3rpa025757 for ; Mon, 2 Nov 2009 16:03:53 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA2F3rxY004589 for ietf-provreg-outgoing; Mon, 2 Nov 2009 16:03:53 +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 nA2F3q0k024000 for ; Mon, 2 Nov 2009 16:03:53 +0100 (MET)
Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id nA2F1Vex029702; Mon, 2 Nov 2009 10:01:31 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 10:03:51 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Mon, 2 Nov 2009 15:03:50 +0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Mon, 02 Nov 2009 10:03:45 -0400
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
From: James Gould
To: Ulrich Wisser , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] Anyone working on 4310-bis?
Thread-Index: AcpbpwreYbqmwbuxTyq5fx+4a65HiAAJqFnQ
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
X-OriginalArrivalTime: 02 Nov 2009 15:03:51.0135 (UTC) FILETIME=[AFEB7EF0:01CA5BCD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id nA2F3r0k003087
Sender: [email-masked]
Precedence: bulk

Ulrich,

So there are registries out there looking to support a keyData interface for
DNSSEC, where the client would pass just the keyData on an add/rem/chg?
Would the DS data be returned in the info response? Was providing a keyData
interface for DNSSEC requested by the Registrars to ease in the
implementation? I¹m not sure if having the registries supporting two
different models like the hostAttr and hostObj models of the domain
specification adds value or causes more complexity for the Registrars. I'm
assuming that the Registry should support one model or the other and not
both. If there is a compelling reason for supporting two different models,
then I believe that a combination of Klaus¹s and Ulrich¹s schema changes
makes sense, but I would like to hear from others related to the advantage
of supporting two DNSSEC models (dsData and keyData).

In summary, below is the XML schema snippet from Klaus:

Below is the XML schema snippet that includes both Klaus¹s and Ulrich¹s
proposals:

I agree that if we're not concerned about backward compatibility that the
chg can be removed since supporting add and rem of multiple DS records is
consistent with the other EPP specifications and removes the need for chg.
I'm on the fence about this since I like backward compatibility but I also
like removing confusion around the use of chg if add and rem can be used in
its place.

--

JG

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

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

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

From: Ulrich Wisser
Date: Mon, 2 Nov 2009 05:08:03 -0500
To: EPP Provreg
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

Andrew Sullivan wrote:
> On Wed, Oct 28, 2009 at 12:45:54PM +0100, Ulrich Wisser wrote:
>
>> The add command (as well as update) uses the secDNS:dsDataType. Which
>> makes keytag, alg, digestType and digest mandatory. I know that .SE and
>> other registries considered to become a "fat" registry and take in the
>> public keys instead of the ds records. The DS records would be computed
>> from the public keys according to registry policies.
>> This case is not covered by 4310.
>
> While this is true, 4310 does provide an OPTIONAL
> element. Registry policy could require this. Then you could get the
> DS and the DNSKEY at the same time, and you could even check to be
> sure the DS they're providing actually matches the DNSKEY they're
> providing (and use that as a first-line test to make sure their plan
> is sane. If they can't generate the right DS, they are as likely to
> have other problems as not, and it could well be that you want to stop
> doing anything until it's sorted). No?

I agree and this is not a big issue. I just thought that while we are
changing the XML schema anyway, this change wouldn't be to troublesome
either. I believe

would do the trick and still be backward compatible, wouldn't it?

/Ulrich

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

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA2A8mUT028011 for ; Mon, 2 Nov 2009 11:08:48 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA2A8miI024483 for ietf-provreg-outgoing; Mon, 2 Nov 2009 11:08:48 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from lvps87-230-32-221.dedicated.hosteurope.de (mail.publisher.de [87.230.32.221]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA2A8ljx017361 for ; Mon, 2 Nov 2009 11:08:47 +0100 (MET)
Received: (qmail 16209 invoked from network); 2 Nov 2009 10:08:47 +0000
Received: from gw.iis.se (HELO ulrich-wissers-macbook-pro.local) (212.247.14.38) by mail.publisher.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 Nov 2009 10:08:47 +0000
Message-ID: <[email-masked]>
Date: Mon, 02 Nov 2009 11:08:44 +0100
From: Ulrich Wisser
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: [email-masked]
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

Why would the RFC have to define an order of execution? Can't that be
left to registry policy decision? As long as the order is consistent of
course.
At .SE we impose limits on several data elements (contacts per domain,
ip numbers per host). Therefor we execute rem first.

I vote for the dsDataType. It makes rem fully compatible to add. And
lessens the burden for implementors on both server and client sides.

If we drop backward compatibility we should drop chg as it doesn't match
the overall EPP interpretation of chg.

/Ulrich

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA2A8A8w003783 for ; Mon, 2 Nov 2009 11:08:10 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nA2A8Ann015140 for ietf-provreg-outgoing; Mon, 2 Nov 2009 11:08:10 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from lvps87-230-32-221.dedicated.hosteurope.de (mail.publisher.de [87.230.32.221]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nA2A89YQ023599 for ; Mon, 2 Nov 2009 11:08:09 +0100 (MET)
Received: (qmail 16180 invoked from network); 2 Nov 2009 10:08:09 +0000
Received: from gw.iis.se (HELO ulrich-wissers-macbook-pro.local) (212.247.14.38) by mail.publisher.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 Nov 2009 10:08:09 +0000
Message-ID: <[email-masked]>
Date: Mon, 02 Nov 2009 11:08:03 +0100
From: Ulrich Wisser
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: [email-masked]
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

Andrew Sullivan wrote:
> On Wed, Oct 28, 2009 at 12:45:54PM +0100, Ulrich Wisser wrote:
>
>> The add command (as well as update) uses the secDNS:dsDataType. Which
>> makes keytag, alg, digestType and digest mandatory. I know that .SE and
>> other registries considered to become a "fat" registry and take in the
>> public keys instead of the ds records. The DS records would be computed
>> from the public keys according to registry policies.
>> This case is not covered by 4310.
>
> While this is true, 4310 does provide an OPTIONAL
> element. Registry policy could require this. Then you could get the
> DS and the DNSKEY at the same time, and you could even check to be
> sure the DS they're providing actually matches the DNSKEY they're
> providing (and use that as a first-line test to make sure their plan
> is sane. If they can't generate the right DS, they are as likely to
> have other problems as not, and it could well be that you want to stop
> doing anything until it's sorted). No?

I agree and this is not a big issue. I just thought that while we are
changing the XML schema anyway, this change wouldn't be to troublesome
either. I believe

would do the trick and still be backward compatible, wouldn't it?

/Ulrich

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