Subject: Hi provreg-archive, prepare for 80% Sale. expansion to United

From: "DiscountViagra shop" <[email-masked]>
Date: Tue, 28 Sep 2010 15:00:09 -0500

28 Sep 2010

If you are unable to display this newsletter, please
click here to view it online.

You are currently registered to receive newsletter at [[email-masked]]

Online Support Team |

Unsubscribe |

Subscribe |
Privacy Policy

Subscribe/Renew to e-Magazine |
Editorial Feedback

©2009

non thickness Media. 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 o8E9bPvN026302 for ; Tue, 14 Sep 2010 11:37:25 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o8E9bPGc009643 for ietf-provreg-outgoing; Tue, 14 Sep 2010 11:37:25 +0200 (MEST)
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 o8E9bOwO025101 for ; Tue, 14 Sep 2010 11:37:25 +0200 (MEST)
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 053231ECB408 for ; Tue, 14 Sep 2010 09:37:22 +0000 (UTC)
Date: Tue, 14 Sep 2010 05:37:21 -0400
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] secDNS-1.1: use of only one form of interface
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References: <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Tue, Sep 14, 2010 at 10:16:44AM +1000, Chris Wright wrote:
>
> Unfortunately your generalised case doesn't hold here. Consider TLDs
> that are sub-divided into 2LDs (in this case as .au is). The
> 'policy' for gov.au names is set by the government and very
> different to the 'policy' for the commercial namespace com.au which
> is set by an industry body. In fact I would argue that the 'general'
> case of one registry mapping to only one 'zone of registration' is
> actually the minority (you guys have com and net in the same
> Registry don't you?), and with the pending release of new gTLDs and
> the industry trend towards separation of 'registry service
> providers' from 'registries' having multiple zones of registration
> in one registry is only going to increasingly become the norm.

It is somewhat unfortunate that the word "registry" has received some
new meaning over time. We need to be careful here.

One meaning of "registry" (and, I think, its historical meaning, but I
don't think we need to determine that) is quite literal: "the
facility whereby registration in a zone happens". The important
detail to note is that this meaning intimately ties the registry to
the zone over which it has administrative authority.

Another meaning, and one that seems to be gaining primacy, is the
collection of software and policies that control registration in one
or more zones.

These are subtly different. I believe, however, that RFCs generally
rely on the first meaning. I suspect this is why the RFCs in question
actually avoid the term "registry" in favour of "repository". There
is no question that more than one repository can live inside a single
software system, and that therefore the policies governing each
repository could be different. That said, the text as it stands
governs the _server_, rather than the repository, which is perhaps
somewhat more problematic.

> doing an 'info' command and checking the results ;) ) and most
> Registries wrap all this 'complexity' up in toolkits anyway (none of
> our Registrars implemented EPP themselves, they all just use our
> toolkits).

Just as an aside, that is a poor argument in favour of the principle
that more complexity in the protocol is ok. On the contrary, if the
number of actual implementations is small, you want a simpler protocol
with fewer options. That's the way to ensure that poorly-tested
assumptions about the interaction of different options don't end up
biting someone later when they try to implement to the specification.
Remember, RFCs are about interoperability as much as anything else.

> For now we will just need to have a non-conforming implementation

Surely not. You can just declare a transition period without a sunset
date. Poof! you're conformant.

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 o8E6GCX0020628 for ; Tue, 14 Sep 2010 08:16:12 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o8E6GC5X029124 for ietf-provreg-outgoing; Tue, 14 Sep 2010 08:16:12 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from flame.co.za (sharon.co.za [160.124.170.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o8E6GBoK006046 for ; Tue, 14 Sep 2010 08:16:11 +0200 (MEST)
Received: from [192.168.0.98] (unknown [41.31.211.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by flame.co.za (Postfix) with ESMTP id DBDBA802AD; Tue, 14 Sep 2010 08:16:09 +0200 (SAST)
Subject: Re: [ietf-provreg] secDNS-1.1: use of only one form of interface
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Theo Kramer
In-Reply-To: <[email-masked]>
Date: Tue, 14 Sep 2010 08:16:08 +0200
Message-Id:
References: <[email-masked]> <[email-masked]> <[email-masked]>
To: EPP Provreg
X-Mailer: Apple Mail (2.1081)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o8E6GBoK007510
Sender: [email-masked]
Precedence: bulk

On 14 Sep 2010, at 06:53AM, Michael Young wrote:

> I'll keep my comments simple, Chris has a very valid point, there are other
> examples of what he's referring to, .ZA comes to mind for instance.

Oops - hit the wrong button first time around.

However, we will probably have each .za 2LD as a separate registry implementation albeit within a shared centralized infrastructure. This allowing clear separation of policy.

--
Regards
Theo

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 o8E692Os025282 for ; Tue, 14 Sep 2010 08:09:02 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o8E692MJ022667 for ietf-provreg-outgoing; Tue, 14 Sep 2010 08:09:02 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from flame.co.za (websvn.rascal.co.za [160.124.170.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o8E690Hn022779 for ; Tue, 14 Sep 2010 08:09:01 +0200 (MEST)
Received: from [192.168.0.98] (unknown [41.31.211.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by flame.co.za (Postfix) with ESMTP id BA0EE802AD; Tue, 14 Sep 2010 08:08:50 +0200 (SAST)
Subject: Re: [ietf-provreg] secDNS-1.1: use of only one form of interface
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Theo Kramer
In-Reply-To: <[email-masked]>
Date: Tue, 14 Sep 2010 08:08:50 +0200
Cc: "'Chris Wright'" , "'James Gould'" , "'James Mitchell'" , "'EPP Provreg'"
Message-Id: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
To: Michael Young
X-Mailer: Apple Mail (2.1081)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o8E691Hn014242
Sender: [email-masked]
Precedence: bulk

On 14 Sep 2010, at 06:53AM, Michael Young wrote:

> I'll keep my comments simple, Chris has a very valid point, there are other
> examples of what he's referring to, .ZA comes to mind for instance.
>
> Michael Young
>
> -----Original Message-----
> From: Chris Wright [mailto:[email-masked]]
> Sent: September-13-10 8:17 PM
> To: James Gould; James Mitchell; EPP Provreg
> Subject: RE: [ietf-provreg] secDNS-1.1: use of only one form of interface
>
> James, thanks for taking the time to respond,
>
> Unfortunately your generalised case doesn't hold here. Consider TLDs that
> are sub-divided into 2LDs (in this case as .au is). The 'policy' for gov.au
> names is set by the government and very different to the 'policy' for the
> commercial namespace com.au which is set by an industry body. In fact I
> would argue that the 'general' case of one registry mapping to only one
> 'zone of registration' is actually the minority (you guys have com and net
> in the same Registry don't you?), and with the pending release of new gTLDs
> and the industry trend towards separation of 'registry service providers'
> from 'registries' having multiple zones of registration in one registry is
> only going to increasingly become the norm.
>
> Putting that aside, you site domain transfer as the reason for enforcing
> 'consistency', if the rule where that a consistent method should be used for
> all domains residing in one 'zone' such consistency is still maintained, as
> the expected behaviour is still predictable by clients based on the zone of
> the domain (which would determine the policy that applies). We have much
> cross-zone inconsistency like this in Registries already that the protocol
> doesn't dictate, I mean, control ( :P ) (e.g. In some zones, technical
> contacts are mandatory and in others they are not) and Registrars cope
> perfectly fine with this 'complexity'. Isn't this the reason for the 2306
> and 2308 error codes?
>
> Even then, programmatically determining which method is in use by a domain
> is not that difficult anyway (no more difficult than say doing an 'info'
> command and checking the results ;) ) and most Registries wrap all this
> 'complexity' up in toolkits anyway (none of our Registrars implemented EPP
> themselves, they all just use our toolkits).
>
> As for the host attributes vs. host objects decision, unfortunately we
> weren't paying as much attention to this group back then as we should have
> been, as a similar rationale could be applied.
>
> For now we will just need to have a non-conforming implementation, as I'm
> hardly going to run separate Registries just for this tiny DS/key data
> difference. We were just concerned that there was some more serious
> rationale that we hadn't thought of, luckily not.
>
> Thanks
>
> Chris Wright
> Chief Technology Officer
> AusRegistry Pty Ltd
>
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of James Gould
> Sent: Monday, 13 September 2010 11:39 PM
> To: James Mitchell; EPP Provreg
> Subject: Re: [ietf-provreg] secDNS-1.1: use of only one form of interface
>
> James,
>
>> We have one server (process) that provides an EPP interface for more
>> than one zone, each zone potentially having a different policy, i.e. one
>> policy may mandate Key Data whereas another policy may mandate DS Data.
>> Furthermore, I do not understand why one zone cannot have a policy that
>> gives registrants the choice of DS Data or Key Data for a domain. What
>> is the rationale for this requirement?
>
> I don't understand what you mean by "each zone potentially having a
> different policy". Generally the Registry is providing an EPP interface for
> the management of a TLD (zone) with a single server-side policy. The
> rationale for requiring one form of interface for a server was the
> following:
> 1. Be consistent with the other EPP specifications. RFC 5731 supports two
> forms of interfaces for name servers (hostObj and hostAttr) where "A server
> operator MUST use one name server specification form consistently".
> 2. Provides for a simpler and cleaner interface if the server instance only
> supports a single interface for the same object types (DS in RFC 5910).
> With the DS Data Interface the client is responsible for managing the DS
> and with the Key Data Interface the server is responsible for managing the
> DS based on the Key Data. Mixing both interfaces will make it more complex
> for clients, since all clients would have to support both interfaces and
> would need to determine the interface to use on domain transfers.
>
>
>
> --
>
>
> 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 Mitchell
> Date: Sat, 11 Sep 2010 03:11:29 -0400
> To: EPP Provreg
> Subject: [ietf-provreg] secDNS-1.1: use of only one form of interface
>
> Hello,
>
> I am seeking clarification on the following sentence from RFC 5910.
>
> The server MUST support the
> use of only one form of interface across all ,
> , and elements, except during a
> transition period, during which the server MAY support both.
>
> We have one server (process) that provides an EPP interface for more
> than one zone, each zone potentially having a different policy, i.e. one
> policy may mandate Key Data whereas another policy may mandate DS Data.
> Furthermore, I do not understand why one zone cannot have a policy that
> gives registrants the choice of DS Data or Key Data for a domain. What
> is the rationale for this requirement?
>
> Regards,
>
> James Mitchell
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 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]

--
Regards
Theo

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 o8E4rvNv015310 for ; Tue, 14 Sep 2010 06:53:57 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o8E4rvD7002752 for ietf-provreg-outgoing; Tue, 14 Sep 2010 06:53:57 +0200 (MEST)
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 o8E4rtIt019258 for ; Tue, 14 Sep 2010 06:53:56 +0200 (MEST)
From: "Michael Young"
To: "'Chris Wright'" , "'James Gould'" , "'James Mitchell'" , "'EPP Provreg'"
References: <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Subject: RE: [ietf-provreg] secDNS-1.1: use of only one form of interface
Date: Tue, 14 Sep 2010 00:53:52 -0400
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: ActRgI42EPKIvN07TlG9DEeDFY09jQByHkRjABVhPKAACnnMQA==
Content-Language: en-ca
X-Authenticated: True
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o8E4ruIt027711
Sender: [email-masked]
Precedence: bulk

I'll keep my comments simple, Chris has a very valid point, there are other
examples of what he's referring to, .ZA comes to mind for instance.

Michael Young

-----Original Message-----
From: Chris Wright [mailto:[email-masked]]
Sent: September-13-10 8:17 PM
To: James Gould; James Mitchell; EPP Provreg
Subject: RE: [ietf-provreg] secDNS-1.1: use of only one form of interface

James, thanks for taking the time to respond,

Unfortunately your generalised case doesn't hold here. Consider TLDs that
are sub-divided into 2LDs (in this case as .au is). The 'policy' for gov.au
names is set by the government and very different to the 'policy' for the
commercial namespace com.au which is set by an industry body. In fact I
would argue that the 'general' case of one registry mapping to only one
'zone of registration' is actually the minority (you guys have com and net
in the same Registry don't you?), and with the pending release of new gTLDs
and the industry trend towards separation of 'registry service providers'
from 'registries' having multiple zones of registration in one registry is
only going to increasingly become the norm.

Putting that aside, you site domain transfer as the reason for enforcing
'consistency', if the rule where that a consistent method should be used for
all domains residing in one 'zone' such consistency is still maintained, as
the expected behaviour is still predictable by clients based on the zone of
the domain (which would determine the policy that applies). We have much
cross-zone inconsistency like this in Registries already that the protocol
doesn't dictate, I mean, control ( :P ) (e.g. In some zones, technical
contacts are mandatory and in others they are not) and Registrars cope
perfectly fine with this 'complexity'. Isn't this the reason for the 2306
and 2308 error codes?

Even then, programmatically determining which method is in use by a domain
is not that difficult anyway (no more difficult than say doing an 'info'
command and checking the results ;) ) and most Registries wrap all this
'complexity' up in toolkits anyway (none of our Registrars implemented EPP
themselves, they all just use our toolkits).

As for the host attributes vs. host objects decision, unfortunately we
weren't paying as much attention to this group back then as we should have
been, as a similar rationale could be applied.

For now we will just need to have a non-conforming implementation, as I'm
hardly going to run separate Registries just for this tiny DS/key data
difference. We were just concerned that there was some more serious
rationale that we hadn't thought of, luckily not.

Thanks

Chris Wright
Chief Technology Officer
AusRegistry Pty Ltd

From: [email-masked] [mailto:[email-masked]] On
Behalf Of James Gould
Sent: Monday, 13 September 2010 11:39 PM
To: James Mitchell; EPP Provreg
Subject: Re: [ietf-provreg] secDNS-1.1: use of only one form of interface

James,

> We have one server (process) that provides an EPP interface for more
> than one zone, each zone potentially having a different policy, i.e. one
> policy may mandate Key Data whereas another policy may mandate DS Data.
> Furthermore, I do not understand why one zone cannot have a policy that
> gives registrants the choice of DS Data or Key Data for a domain. What
> is the rationale for this requirement?

I don't understand what you mean by "each zone potentially having a
different policy".  Generally the Registry is providing an EPP interface for
the management of a TLD (zone) with a single server-side policy.  The
rationale for requiring one form of interface for a server was the
following:
1. Be consistent with the other EPP specifications.  RFC 5731 supports two
forms of interfaces for name servers (hostObj and hostAttr) where "A server
operator MUST use one name server specification form consistently".
2. Provides for a simpler and cleaner interface if the server instance only
supports a single interface for the same object types (DS in RFC 5910).
With the DS Data Interface the client is responsible for managing the DS
and with the Key Data Interface the server is responsible for managing the
DS based on the Key Data.  Mixing both interfaces will make it more complex
for clients, since all clients would have to support both interfaces and
would need to determine the interface to use on domain transfers.

--

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 Mitchell
Date: Sat, 11 Sep 2010 03:11:29 -0400
To: EPP Provreg
Subject: [ietf-provreg] secDNS-1.1: use of only one form of interface

Hello,

I am seeking clarification on the following sentence from RFC 5910.

The server MUST support the
use of only one form of interface across all ,
, and elements, except during a
transition period, during which the server MAY support both.

We have one server (process) that provides an EPP interface for more
than one zone, each zone potentially having a different policy, i.e. one
policy may mandate Key Data whereas another policy may mandate DS Data.
Furthermore, I do not understand why one zone cannot have a policy that
gives registrants the choice of DS Data or Key Data for a domain. What
is the rationale for this requirement?

Regards,

James Mitchell

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 o8E0ElJ8012724 for ; Tue, 14 Sep 2010 02:14:47 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o8E0El11014225 for ietf-provreg-outgoing; Tue, 14 Sep 2010 02:14:47 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mx10-1.ausregistry.net.au (mx10-1.ausregistry.net.au [202.65.12.90]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o8E0EiBY016578 for ; Tue, 14 Sep 2010 02:14:46 +0200 (MEST)
Received: from off-win2003-01.ausregistrygroup.local (off-win2003-01.stkildard.vic.ausregistry.com.au [10.30.1.3]) by mx10-1.ausregistry.net.au (8.13.8/8.13.8) with ESMTP id o8E0EYpi023266; Tue, 14 Sep 2010 10:14:35 +1000
Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Tue, 14 Sep 2010 10:14:34 +1000
From: Chris Wright
To: James Gould , James Mitchell , EPP Provreg
Date: Tue, 14 Sep 2010 10:16:44 +1000
Subject: RE: [ietf-provreg] secDNS-1.1: use of only one form of interface
Thread-Topic: [ietf-provreg] secDNS-1.1: use of only one form of interface
Thread-Index: ActRgI42EPKIvN07TlG9DEeDFY09jQByHkRjABVhPKA=
Message-ID: <[email-masked]>
References: <[email-masked]>
In-Reply-To:
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
X-Spam-Status: No, score=-104.4 required=5.0 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mx10-1.ausregistry.net.au
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o8E0ElBY002341
Sender: [email-masked]
Precedence: bulk

James, thanks for taking the time to respond,

Unfortunately your generalised case doesn't hold here. Consider TLDs that are sub-divided into 2LDs (in this case as .au is). The 'policy' for gov.au names is set by the government and very different to the 'policy' for the commercial namespace com.au which is set by an industry body. In fact I would argue that the 'general' case of one registry mapping to only one 'zone of registration' is actually the minority (you guys have com and net in the same Registry don't you?), and with the pending release of new gTLDs and the industry trend towards separation of 'registry service providers' from 'registries' having multiple zones of registration in one registry is only going to increasingly become the norm.

Putting that aside, you site domain transfer as the reason for enforcing 'consistency', if the rule where that a consistent method should be used for all domains residing in one 'zone' such consistency is still maintained, as the expected behaviour is still predictable by clients based on the zone of the domain (which would determine the policy that applies). We have much cross-zone inconsistency like this in Registries already that the protocol doesn't dictate, I mean, control ( :P ) (e.g. In some zones, technical contacts are mandatory and in others they are not) and Registrars cope perfectly fine with this 'complexity'. Isn't this the reason for the 2306 and 2308 error codes?

Even then, programmatically determining which method is in use by a domain is not that difficult anyway (no more difficult than say doing an 'info' command and checking the results ;) ) and most Registries wrap all this 'complexity' up in toolkits anyway (none of our Registrars implemented EPP themselves, they all just use our toolkits).

As for the host attributes vs. host objects decision, unfortunately we weren't paying as much attention to this group back then as we should have been, as a similar rationale could be applied.

For now we will just need to have a non-conforming implementation, as I'm hardly going to run separate Registries just for this tiny DS/key data difference. We were just concerned that there was some more serious rationale that we hadn't thought of, luckily not.

Thanks

Chris Wright
Chief Technology Officer
AusRegistry Pty Ltd

From: [email-masked] [mailto:[email-masked]] On Behalf Of James Gould
Sent: Monday, 13 September 2010 11:39 PM
To: James Mitchell; EPP Provreg
Subject: Re: [ietf-provreg] secDNS-1.1: use of only one form of interface

James,

> We have one server (process) that provides an EPP interface for more
> than one zone, each zone potentially having a different policy, i.e. one
> policy may mandate Key Data whereas another policy may mandate DS Data.
> Furthermore, I do not understand why one zone cannot have a policy that
> gives registrants the choice of DS Data or Key Data for a domain. What
> is the rationale for this requirement?

I don't understand what you mean by "each zone potentially having a different policy".  Generally the Registry is providing an EPP interface for the management of a TLD (zone) with a single server-side policy.  The rationale for requiring one form of interface for a server was the following:
1. Be consistent with the other EPP specifications.  RFC 5731 supports two forms of interfaces for name servers (hostObj and hostAttr) where "A server operator MUST use one name server specification form consistently".
2. Provides for a simpler and cleaner interface if the server instance only supports a single interface for the same object types (DS in RFC 5910).   With the DS Data Interface the client is responsible for managing the DS and with the Key Data Interface the server is responsible for managing the DS based on the Key Data.  Mixing both interfaces will make it more complex for clients, since all clients would have to support both interfaces and would need to determine the interface to use on domain transfers.

--

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 Mitchell
Date: Sat, 11 Sep 2010 03:11:29 -0400
To: EPP Provreg
Subject: [ietf-provreg] secDNS-1.1: use of only one form of interface

Hello,

I am seeking clarification on the following sentence from RFC 5910.

The server MUST support the
use of only one form of interface across all ,
, and elements, except during a
transition period, during which the server MAY support both.

We have one server (process) that provides an EPP interface for more
than one zone, each zone potentially having a different policy, i.e. one
policy may mandate Key Data whereas another policy may mandate DS Data.
Furthermore, I do not understand why one zone cannot have a policy that
gives registrants the choice of DS Data or Key Data for a domain. What
is the rationale for this requirement?

Regards,

James Mitchell

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 o8DDdTqH026101 for ; Mon, 13 Sep 2010 15:39:29 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o8DDdTMC019752 for ietf-provreg-outgoing; Mon, 13 Sep 2010 15:39:29 +0200 (MEST)
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 o8DDdRqo011239 for ; Mon, 13 Sep 2010 15:39:28 +0200 (MEST)
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 o8DDRIUd004587; Mon, 13 Sep 2010 09:27:18 -0400
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Sep 2010 09:39:12 -0400
Received: from 10.131.30.174 ([10.131.30.174]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Mon, 13 Sep 2010 13:39:12 +0000
User-Agent: Microsoft-Entourage/12.26.0.100708
Date: Mon, 13 Sep 2010 09:39:03 -0400
Subject: Re: [ietf-provreg] secDNS-1.1: use of only one form of interface
From: James Gould
To: James Mitchell , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] secDNS-1.1: use of only one form of interface
Thread-Index: ActRgI42EPKIvN07TlG9DEeDFY09jQByHkRj
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3367215546_9873507"
X-OriginalArrivalTime: 13 Sep 2010 13:39:12.0860 (UTC) FILETIME=[0D2779C0:01CB5349]
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_3367215546_9873507
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

James,

> We have one server (process) that provides an EPP interface for more
> than one zone, each zone potentially having a different policy, i.e. one
> policy may mandate Key Data whereas another policy may mandate DS Data.
> Furthermore, I do not understand why one zone cannot have a policy that
> gives registrants the choice of DS Data or Key Data for a domain. What
> is the rationale for this requirement?

I don=B9t understand what you mean by =B3each zone potentially having a
different policy=B2. Generally the Registry is providing an EPP interface fo=
r
the management of a TLD (zone) with a single server-side policy. The
rationale for requiring one form of interface for a server was the
following:

1. Be consistent with the other EPP specifications. RFC 5731 supports two
forms of interfaces for name servers (hostObj and hostAttr) where =B3A server
operator MUST use one name server specification form consistently=B2.
2. Provides for a simpler and cleaner interface if the server instance only
supports a single interface for the same object types (DS in RFC 5910).
With the DS Data Interface the client is responsible for managing the DS an=
d
with the Key Data Interface the server is responsible for managing the DS
based on the Key Data. Mixing both interfaces will make it more complex fo=
r
clients, since all clients would have to support both interfaces and would
need to determine the interface to use on domain transfers.

--=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 Mitchell
Date: Sat, 11 Sep 2010 03:11:29 -0400
To: EPP Provreg
Subject: [ietf-provreg] secDNS-1.1: use of only one form of interface

Hello,

I am seeking clarification on the following sentence from RFC 5910.

The server MUST support the
use of only one form of interface across all ,
, and elements, except during a
transition period, during which the server MAY support both.

We have one server (process) that provides an EPP interface for more
than one zone, each zone potentially having a different policy, i.e. one
policy may mandate Key Data whereas another policy may mandate DS Data.
Furthermore, I do not understand why one zone cannot have a policy that
gives registrants the choice of DS Data or Key Data for a domain. What
is the rationale for this requirement?

Regards,

James Mitchell

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

Re: [ietf-provreg] secDNS-1.1: use of only one form of interface</TI=
TLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>James,<BR>
<BR>
> We have one server (process) that provides an EPP interface for more<B=
R>
> than one zone, each zone potentially having a different policy, i.e. o=
ne<BR>
> policy may mandate Key Data whereas another policy may mandate DS Data=
.<BR>
> Furthermore, I do not understand why one zone cannot have a policy tha=
t<BR>
> gives registrants the choice of DS Data or Key Data for a domain. What=
<BR>
> is the rationale for this requirement?<BR>
<BR>
I don’t understand what you mean by “each zone potentially havi=
ng a different policy”.  Generally the Registry is providing an E=
PP interface for the management of a TLD (zone) with a single server-side po=
licy.  The rationale for requiring one form of interface for a server w=
as the following:<BR>
<BR>
</SPAN></FONT><OL><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=
STYLE=3D'font-size:11pt'>Be consistent with the other EPP specifications. &nb=
sp;RFC 5731 supports two forms of interfaces for name servers (hostObj and h=
ostAttr) where “A server operator MUST use one name server specificati=
on form consistently”.
</SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY=
LE=3D'font-size:11pt'>Provides for a simpler and cleaner interface if the serv=
er instance only supports a single interface for the same object types (DS i=
n RFC 5910).   With the DS Data Interface the client is responsibl=
e for managing the DS and with the Key Data Interface the server is responsi=
ble for managing the DS based on the Key Data.  Mixing both interfaces =
will make it more complex for clients, since all clients would have to suppo=
rt both interfaces and would need to determine the interface to use on domai=
n transfers.  <BR>
</SPAN></FONT></OL><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN ST=
YLE=3D'font-size:11pt'><BR>
<BR>
</SPAN></FONT><FONT SIZE=3D"1"><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN S=
TYLE=3D'font-size:9pt'><BR>
-- <BR>
<BR>
<BR>
JG <BR>
<BR>
</SPAN></FONT><FONT COLOR=3D"#800000"><FONT FACE=3D"Arial"><SPAN STYLE=3D'font-si=
ze:7.5pt'>-------------------------------------------------------<BR>
</SPAN></FONT></FONT></FONT><FONT FACE=3D"Arial"><FONT COLOR=3D"#7F0000"><FONT =
SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><B>James F. Gould<BR>
</B></SPAN></FONT></FONT><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><B><FO=
NT COLOR=3D"#4C4C4C">Principal Software Engineer<BR>
</FONT></B><FONT COLOR=3D"#4C4C4C">VeriSign Naming Services<BR>
</FONT></SPAN></FONT><FONT COLOR=3D"#1100EF"><FONT SIZE=3D"1"><SPAN STYLE=3D'font=
-size:9pt'><a href=3D"[email-masked]">[email-masked]</a><BR>
</SPAN></FONT></FONT><FONT SIZE=3D"1"><FONT COLOR=3D"#4C4C4C"><SPAN STYLE=3D'font=
-size:7.5pt'><B>Direct:</B> 703.948.3271<BR>
<B>Mobile:</B> 703.628.7063<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:7.5pt'><BR>
<BR>
<FONT COLOR=3D"#4C4C4C">21345 Ridgetop Circle<BR>
LS2-2-1<BR>
Dulles, VA 20166<BR>
</FONT><BR>
<FONT COLOR=3D"#7F0000"><B><I>Notice to Recipient:  </I></B></FONT></SPA=
N><I><SPAN STYLE=3D'font-size:9pt'>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.  <B>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.</B>  Thank you.<BR>
</SPAN></I></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><S=
PAN STYLE=3D'font-size:11pt'><BR>
<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"><B>From: </B>James Mitchell <<a hr=
ef=3D"[email-masked]">[email-masked]</a>=
><BR>
<B>Date: </B>Sat, 11 Sep 2010 03:11:29 -0400<BR>
<B>To: </B>EPP Provreg <<a href=3D"[email-masked]">ietf-provreg@caf=
ax.se</a>><BR>
<B>Subject: </B>[ietf-provreg] secDNS-1.1: use of only one form of interfac=
e<BR>
<BR>
Hello,<BR>
<BR>
I am seeking clarification on the following sentence from RFC 5910.<BR>
<BR>
The server MUST support the<BR>
use of only one form of interface across all <secDNS:c=
reate>,<BR>
<secDNS:update>, and <secDNS:infData> element=
s, except during a<BR>
transition period, during which the server MAY support bo=
th.<BR>
<BR>
We have one server (process) that provides an EPP interface for more<BR>
than one zone, each zone potentially having a different policy, i.e. one<BR=
policy may mandate Key Data whereas another policy may mandate DS Data.<BR>
Furthermore, I do not understand why one zone cannot have a policy that<BR>
gives registrants the choice of DS Data or Key Data for a domain. What<BR>
is the rationale for this requirement?<BR>
<BR>
Regards,<BR>
<BR>
James Mitchell<BR>
<BR>
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
<BR>
List run by majordomo software.  For (Un-)subscription and similar det=
ails<BR>
send "help" to <a href=3D"[email-masked]">ietf-provr=
[email-masked]</a><BR>
<BR>
<BR>
</SPAN></FONT>
</BODY>
</HTML>

--B_3367215546_9873507--

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

Return-Path: <[email-masked]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o8DCdxHx003973 for <[email-masked]>; Mon, 13 Sep 2010 14:39:59 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o8DCdxxU017969 for ietf-provreg-outgoing; Mon, 13 Sep 2010 14:39:59 +0200 (MEST)
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 o8DCdwG4029845 for <[email-masked]>; Mon, 13 Sep 2010 14:39:58 +0200 (MEST)
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 o8DCS2jw002187; Mon, 13 Sep 2010 08:28:02 -0400
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Sep 2010 08:39:56 -0400
Received: from 10.131.30.174 ([10.131.30.174]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Mon, 13 Sep 2010 12:39:56 +0000
User-Agent: Microsoft-Entourage/12.26.0.100708
Date: Mon, 13 Sep 2010 08:39:56 -0400
Subject: Re: [ietf-provreg] RFC5910 public client implementation
From: James Gould <[email-masked]>
To: Patrick Mevzek <[email-masked]>, EPP Provreg <[email-masked]>
Message-ID: <[email-masked]>
Thread-Topic: [ietf-provreg] RFC5910 public client implementation
Thread-Index: ActQ8+bpbgLZMLQyTJS108opmZpCcgCTN4zH
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3367211997_9622571"
X-OriginalArrivalTime: 13 Sep 2010 12:39:56.0937 (UTC) FILETIME=[C5A8AF90:01CB5340]
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_3367211997_9622571
Content-type: text/plain;
charset="US-ASCII"
Content-transfer-encoding: 7bit

Patrick,

> I have not found any problem implementing the RFC 5910, just one
> nitpick in the 5th example of secDNS update
> (Net::DRI uses examples in RFC for its ~3500 regression tests)
> which says:
> C: <secDNS:update urgent="true"
> C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0">
> C: <secDNS:rem>
> C: <secDNS:all>true</secDNS:all>
> C: </secDNS:rem>
> C: </secDNS:update>
>
> where it should have been secDNS-1.1 I believe.

Thanks, you are correct it should be secDNS-1.1.

--

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: Patrick Mevzek <[email-masked]>
Organization: Dot And Co
Date: Fri, 10 Sep 2010 09:58:55 -0400
To: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] RFC5910 public client implementation

James Gould <[email-masked]> 2010-07-28 21:43
> Just curious if anyone is planning on supporting the Key Data Interface of
> RFC 5910?

On the client side,
as I've just finished its implementation, in the next release of
Net::DRI there will be full support of RFC5910 with both the dsData
interface and the keyData interface provided,
alongside support of RFC4310 which was there since 2006.

The client switches to secDNS-1.1 if announced by server, and
provides the same API in all cases to the calling application.

I have not found any problem implementing the RFC 5910, just one
nitpick in the 5th example of secDNS update
(Net::DRI uses examples in RFC for its ~3500 regression tests)
which says:
C: <secDNS:update urgent="true"
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0">
C: <secDNS:rem>
C: <secDNS:all>true</secDNS:all>
C: </secDNS:rem>
C: </secDNS:update>

where it should have been secDNS-1.1 I believe.

If there are some people that can test with or provide access to
servers announcing secDNS-1.1 only or secDNS-1.0 + secDNS-1.1
please contact me in private to get an RC tarball if you are
interested in interoperability tests.

Also, I've implemented at the same time the .EU specific DNSSEC
extension called "Keygroup" to manage list of dsData material.

--
Patrick Mevzek
Dot and Co <http://www.dotandco.com/> <http://www.dotandco.net/>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

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

<HTML>
<HEAD>
<TITLE>Re: [ietf-provreg] RFC5910 public client implementation

Patrick,

> I have not found any problem implementing the RFC 5910, just one

> nitpick in the 5th example of secDNS update

> (Net::DRI uses examples in RFC for its ~3500 regression tests)

> which says:

>    C:      <secDNS:update u=
rgent=3D"true"

>    C:       xmlns:secDNS=3D=
"urn:ietf:params:xml:ns:secDNS-1.0">

>    C:        <sec=
DNS:rem>

>    C:         &=
nbsp;<secDNS:all>true</secDNS:all>

>    C:        </se=
cDNS:rem>

>    C:      </secDNS:update&=
gt;

> where it should have been secDNS-1.1 I believe.

Thanks, you are correct it should be secDNS-1.1.

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

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

From: Patrick Mevzek <[email-masked]>

Organization: Dot And Co

Date: Fri, 10 Sep 2010 09:58:55 -0400

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

Subject: Re: [ietf-provreg] RFC5910 public client implementation

James Gould <[email-masked]> 2=
010-07-28 21:43

> Just curious if anyone is planning on supporting the Key Data Interfac=
e of

> RFC 5910?

On the client side,

as I've just finished its implementation, in the next release of

Net::DRI there will be full support of RFC5910 with both the dsData

interface and the keyData interface provided,

alongside support of RFC4310 which was there since 2006.

The client switches to secDNS-1.1 if announced by server, and

provides the same API in all cases to the calling application.

I have not found any problem implementing the RFC 5910, just one

nitpick in the 5th example of secDNS update

(Net::DRI uses examples in RFC for its ~3500 regression tests)

which says:

C:      <secDNS:update urgent=
=3D"true"

C:       xmlns:secDNS=3D"=
;urn:ietf:params:xml:ns:secDNS-1.0">

C:        <secDNS:r=
em>

C:          =
<secDNS:all>true</secDNS:all>

C:        </secDNS:=
rem>

C:      </secDNS:update>

where it should have been secDNS-1.1 I believe.

If there are some people that can test with or provide access to

servers announcing secDNS-1.1 only or secDNS-1.0 + secDNS-1.1

please contact me in private to get an RC tarball if you are

interested in interoperability tests.

Also, I've implemented at the same time the .EU specific DNSSEC

extension called "Keygroup" to manage list of dsData material.

--

Patrick Mevzek

Dot and Co <http://www.dotandco.com/<=
/a>> <http://www.dotandco.net/&=
gt;

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=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_3367211997_9622571--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 o8B7Bi0e016294 for ; Sat, 11 Sep 2010 09:11:44 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o8B7BiRq021298 for ietf-provreg-outgoing; Sat, 11 Sep 2010 09:11:44 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mx10-2.ausregistry.net.au (mx10-2.ausregistry.net.au [202.65.12.91]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o8B7Bfjt006492 for ; Sat, 11 Sep 2010 09:11:43 +0200 (MEST)
Received: from off-win2003-01.ausregistrygroup.local (off-win2003-01.stkildard.vic.ausregistry.com.au [10.30.1.3]) by mx10-2.ausregistry.net.au (8.13.8/8.13.8) with ESMTP id o8B7BXw1010915 for ; Sat, 11 Sep 2010 17:11:34 +1000
Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Sat, 11 Sep 2010 17:11:33 +1000
From: James Mitchell
To: "[email-masked]"
Date: Sat, 11 Sep 2010 17:11:29 +1000
Subject: [ietf-provreg] secDNS-1.1: use of only one form of interface
Thread-Topic: secDNS-1.1: use of only one form of interface
Thread-Index: ActRgI42EPKIvN07TlG9DEeDFY09jQ==
Message-ID: <[email-masked]>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-cr-hashedpuzzle: Alw= AH4m BBg3 BIQV ENjK EY/a F0b4 F2de G2Bp HXdx IciF JAAK JD28 Jv2e KDHi KGW/;1;aQBlAHQAZgAtAHAAcgBvAHYAcgBlAGcAQABjAGEAZgBhAHgALgBzAGUA;Sosha1_v1;7;{C0C91B23-6D8B-46C1-947A-32E93D687A38};agBhAG0AZQBzAC4AbQBpAHQAYwBoAGUAbABsAEAAYQB1AHMAcgBlAGcAaQBzAHQAcgB5AC4AYwBvAG0ALgBhAHUA;Sat, 11 Sep 2010 07:11:29 GMT;cwBlAGMARABOAFMALQAxAC4AMQA6ACAAdQBzAGUAIABvAGYAIABvAG4AbAB5ACAAbwBuAGUAIABmAG8AcgBtACAAbwBmACAAaQBuAHQAZQByAGYAYQBjAGUA
x-cr-puzzleid: {C0C91B23-6D8B-46C1-947A-32E93D687A38}
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mx10-2.ausregistry.net.au
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o8B7Bhjt024529
Sender: [email-masked]
Precedence: bulk

Hello,

I am seeking clarification on the following sentence from RFC 5910.

The server MUST support the
use of only one form of interface across all ,
, and elements, except during a
transition period, during which the server MAY support both.

We have one server (process) that provides an EPP interface for more
than one zone, each zone potentially having a different policy, i.e. one
policy may mandate Key Data whereas another policy may mandate DS Data.
Furthermore, I do not understand why one zone cannot have a policy that
gives registrants the choice of DS Data or Key Data for a domain. What
is the rationale for this requirement?

Regards,

James Mitchell

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 o8ADwweZ026037 for ; Fri, 10 Sep 2010 15:58:58 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o8ADwwLt016728 for ietf-provreg-outgoing; Fri, 10 Sep 2010 15:58:58 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.dotandco.com (triglav.dotandco.com [194.242.114.22]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o8ADwvbs005994 for ; Fri, 10 Sep 2010 15:58:58 +0200 (MEST)
Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by mail.dotandco.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o8ADwvNT013431; Fri, 10 Sep 2010 15:58:57 +0200
Received: (from patrick@localhost) by triglav.dotandco.com (8.14.3/8.14.3/Submit) id o8ADwuc0013429; Fri, 10 Sep 2010 15:58:56 +0200
X-Authentication-Warning: triglav.dotandco.com: patrick set sender to [email-masked] using -f
Date: Fri, 10 Sep 2010 15:58:55 +0200
From: Patrick Mevzek
To: EPP Provreg
Subject: Re: [ietf-provreg] RFC5910 public client implementation
Message-ID: <[email-masked]>
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
Organization: Dot And Co
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

James Gould 2010-07-28 21:43
> Just curious if anyone is planning on supporting the Key Data Interface of
> RFC 5910?

On the client side,
as I've just finished its implementation, in the next release of
Net::DRI there will be full support of RFC5910 with both the dsData
interface and the keyData interface provided,
alongside support of RFC4310 which was there since 2006.

The client switches to secDNS-1.1 if announced by server, and
provides the same API in all cases to the calling application.

I have not found any problem implementing the RFC 5910, just one
nitpick in the 5th example of secDNS update
(Net::DRI uses examples in RFC for its ~3500 regression tests)
which says:
C:
C:
C: true
C:
C:

where it should have been secDNS-1.1 I believe.

If there are some people that can test with or provide access to
servers announcing secDNS-1.1 only or secDNS-1.0 + secDNS-1.1
please contact me in private to get an RC tarball if you are
interested in interoperability tests.

Also, I've implemented at the same time the .EU specific DNSSEC
extension called "Keygroup" to manage list of dsData material.

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